In the beginning there were raw html pages. Real web page designers used something like NotePad to directly edit the html tags. That did work, and there are still raw html editors available - they let you work with html tags and provide easy reference to the full range of tag and style sheet options. If all you want to do is edit single web pages, working with the raw html can be both efficient and effective (assuming you understand tags and css).
When you need to edit an entire website, working one page at a time is fraught with problems. Basic to any multi-page website are the cross links, the hyperlinks, that take the visitor from one page to another. Keeping track of those links, and making sure that all the pages share a common look and feel, can be done a page-at-a-time, but there are tools that will automatically look after these important background concerns.
There is, however, an important difference between a website that has one person making all the changes, and a site that has multiple participants contributing in different ways. The single person website can be developed and edited on the author's personal computer. New versions of the site are developed on the desktop. When it's the way you want it on the desktop, it gets uploaded to the public server. And that's a perfectly reasonable approach for a single person website.
When you need to have more than one person contributing, the desktop approach just isn't powerful enough. Different people will play different roles, and different rights will be assigned to different roles. It can get very confusing if the system supporting the website isn't set up to recognize rights and roles. Content Management Systems (CMS) are set up to recognize different roles and provide users in those roles with access to only those tasks they are authorized to perform. Security Management is basic to all multi-user Content Management Systems.
The CMS is generally able to separate out the different site management roles:
There are literally hundreds of Content Management Systems available. Most of the free CMS have been designed for the LAMP environment - Linux, Apache, mySQL & PHP. LAMP hosting services are widely available and typically are the most attractively priced. Restricting consideration to LAMP CMS, there are still very many options from which to choose.
A CMS can confront the system administrator with a vast range of choices. It's all too easy to suffer a severe case of "option shock" when reviewing the administrative options available in a CMS. There is a general trade-off between features and flexibility, with accompanying option shock; and limited, but easy to understand. Drupal is a widely used open source (freely dis) LAMP CMS - the US White House has just selected (Oct 2009) Drupal to support its website. But Drupal is on the option shock side of the spectrum.
There are thousands of free modules available for installation on a Drupal site. There is a very active Drupal development environment. There are specialized Drupal hosting services. There are regular Drupal developer meetings held throughout the world. There are a number of local, national, and international Drupal development shops. The community is currently providing support for Drupal version 5, encouraging everyone to move to Drupal version 6, and actively developing Drupal version 7. Version 4 is no longer being supported, and there is almost no visibility for version 8.
I use Drupal on several sites, and have recommended it for several other sites. My experience has been generally positive. But it's not all straight forward and obvious. What follows are some of the observations that I have discovered, or that have been forced upon me.
Open source isn't without cost. It's true that there is no charge for access to open source system - you don't pay to get the code. But there is a cost in terms of time and energy. Support comes from a community, and participation in that community takes time and requires energy. You don't have to pay the firm that developed the system, but you do have to "pay" to be accepted into the community that supports the system.
Popular systems demand regular maintenance. All publicly available systems are exposed to hackers. There are no invulnerable systems, and public systems are necessarily open to attack. Drupal is a popular public system. It regularly gets hacked. And there are regular security updates. You don't really have the option of not installing those security updates. When a security vulnerability is discovered, there will be automated "spiders" searching for sites that have not bothered with the update. Your site will get hacked.
Sharply limit installed modules. Going to the drupal.org module pages can be emotionally similar to what a small child experiences in a free candy store. It's all too easy to over-indulge in installing modules. After all, they're free. Why shouldn't we install them? They might come in handy. Resist the temptation!
My list of installed module concerns:
Only touch actively supported modules. Problems can develop (or be discovered) over time. Active support is important to fix any problems that may arise. Just looking at the date of the most recent version provide an indication of support activity. And it helps to be sufficiently plugged into the community to understand which modules are being frequently installed and actively maintained.
Limit yourself to multi-version modules. Drupal will always have a supported legacy version, an active version, and a planned version. Ideally, all modules you use will have versions for all three Drupal versions. If you're still one version back with Drupal (the legacy version), only install modules that also have versions for the current Druapl version, and are committed to supporting the next Drupal version. There is an obvious exception for modules whose functionality is being integrated into core Drupal and are not required in the current version.
Restrict those with administrative rights. Well meaning individuals without the proper experience can cause serious problems on a Drupal site. Restrict the number of people with significant administrative rights (to visual design, architecture, maintenance, and security). The administrative "team" could be as small as one person, and should only contain people who have a shared understanding of Drupal and what the site is to accomplish.
Approach multi-site configurations with caution. Drupal is able to support multiple sites from the same code base. That can mean that the cost of supporting the code base is shared across multiple sites, thereby saving support costs. Yes, but ... If the same team of individuals is administering all the sites, this can be a sensible approach. If different people are administering the different sites, multi-site configurations can pose serious maintenance problems. Maintenance happens on the common code base which means that all sites must undergo parallel maintenance. With different sites, each with different administrators, who will be concerned about different things, serious coordination problems can arise.
That's it for my short-list of my most important Drupal concerns. There will always be evolving concerns. Today (Oct 2009), my concern about spurious registrants is sharply increasing. The Capatca module is effective in filtering out automated registrants. The Profile module allows you to demand additional information from registrants. But there still seems to be a steady trickly of individuals who request registration with the obvious purpose of inserting their "advertisements" into public forums. I've recently taken to requesting a personal email message before registering new people on my sites - removing the automated registration process.
With all of the challenges, I still find Drupal to be an attractive platform.