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.

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”.

I suspect that there are others…

“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