Open-Src
Open-Source CMS: Prohibitively Fractured?
by Tony Byrne
14-May-2003
I love the whole idea of open-source software. Like the proverbial "conservative who used to be a liberal before he was mugged," I didn't convert completely to open-source tools until I had to oversee a team managing a couple of racks of hiccupping Microsoft webservers. The servers inevitably earned nicknames like "Reboot," and "Meltdown."
So when we built CMS Watch two years ago, it was around LAMP technologies: Linux, Apache, MySQL, and PHP, fronted by an open-source CMS, Midgard.
Linux and Apache continue to win hearts and minds. Interestingly, however, the major open-source content management projects have not advanced as rapidly as their commercial competitors in the past two years. It's puzzling and a little disappointing. This is not to say that there hasn't been a lot of work going on. Just the opposite: depending on which list you consult, you can choose from among 45 to 75 or more active open-source CMS projects out there. People are working quite a lot, but towards what end?
What appears to have happened is that development resources have become dissipated among so many different initiatives that seemingly none of them is achieving critical velocity. Moreover, an emphasis on technical elegance over end-user features goes against what the CMS marketplace is looking for today.
Which Language?
One part of the story is that the open-source CMS community has become fractured into various camps centered principally around different scripting languages (e.g. Perl, PHP, Python, Tcl). Scripting languages are nice. Each of them brings unique advantages dealing with the kinds of text blocks that predominate in CMS implementations. But their adherents tend to promote them with a quasi-religious fervor despite the fact that none of the languages holds a decisively compelling edge for developing content management systems.
One thing all the scripting languages share is the mantra that they "are not Java." That means you can code faster, usually because the languages deliberately ignore certain strict rules that Java enforces, therefore leaving you free to follow less of an object-based orientation if you wish (or if your team is undisciplined). But there's the rub. On a large, distributed CMS implementation, the apparent drawbacks of Java (or COM, for that matter) start to become benefits, as they force developers to code in ways that other developers can understand and extend.
Some open-source CMS projects are Java-based. However, like the early versions of commercial application servers, they have tended to rely on strange alternatives to JSP, and didn't support any recognizable Java design pattern. Of late, this has improved a bit (for example, see our take on the latest OpenCMS upgrade). But more importantly, these packages don't tend to exploit several fast-evolving Java projects that bear directly on content management. It's great to use the Tomcat engine, but scarce developer resources could be better husbanded by leveraging the rest of the Apache family of Java-based toolsets, like Cocoon, Xindice and Axis.
The result of all this is that development energy dissipates -- not just across the open-source community at large, but within a language group itself. Only the Python community has coalesced its resources around a single CMS (Zope), and even Zope seems a bit splintered. This stunts the growth of a package, and perhaps more importantly, limits the available support resources that have traditionally distinguished open-source offerings from poorly-supported commercial competitors. Once you get beyond the handful of major open-source CMS projects, nearly all the rest are driven by a single, very small consulting firm, sometimes with occasional contributions from a smattering of other developers. These efforts may not fail to the extent that they disappear -- the project sponsor's consulting clients keep them afloat -- but the packages tend not to advance very much either.
Of course, there are also literally hundreds of small commercial CMS packages -- developed and sold by lone consulting firms -- that have similarly dismal prospects for longterm growth. On the other hand, more than 40 major commercial CMS providers around the world continue to generate enough license revenue to underpin significant R&D efforts. Over the past couple of years, a large chunk of those development resources has gone into making their products more transparent, customizable, and user-friendly. To what extent has the open-source CMS community matched these efforts? Let's look deeper.
In Platforms We Trust
Many leading open-source CMS projects have resigned themselves to becoming development "platforms," spawning multiple (often competing) derivative projects to undertake the difficult work of actually fashioning products that will appeal to real business users. To be sure, building a good platform is hard, too. It takes a lot of architectural savvy, trial and error, and constant refactoring. (Certain Apache projects fulfill important lower-level functions and properly remain platforms rather than polished products.) But a platform doth not a CMS application make.
This trend is ironic, because much of the criticism of bloated or failed CMS projects has centered around the commercial products involved being too "platform-oriented" and therefore requiring excessive, code-based customization to convert into practical CMS applications. Extensibility is important, but savvy customers expect to see the inclusion of core features, together with the ability to configure key settings via simple browser interfaces.
We know, in fact, what most business users want today. After 8 years of Web CMS development, certain core features have emerged as very important or even essential to content managers. Most such features have found their way into even the most elemental and inexpensive commercial packages, but many of them remain absent from open-source packages, or require substantial scripting to replicate. (For more on this topic, plunk down a measly US$200 to attend the OSCOM conference in Boston, and consider attending my talk, "Top Ten Features from the Commercial CMS World." By the way, OSCOM promises to be a great show this year.)
Open-source adherents offer three replies to the "platform" criticism:
- Since the source is completely open, you can build whatever features
you need.
Sure, but my clients want these capabilities out-of-the-tarball. Someone needs to push for these features to be added to the core package. This is what good product managers do. The absence of strong, customer-oriented product managers makes me wonder whether open-source packages that principally serve non-technical business users may be fated to stunted development and acceptance.
- You can contract for professional services, or buy commercial add-on
modules from sponsoring firms that provide key CMS functionality.
Doesn't this kind of defeat the purpose of going open source in the first place? I don't mind employing professional services to help with complex implementations; I do resent having to bring in consultants to build basic features (like event notifications or new content types) that should be configurable via a browser interface.
- Other firms offer derivative CMS products, such as Plone or ZMS,
two CMS products built on the Zope CMF platform.
These derivative offerings can offer a helpful alternative, but they are typically too small to attract a critical mass of developers. To the extent it splinters the community within any one platform, this approach becomes part of the problem, not the solution.
In Developers We Trust
My experience helping organizations select CMS technologies suggests that open-source packages tend to get chosen when IT groups -- developers in particular -- have preponderant power in the selection process. Developers often have excellent reasons for choosing open source. They may have been burned repeatedly by bad, unsupported commercial software, often foisted upon them by naive business managers. Perhaps they learned the hard way that Linux and Apache are the most reliable products in their respective categories.
But recall that operating systems and webserver software are fundamentally tools for developers, not business users. At a time when many commercial CMS packages have invested substantial resources in usability, the major open-source offerings tend to retain a very "techie" feel to them.
Moreover, many of the rationales for selecting open-source content management tools don't hold as much water as they used to.
Some open-source packages remain quite proprietary while their commercial competitors are increasingly adopting industry standards. This risks locking the implementer into particular solutions. In other cases, the packages push customers into a highly specialized environment, or a single repository package. For example Midgard requires MySQL, RedHat CCM mandates Oracle, and Bricolage only uses PostgreSQL. Those are all fine databases, but requiring them reduces the portability of the system. Zope prefers its own unique database that no one outside the Python community would ever consider using.
At the end of the day, developers often take comfort that the underlying source code is freely available. No need to lose sleep over a vendor heading to bankruptcy court. Yet, if you're worried about corporate viability in a commercial offering, you can negotiate to have the source placed into escrow, to be released upon any vendor dissolution. The difference with open source, however, is that developers can fiddle around with the actual core source code during implementation. Beware: significant changes to the underlying source can splinter your application from the main development tree. When that happens, and it's time for an upgrade, then you are truly, well, "forked."
You could take some comfort, I guess, that major upgrades have been very slow in coming for the major open-source packages. Nevertheless, there's another irony here: the danger of forking represents a traditional criticism of failed commercial implementations, especially those where the product uses scripting languages underneath the covers. So it turns out you can isolate yourself in both the cathedral and the bazaar.
What Is to Be Done?
I would like to see development and support resources coalesce around winning projects. Open-source CMS efforts would benefit from a selective merger of efforts, especially among packages using the same language. We could celebrate that a thousand flowers have bloomed, but let's also acknowledge that too few of them give off a sufficiently pleasant fragrance today.
Right now, a lot of cooperation seems to be focused instead on "interoperability." In a recent article, two open-source veterans discuss how they have overcome their skepticism about early OSCOM efforts to foster more interoperability among open-source CMS packages. Indeed, some progress has been made on common standards. This is useful, but doesn't solve the key problem of too many undead projects. Moreover, I believe that customers remain less concerned about interoperability between prospective CMS implementations, and more about integration between CMS applications and other enterprise systems like document management, print publishing, or asset management systems -- many of which inevitably are commercial in origin.
The community could also be more active in adopting larger foundational efforts as the base of their systems -- employing specifically the diverse Apache initiatives, from webserver to repository. Five years from now, it's highly likely that buyers are going to choose from among CMS solutions built on top of 4 major "enterprise" families: Oracle, IBM, Microsoft, and Apache. Might as well start aligning with the Apache project now. But more importantly, focusing CMS efforts higher up the solutions stack will make open-source CMS packages more feature-rich and relevant to content managers. The successful open-source CMS projects will be those that get out of the technology ghetto and pitch more aggressively to marketing and other business people to see what the latter really need (and here's a hint: they're generally not thinking about topic maps and the semantic web) -- then take those features to heart.
What is a prospective CMS buyer to do? The best package-selection decisions get made when content owners, marketing staff, and IT specialists collaborate closely in the final choice, so they all obtain what they need. Working together and carefully testing their alternatives, they might pick an open-source CMS product. Increasingly, I think, they will pick a commercial alternative instead.