In my last post I talked about the process we went through for choosing an open source Content Management System (CMS) for the new Redwood Technology Consortium web site. But let me back up a little and talk about why we even wanted a to begin with. After all many web sites are built and maintained by web developers who can update content quickly and easily. What is it that a CMS does that made us go in that direction in the first place? After all aren’t we, the members of RTC technologically savvy enough to maintain our site the old fashioned way? Isn’t a CMS designed for organizations that don’t have the expertise to manage their own sites?
The simple answer to both questions is “No.” While many of the people in RTC could spend the time manually updating content, the truth is, as an all volunteer organization, no single person has the time to keep up with the content changes on the site. So, various people are given the responsibility to update different aspects of the site. Some of them know web programming and some of them don’t. It’s much easier then to provide access to web site maintainers to manage content through a web browser. As any good CMS separates content from presentation, this process ensures the look and feel of the site retains its integerity and consistency.
In addition to content management, today’s CMSs come with a wide range of features that can be added by plugging in a module. And popular systems receive module contributions from developers on a daily basis. Looking at the current and potential needs of RTC we realized it would be most cost effective to adopt a system that had these features built in or can be easily added. Otherwise we would continually need to be paying programmers to develop and integrate these features as our organizational needs changes.
So why isn’t every site built with a CMS? The truth is, nearly every site probably should have some way for the organization to update information easily. The days of static sites with unchanging content are over. Web sites, to be effective, and to have visitors return, need to be dynamic, with content being kept fresh and up to date. This might mean just having a calendar of upcoming events, or Tip of the Month, or Photo of the Day or recent news. It doesn’t always require a full-blown CMS, but sites should at least have simple tools that make keeping these kinds of things current by site owners. Otherwise they will always be at the mercy of a webmaster and his or her schedule. I don’t know how many times we have worked with clients who have complained that their site hasn’t changed in months because they can’t get their ‘web guy’ to update it.
So, RTC decided to go for an CMS that would make updating the content easy for a team of people and would allow for easy expansion of features as the organization’s needs changes. We did not want the expense of purchasing a closed, proprietary system that would require being locked in to a single web development company to make changes to the system. So, we decided to look for an open source system.
As I pointed out earlier there are a huge number of these systems most with a large community of enthusiastic developers behind them. After looking at many and trying to match our specifications with the systems’ featuresets it came down to two possibilities: Joomla, and Drupal. Don’t ask me where these names come from – I haven’t a clue. Both systems came close to meeting our needs. Both seemed easy to use and extendable. Joomla, however, is an off shoot of another system called Mambo. And while its seemed stable this tipped the balance a bit toward Drupal which has had a steady history of development for several years. The final decision came down not the merits of the software, but to a person. We knew a local developer (Rob Wohleb of Blue Ant Media) who has a great deal of experience with Drupal. He’d worked for me previously and he was willing to take on this task becasue of his support of RTC and our area. That sealed the deal. Drupal it was.
Next: Why using a CMS is not always the smoothest, easiest process.
Oops, I left out the key detail! When Dries released the software powering his personal website, he chose the Dutch word for ‘drop’ as its title: Drupal.
All of this is from the Drupal History page in the Drupal Handbook.
Thanks for the story. But how did they get from drop.org to drupal.org?
Here’s the story to satisfy your curiosity about the origins of the name Drupal: