In 1997, I was at the Macromedia User's Conference to give a talk on creating "intelligent" agents within Macromedia Director. At this particular conference, Macromedia announced a new product called Dreamweaver, an HTML editing application that exercised a profound effect upon the web development community.
Intended to compete primarily with Microsoft FrontPage (and secondarily with Allaire's HomeSite, which Macromedia ended up acquiring a few years later), Dreamweaver very rapidly became the product to beat in this category. If a medium to large company had a web-presence, there was a high likelihood that Dreamweaver could be found in the web production department. Indeed, it can be argued that while Flash may have been the primary reason that Adobe ended up purchasing Macromedia in 2006, Dreamweaver sweetened the deal considerably.
Yet there are a number of indications that Dreamweaver may be losing ground to an unlikely competitor: Drupal. Established in 2000 as an open source platform for building community-oriented sites, Drupal might seem an odd choice to be keeping Adobe managers awake at night, particularly since Drupal tends to be seen as a content management system rather than a website editor, though it is in fact really neither.
Web designer Tom Arah recently wrote in his blog that Dreamweaver is Dying, not through any intrinsic fault of the application itself, which is (as I would agree) superb. Rather, what has changed is the nature of the web itself - that ultimately it is as more about the ease of content creation and management within a given framework than it is about the sophistication of the editing tools.
While I agree with his conclusion - that Dreamweaver's days are numbered - there is in fact more to the story than just that content management is becoming the preferred mechanism. It actually has far more to do with the very nature of community generated software itself, and specifically a class of very successful open source software that share a number of common characteristics.
At the 2008 OSCON, Roy Fielding gave an interesting talk about open community projects, those projects which have managed to successfully harness a collaboration between a development core and a community of module developers that add to the richness of the core, and pointed out that these tend to spawn remarkably stable, long term projects. The examples that he gave included Linux, Apache and Firefox, but I'd be inclined to include Drupal in this category as well.
The best way to think about Drupal is to envision it as a small core of highly integrated modules along with a very clearly articulated mechanism for extensibility and integration. This core is written by developers. Around this core are a cloud of thousands (about 12,000 at last count) modules that are developed by the community, usually to solve specific needs or itches. Because the core architecture is so well articulated (and undergoes a thorough vetting between version changes) the community modules are usually able to work well with one another. It's not perfect - in the 5.0 branch, for instance, there's about three alternative architectural approaches that you can take and these introduce some minor incompatibilities - but for the most part the system works well.
A typical Drupal sys-admin would then load in the modules that he or she needs to facilitate a given type of project, sets up the corresponding configurations in an admin screen, then lets it run. The sys-admin does not need to know anything about programming PHP; indeed, I've been working with Drupal for about the last four years, and I think I've only really begun delving into PHP in the last six months, and that only because I wanted to write my own modules for a few functions that I couldn't get pre-written.
Overall, its a pretty powerful approach. I can set up views that generate serial collections of given document types using a standard forms page which essentially generates the SQL queries that run the views in the background; these in turn can be used to populate tables, lists, more sophisticated HTML constructs, RSS feeds, Atom feeds and so forth. Again I can think of only two instances where I specifically rewrote these queries manually, and again this was for something that was highly unorthodox ... and significantly, within a few months in at least one case, someone had written a module to do this.
You can get a Drupal site up and running within minutes for something as simple as a blogging page, and a fairly sophisticated site upon within a few days if you know what you're doing. Because of Drupal's structure (and its fairly innovative approach to looking at different types of documents as "nodes" of different "content type") you can also create remarkably sophisticated page layouts that hold a lot of related content (for instance, you could readily create a Drupal instance that would include content types representing galleries of images that share a common keyword, events listings with date selectors and related output display, purchasing orders, news articles, library cards, or just about any other kind of document.
I find that the XML community has actually tended to gravitate towards it, because its one of the few PHP/mySQL applications that so readily encompasses RESTful services programming. It has some downsides - performance can be an issue, especially for complex views or similar complexity, and even with a lot of different theme creators Drupal sites tend to develop a certain sameness, largely because of the data-feed oriented nature of the application (which imposes certain layout implications). However, because there is a more effective templating mechanism and the node architecture working in the background, comparing Drupal and Dreamweaver is an oranges vs. apples comparison.
In a back-channel discussion among the O'Reilly editors, O'Reilly Co-founder and Make Division General Manager Dale Dougherty brought up the question about whether applications such as Drupal shifts the balance of focus to developers rather than users. While this is true for a number of members of these new classes, Drupal in particular actually serves to more effectively empower users at various levels of access than either web editors such as Dreamweaver or more focused web blogging CMS's such as Movable Type.
One reason for this is that while only one specific account can add new modules to a given site (effectively the sysadmin for that site), each module typically offers a variety of specific operations which can be assigned to one or more access classes (each of which are, with the exception of two base classes, created by the sysadmin). This means that a sysadmin can give to a group moderator the ability to create new content types, and the moderator can in turn give to logged in users the ability to create individual documents based upon these content types, with taxonomy, input and presentation filtering, property storage and related metadata also assignable at various levels.
For instance, a group manager for a newspaper using Drupal as its community engine could create a general news article content type, a sports article (or even an individual baseball or basketball article) content type, a finance article content type and so forth. A baseball article would include taxonomy links to Major League Baseball teams, might include an optional set of fields for loading in box scores and featured player statistics, and so forth.
The group manager would also set up different filter types - a rich text WYSIWIG editor, a bare HTML editor, a specialized BBCode editor, a line break text editor, that a writer could yse - and might even have the option of using special macros in the input types for linking to specific player bios, promotional events, layout options and so on. These too can be modified, and multiple filters can be applied (such as the WYSWIG editor with macro enlargement), and the moderator can even assign which groups could access which kinds of filters.
More significantly, none of this requires formal "programming". Instead you'd take advantage of taxonomy module administrator screens to create the team "names" (which also serves to link additional related content), you'd use the Content Construction Kit (CCK) module screens to add new fields, and you'd use Views to retrieve a list of previous articles about the team. The moderator would never write a line of code to do any of this.
The sports writer, in turn, would see specific content types for Baseball stories, Basketball stories, Football stories and so forth, as well as a more generalized Sports story. These content types would be "templates" - when he created a new article of a given type, he'd see a drop down list where he could select the two competing teams, could select that this story was a game review rather than general news, and then would write the story, using one of the input filters that the group manager had assigned for his group.
The writer could save successive revisions until he was ready, then he (or perhaps someone else with different permissions) could set the article's workflow state to "published" to make it visible - not only as a story that people could read in full but as a teaser in a list of related topics, a title in a list of related content, an entry in an RSS or atom feed, an entry under Baseball or either team's taxonomy pages, an email newsletter item, a Twitter announcement and so on - each of which are modules that can be added without a line of code ever being formally written by anyone at the newspaper.
Not only is such a combination devastating to static content editors such as Dreamweaver, but this same modularity means that new features can be added in as soon as someone realizes that there's a need for them. The Twitter module, for instance, emerged within two weeks of Twitter publishing their APIs. with stable (approved) versions coming out about two months after that.
One additional nail in Dreamweaver's coffin - AJAX toolkits have been heavily integrated into Drupal (primarily jQuery, though it is possible to use other toolkits). This means that it is possible to create both WYSIWIG and specialized editors (including customized buttons and related functionality) that give you most of the capability that Dreamweaver itself offers, at least on the editor side, and the complete shift in how documents are stored and managed makes much of Dreamweaver's additional functionality obsolete.
Drupal isn't perfect. It does take some time to become proficient with the Drupal content model (even after four years of working with it, I'm still having "a ha!" moments), the presentation and style layers are not as sophisticated as they could be, performance can be a problem on occasion, and there are times where I wish I didn't have to deal with PHP as a foundational layer, as PHP itself has problems.
My own take is that Drupal is ultimately a transitional application, as a significant amount of Drupal's capabilities can also be seen (in a somewhat more refined fashion) within XML pipeline systems using RESTful interfaces and XQUery. Yet its a transitional application with some serious legs as well ... the Drupal developer community is growing rapidly, though this is still smaller than the number of "super-users" that see Drupal as a site building or management tool.
My recommendation to Adobe - study Drupal very closely, not just as a product but as the harbinger of a wave of products that are developed via crowdsourcing and community involvement. There's room for a proprietary version of the same type of system, a toolkit for building complex community sites, but it requires getting beyond Dreamweaver and building a community editor for the twenty-first century.