Kellan (I’m guessing) offers some insightful thoughts about hosting software for nonprofits. He raises two challenages facing folks who build nonprofit solutions using so-called ‘niche’ platforms like Zope or Rails… well, really anything other than PHP, right?
Challenge #1: “Qualified developers for ‘niche’ technologies.”
There are definitely a lotta folks out there who know a little PHP, and not as many (yet) who can hack around with Zope or Rails. But I’m not sure there are that many more people who can effectively make substantial changes to a complex PHP application such as Gallery, CivicSpace or Groundspring’s forthcoming Enterprise. And the great thing about frameworks like Rails or Zope is that they’re pretty easy to learn and generally well documented. Also, the points in the landscape to find help are well-lit and active.
But I definitely agree with the larger point that I think Kellan’s trying to make: the nonprofit tech community needs to do a much better job of teaching itself platforms that aren’t “lowest common denominator” so it can take advantage of the huge leverage that platforms like Zope and Rails offer. I think this is definitely solvable — in fact, ONE/Northwest has already started tackling our local piece of the puzzle by starting the Seattle Plone Users’ Group along with our friend Brian Gershon of RagingWeb. (You can join the email list here.)
But the “lowest common denominator” challenge is definitely real. In fact, I think it’s been one of the largest challenges that Groundspring’s ebase has faced over its life — there just aren’t tons of great FileMaker consultants out there.
Challenge #2) Low cost hosting.
Kellan correctly notes that low-cost PHP hosting is pretty ubiquitous these days while Rails hosting is “at the moment nearly non-existent” and Plone/Zope hosting is a bit more expensive than PHP hosting.
Couple thoughts here. First, the difference between $7/month ($96/year) for bottom-of-the-barrel PHP hosting and ~$15-25/month ($165-300/year) for solid Zope hosting isn’t gonna break the budgets of most nonprofits.
Second, I’d observe that Rails and Plone/Zope are in very different places, and it’s probably not fair to generalize about them both simultaneously. Zope and Plone have been around for a few years now, and while not every Tom/Dick/Harry web host supports them, there is a solid marketplace of hosting providers, like Zettai, Quintagroup, and others. I can’t speak to where the Rails hosting market is at, but I’ll take Kellan’s word for it.
If you’re really concerned about the “cost of experimentation” then I’d note that…
A) Installing a working Plone/Zope environment on a Windows or Mac box is literally a double-click. Great for experimentation at zero cost. PHP and Apache can’t touch that kind of ease of install for novices. (See comments. Thanks, John & Trey.)
B) If you’d rather have someone else host your sandbox for you, there are a few providers of free Zope/Plone hosting such as FreeZope and Objectis. Not too bad.
But again, I think Kellan’s right on the larger lesson: folks like Electric Embers, Community Bandwidth, et al. ought to think seriously about expanding their nonprofit-centric hosting practices to include emerging platforms like Zope and Rails. There is a learning curve to supporting these platforms, but it’s not that bad, and it only takes a few talented sysadmins to climb it to start supporting a pretty huge number of nonprofit clients.
Great article Jon.
“Great for experimentation at zero cost. PHP and Apache can’t touch that kind of ease of install for novices.”
I believe WAMPserver provides this:
http://www.wampserver.com/en/presentation.php
Good points. There is at least one “one-click” installer (or close-to-one-click) for PHP-Apache-MySQL on Windows, the Mambo Stand Alone Server. The installer happens to install Mambo as well (hence the name) but you can play around with the environment sans-Mambo.
I suspect that there are others…
This topic certainly makes the rounds. It is again the same questions concerning the fundemental aspects of software and computers. Powerful software in most cases is the enemy of simple (which is not the same as easy to use) software. The best combination is easy to use software that is also powerful. Powerful and complex go together, I just have not seen an exception to this. When software works well, it is layered so that the user can inhabit the layer they are most comfortable with while a transition path to the next layer of complexity and power is well defined.
I work with Plone and Zope as well as PHP when it is appropriate. I have fielded several questions concerning the niche status of Plone/Zope compared to the popularity of PHP based software.
Basically I agree mostly with Jon on many of these points:
Cheap Hosting. You get what you pay for. Most budget hosts are not worth the trouble of saving $5-10 or month. If you use up 3 hours of support time for one year you have probably wiped out the profit margin for your account. That is why the support is usually not that good. I encourage groups to find a host that can provide dedicated resources to their site, otherwise the host has an economic incentive to maximize the number of sites on their machines.
Python vs. PHP. Real quick Python is Java with less typing and no curly braces. PHP is like C like without bothering with pointers. Learning Python is not a black art of some kind, and you can use it for other sysamdin tasks, which PHP is really not suited for.
Qualified Developers. This is the key point. A good developer will not be a one trick pony. If you are looking for sheer number of developers, we should switch to Java, but those frameworks are complex and usually require dedicated hosting. The appeal of many PHP packages is that someone can usually to a string search to change the software (usually look and feel) and this has a certain appeal. As Jon states, once the package reaches a certain complexity or the changes require modfications of the program logic, the skills required to manage the software increase.
I disagree that Zope is easy to learn. I takes some time to learn the framework. Similarly with PHP, if you want to use templating technologies (Smarty,etc) ,
have good seperation of data and view, use standard libraries (PEAR) you are going to find yourself with a complexity that approaches Zope. If want powerful software you will arrive at the same place eventually.
I feel that the focus of the “lowest common denominator” is a result of trying to make the dabbler happy. The dabbler goes by other name, the accidental tech comes to mind although this may not be the best match. The dabbler is someone who can implement a PHP package on a LAMP host, has taught themself some PHP, but is usually too busy or has no interest in more complex platforms or technologies. The don’t want to worry about the architecture of the system, they want their blog to work, be able to change the layout, and be done with it. The dabbler will not created good stable projects, and often creates a large mess. I feel that the NP world relies too much on the dabbler. I don’t think that an org would let say, their tech person dabble in the accounting “oh just a quick little hack with these numbers” or with their fundraising strategy, or organization strategy “hey I just whipped up this 5 year stragegic plan, I will implement it this afternoon”, etc.
I too feel that the conversation needs to move beyond “this package makes it simple to change X”, or “More folks know language Y”.
Might I suggest PLANET ARGON for hosting for Rails. We’re pretty affordable compared to the other options.
All great points – thank you Kellan, Jon and Aaron for keeping me up past midnight. (And, just FYI, we have MAMP on the Mac, for one-click local AMP fun)
After a quick re-read, I tend to agree with the direction of Aaron’s comments most. My own sense is that organizations I’m working with A) don’t have a technology/platform preference and B), if they do, it’s usually a sign that they’re putting the cart before the horse (or the tool before the objective).
I’ve often had to struggle with the “we want a CivicSpace campaign site,” or “we want a XYZ-based publishing system,” only to dig deeper and uncover that the basics of “why are we doing this” and “how will we measure success” have not been documented. However, this is a bit off the hosting and technologies theme, so I’ll digress.
Challenge #2) Low cost hosting.
At the moment, I do support Ruby and Rails. The only challenge is keeping up with the pace of its development — however, when rolled in with other Sunday maintenance, it’s not really a big deal. But, as Kellan suggests, I’m not clear on the performance and scalability issues yet.
Interestingly, I’ve been thinking a lot lately about not charging for hosting at all. To me the idea of a cost attached to hosting is almost misleading. Instead, I’ve thought about inviting clients to make a small monthly investment toward the cost of quality, attentive, support.
If no support is needed, then I would be happy to provide the infrastructure at no cost. However, as most folks that provide hosting know, the real cost is in the time spent helping with application set-up, and ongoing maintenance, security, and upgrades.
So I wonder if the concept of paying for Web hosting is obsolete? With companies like 1and1.com charging 4.95/month, it would seem the writing is on the wall.
Challenge #1: “Qualified developers for ‘niche’ technologies.â€
Similarly, I suspect that the commoditization of software development will eventually push the focus back to quality of planning, delivery, and — most importantly — the experience. Over the years, I’ve worked on enough projects to feel comfortable explaining to a client that there is little different between Java, PHP, Perl, and Python – I’ve seen unusable application built on them all! Instead, I feel that approach and experience are what set successful applications apart from mediocre ones.
To riff on Aaron’s point: would I care if my accountant wanted to use Quickbooks over Simply Accounting or SQL Ledger?
However, I disagree with the idea that the NPO Tech world is filled with “dabblers.†I’ve seen my fair share of “dabbling†in non-NPO settings and, in fact, I’d venture to say more so, given the number of “Hot Script†sites out there with every manner of “build your business online†tool; They come in ASP, Java and ColdFusion too! The “dabbler,†it would seem, is ever-present.
I also disagree with the notion that organizations need to silo away their skills and experts. I feel that it would be good to have more crossovers – techies learning double-entry accounting and organizational development approaches, while program managers get a better sense of what’s involved in getting their information-and-referral database online. In fact, I know it would help make organizations more grounded and compassionate by doing so. And, where I’ve seen technology serve its purpose in the NPO sector in an exemplary way, this is exactly what has happened.
Again, I feel all the points made are valid and helpful (so thank you!). And it goes without saying that this was a decidedly tech thread and was not delving into the other opportunities and challenges around healthy technology interventions. But my final thought is…
A tool is not a process
Technology is a tool. It permeates most of what we do. It’s becoming more ubiquitous and, at the same time, less noticeable in our day-to-day lives. Like hosting: programming languages and development skills will slowly become more commoditized. Ultimately, I feel that deciding factor for clients will be trust in the relationship. I sense that what organizations like ONE NorthWest, Electric Embers and Digital Aid provide to their clients that sets them apart is personal attention, quality relationships, understanding, and commitment to the issues. And I know that “quality programmers†will bring more to the NPO table than design patterns and code efficiency – what will set them apart is their approach to the problems and the experiences they draw on and create.
On the ‘dabbler’……….
What I am trying to convey with that notion is that many groups do not see technology as something worth investing in or planning for even though it isincreasingly becoming more essential to their day to day operations. Often they fill the gap with an intern, which can work great if the they are committed. On the other hand, they can leave a mess, or stop helping out suddenly leaving the organization in a pinch. I too, do not believe that organizations should operate with their staff solely working within their domain of expertise. Tech infrastructure, however, seems the one area where orgs are more willing to risk using someone who may or may not have the skills versus say their accounting or planning etc. I feel that the for profit world understands this a bit better and that the non-profits are still catching up. Almost everyone starts out as a dabbler, I don’t want to discourage non-tech folks from diving in to tech.