Drupal and the Enterprise

(Note: this post is part one in a two-part series. Part two is here.)

One of the most interesting sessions at OSCMS 2007 for me was the discussion billed as "Is Drupal an Enterprise Solution?" I attended in part because I'm interested in the technical issues of large-scale projects, and because facilitating the growth of the overall Drupal marketplace -- including the growth into the corporate/enterprise environment -- has been one of my interests over the past several years.

Expecting a mix of topics, I was a bit surprised that the conversation quickly became focused on questions of organizational culture and communication. In hindsight, this was probably a good thing, as these issues really are the critical roadblocks for most potential large-scale Drupal adoptors.

Technical questions of scale do exist; they require expertise to solve, and it would be nice if this expertise could be more widly held. However, numerous Drupal-based companies and consultants have proven the codebase itself to be eminently enterprise-ready if deployed correctly, and thanks to the efforts of the community (Lullabot trainings, the Drupal Dojo, etc) the pool of talent is growing.

On the other hand, the clash of cultures between most enterprise environments and the Drupal community presents a much more interesting and difficult challenge. There are a number of highly capable individuals working on this from both sides of the issue -- Ivan Labra and Boris Mann come to mind, as well as my partner Zack of course -- but my sense is that it will take some time and effort before there's significant movement on this front.

One of the critical problems is that most so-called enterprise environments are actually far less enterprising (in the sense that you'd find "enterprising" defined in a dictionary) than the Drupal project itself. Most are bureaucratic organizations which move very slowly, deliberately, and generally with an eye towards internal political concerns and risk-management above all else. Some complain that Drupal itself is too slow, political and restrictive. My guess is most of these folks have yet to take a tour of duty in Corporate America. :)

The contrast between Drupal and enterprise cultures is perhaps most strongly evidenced in huge gap in styles of communication. Corporations are organized hierarchically, and in knowledge-work this hierarchy is usually built and maintained via the structure and management of information. To an entity that carefully controls its internal flow of data -- who reports to whom -- and even more carefully restricts what is made available to the Public, the overtly, even aggressively transparent nature of a dynamic open-source project such as Drupal is literally alien. It inspires confusion, if not outright fear or contempt.

In short, Drupal rides the cluetrain, but most of the Global 2000 still do not.

I would argue that our ways are potentially more productive, efficient and honest, and that in the long run top organizations and businesses are going to adopt many of our methods and practices. But this change will be iterative, and the workflows and needs of enterprise customers are going to evolve slowly over several years. As much as antiquated equipment, this is a true "legacy" issue, and one that cannot be ignored.

I think we all recognize the value in reaching out to potential partners, rather than simply remaining aloof and apart. The enterprise environment offers Drupal a chance to engage large-scale applications and drive innovation that would otherwise go by the way-side. They also offer some stability for the marketplace, and have the resources to make strategic investments that may help greatly in taking the platform to the next level.

With that in mind, in the subsequent posts in this series I will explore what I see as some of the next logical steps Drupal can take to be more friendly to the enterprise, as well as what enterprises may have to learn about organization/process from the Drupal project, and vice-versa.

Topics