I saw a call for a ColdFusion developer on an email list I’m on, and I couldn’t help but think about technology choice and change, particularly in the website world, and how nonprofits deal with technology change (or, don’t deal with it.) ColdFusion has been around for 15 years (more than a century in Internet time), and although it has improved and developed, technologically, it has been surpassed by its successors (including PHP, Java, Python, RubyonRails, and even .NET.) But this article isn’t about CF, it’s about technology change.
Technology is a rapidly moving beast. And the pressure to move forward, fast, is right there, always. It’s part of our culture, from the advertisements to the neatest, newest, coolest phones, to the new TV you should have. And then there are those of us in the Nonprofit technology community who are constantly on the bleeding edge of the next thing, whether it be hardware, software, or web services, are constantly talking about it, and how it’s going to make it easier/better/faster to change the world. Although I often get snarky about this, I am aware that I am guilty of this, too.
Most nonprofits are not run by geeks. Most nonprofit leaders think of technology as something in between a useful tool to be leveraged, and a necessary evil. They are resistant to rapid changes in their technology, as well they should be. And, they depend on geeks to help them get things done.
I have a story about nonprofits with a website they can’t leverage for their mission. Although complete fiction, this story will feel quite familiar. And I know I’ve been a guilty party in a real story at some point in my career.
A small nonprofit has a small staff who know a lot about their mission, but nothing about how to create a website. A friend of one of the board members is a web developer. They hire that web developer to put a new site together. The developer waxes poetic about the capabilities of this platform, called AmazingWebCreator. They imagine the developer knows what they are talking about. The developer builds the website, then goes away. The organization is happy for a while, they have a website with pages they can easily edit using a web form, which is more than they had before. Then in months, or years, they want to add some new pages, or a new section to their site, and a widget on the side. But they realize they don’t know how to do that. They call the developer, who is busy now using AmazingWebCreator on some huge project, or has moved on to SuperDuperWebCreator, and doesn’t have time for them. They have to bring in another developer, who knows AmazingWebCreator, which may cost them time and $.
Of course, the critical factor here is what is “AmazingWebCreator”? If it is a relatively new CMS (like WordPress, Drupal, Joomla and others) they may not need to bring in a new developer – they may just be able to get a book, or buy a video to teach them how to use the web interface to create new regions and widgets. If “AmazingWebCreator” is a platform like RubyonRails, Django, .NET, Java, or ColdFusion, they are most likely going to have to hire someone to do that work for them, and depending on the platform, those developers may be either few and far between (ColdFusion) or in high demand, and therefore relatively expensive (RubyonRails, Java.) Worst, of course, is if AmazingWebCreator is a proprietary, custom CMS that the developer wrote themselves in 2002, and no longer supports.
How is an organization supposed to know how to make an informed choice about a website platform? I have a few suggestions:
1) Assumptions: First, assume the person/people who develop your site might not be around in a year or so. And assume there are things you can’t conceive of now that you’ll want to do in a year. Don’t assume the platform that your buddy chose for their organization’s site is the right one for you. Don’t assume that the most popular platform is necessarily the right one, either.
2) Feature set: Garden variety website, or very specialized functionality? (By “garden variety” I don’t mean brochureware. I mean average, normal features of most nonprofit organizations. These include such things as donation buttons/pages, membership lists, blogs, etc.)
3) Platform choice: Look at a number of things – if it’s open source – how many developers are there? How many people use it? How easy is it to find developers? Will most new functionality be able to be added via web interface, or will it require back-end coding? Is it a custom CMS, written, maintained and supported by a single shop? (NEVER, EVER, EVER CHOOSE THESE. Here’s why. Luckily, they are an endangered species.) If it is proprietary, or software-as-a-service, are the extra features really worth the cost? Are there many consultants and developers who can assist you with this platform?
4) Lifecycle: Is it early in the life of the platform, at it’s peak, or late (or very, very late)? Bleeding edge might hurt, aged platform might crumble underneath the weight.
There are lots of folks (I do this on occasion on this blog, and Idealware is a great resource) that can provide you with information about specific platforms, and comparisons between them. Read, read, read, and ask many questions before you decide.
{ 2 comments }

