Separation of Drupal the platform from Drupal products

In the State of Drupal 2011 survey, Dries ask for thoughts about Drupal's future. As CEO of one of the leading Drupal companies, I have of course thought a lot about Drupal's future. Otherwise would be a breach of duty by me. :-) In this blog post, I will share my thinking of Drupal as a platform on which content management systems (CMSes) and other content centric products can be built.

Content management platform = content management framework + tools

Drupal.org portray Drupal as "an open source content management platform". In my opinion, Drupal is not really there. A content management platform is a software framework along with tools that facilitate the building of content centric applications.

The framework should provide services such as

• user authentication and authorization,
• content staging and storage,
• content retrieval and repurpose, and more…

Most of these services already exists in Drupal's core and contrib, but to follow the dependency inversion principle they need to be untangled into service provider interfaces with default implementations.

In addition to the framework, the platform should also include tools for

• configuration management and data migration,
• testing and debugging,
• command line access, and more…

Many of these tools exist as contrib modules (e.g. Migrate, Devel and Drush) or services (e.g. qa.drupal.org), but they need to be part of the platform itself.

With Drupal as a true content management platform, it will be easier to build both off-the-shelf products, such as CMSes and digital asset management (DAM) systems, as well as websites with custom made CMSes and other web applications. The desirable situation can be likened to that of Linux. The Linux kernel and the GNU toolchain form a platform on which different vendors can build Linux distributions. As I see it, this will buy us at least three major advantages, which I will discuss next.

Direct competition with proprietary CMS

Currently, Drupal is a content management framework, delivered with some end-user features, and relying on contrib for others. This makes Drupal out of the box look very rudimentary in comparison with many proprietary CMSes. As everyone involved with Drupal knows, this is comparing apples with oranges. Drupal out of the box is not really a CMS, but a framework on which both simple and advanced CMSes can be built; while proprietary CMS seemingly comes with a boat load of features.

The problem is that this is not necessary known by people evaluating Drupal as an option to a proprietary CMS. At NodeOne we see this from time to time, when a request for information (RFI) or a request for proposal (RFP) requires us to make an assessment of Drupal as a CMS against a list of detailed requirements. Out of the box, Drupal does not meet many of these requirements. But we can build on top of Drupal a CMS that fulfill every requirement. So how should we respond…?

With a clear separation between Drupal the platform and CMSes built on top of Drupal, there will be room for developing and marketing Drupal based products that really can challange proprietary CMSes.

Sustainable business ecosystem

In Harvard Business Review in May/June 1993, James F. Moore described a business ecosystem as

An economic community supported by a foundation of interacting organizations and individuals—the organisms of the business world. This economic community produces goods and services of value to customers, who are themselves members of the ecosystem. The member organizations also include suppliers, lead producers, competitors, and other stakeholders. Over time, they co-evolve their capabilities and roles, and tend to align themselves with the directions set by one or more central companies. Those companies holding leadership roles may change over time, but the function of ecosystem leader is valued by the community because it enables members to move toward shared visions to align their investments and to find mutually supportive roles.

Much of Drupal's success is due to the emerge of a vibrant business ecosystem around Drupal. It creates a demand for Drupal, making it interesting for more parties to contribute in varying ways, which in the end benefit all in the Drupal community.

Today, the ecosystem consists mainly of small companies, of which most are building websites with custom-made CMS based on Drupal. Dries has in speeches and in writing questioned the sustainibility of this business model. I tend to agree. There will always be room for niche players, but if we want the business ecosystem to grow further and continue to prosper, we must facilitate other business models, such as developing, marketing and supporting vendor specific offerings on top of the Drupal platform. Much like how Canonical, Red Hat and other Linux companies are operating today. That will benefit the Drupal community in many ways:

• There will be a large selection of both broad products, that can compete with proprietary CMSes, and niche products that can meet specific needs. Compare with Linux, on which both broad distributions (e.g. Ubuntu ̣— a desktop OS) and niche distributions (e.g. Boxee — a home theater OS) co-exists.
• The possibility for a vendor to control the development of its own CMS will make it commercially more interesting to make major investments. Since Drupal has open source, everything will be contributed, and hence propel the development of Drupal itself and the CMSes built on top of it. Compare with Linux, where Canonical and Red Hat among others are making substantial investment in Linux.
• Commercially supported CMS on Drupal would enable web agencies to focus on their core competence — concept and design of websites — without deep understanding on the inner works of Drupal.
• A separation of products from the platform will allow them to be released in differet paces. The platform can continue to evolve as today, with no fixed release date, while CMSes built on top can have their own release cycles. Compare with Linux, where the kernel is released when it is finished, while the Linux distribution Ubuntu is released every six months.

Separation of concerns

Drupal was from the beginning developed as a content management system (CMS). But with version 4.6, or so, it started a journey towards becoming more like a framework. It is my understanding that this movement was not deliberately in the beginning, but rather evolutionary and a consequence of interesting development such as Form API, CCK and Views. Now, it is a direction actively pursued. But its heritage is visible in that Drupal lacks a clear separation of concerns between the framework and the CMS delivered out of the box.

Separation of concerns (SoC) is about separating different concerns, such as content storage and user interface, and allowing interactions between them only through a well defined interfaces. It is the key principle of software engineering.

SoC is important for Drupal, because it allows us to cope with complexity, and to achieve quality factors such as robustness, adaptability, maintainability, and reusability. I think, as a former developer and a programmer by heart, that this is enough reason in itself for pushing Drupal into becoming a pure framework on which CMS and other products can be built.

Summary

In the future, preferably already in Drupal 8, Drupal needs to be refined into a content management framework that is delivered along with tools, together forming the Drupal platform, on which various CMSes and other goods and services, collectively referred to as Drupal products, can be built and provided. The desirable situation can be likened to that of Linux. The Linux kernel and the GNU toolchain form a platform on which different vendors can build Linux distributions. The main advantages for the Drupal community are:

• An increased use of Drupal due to a diversified product offering that match more people's and business' needs.
• A sustainable business ecosystem, which will propel the development of Drupal itself and the CMSes built on top of it.
• A better separation of concerns, allowing us to cope with complexity, and to achieve quality factors such as robustness, adaptability, maintainability, and reusability.

Afterword

In this blog post I have spoken frankly about the commercial aspects of Drupal. I know it may annoy some. It is not my intention. But I think we must be able to speak openly about the fact that Drupal is big business, and that we who make money on Drupal also have needs that must be considered. In the end, the Drupal Community gains from it.