Has Drupal peaked?
Drupal, a leading open source content management system, is at a crossroads. The same traits that have made Drupal a strong framework are likely to create a glass ceiling for its growth and acceptance.
Drupal is the product of a devoted, closely knit developer community spearheaded by Dries Buytaert. In many ways its evolution and structure has mirrored the Linux community as led by Linus Torvalds. Its name is owned as a trademark by its founder, there’s a nonprofit foundation named after the application… the comparisons abound.
Like Linux, Drupal has embraced every principle of open source, with a development and review process for code that’s enviable. Its internal quality standards are exceptionally high. Its culture is a model of open source in action, and I’ve presented Drupal a few times at conferences in that light.
Drupal’s deference and loyalty from developers has also made it remarkably resistant to adoption and contributions from designers and the creative community. It’s not unique in this regard: the relationship between developers and designers in the open source world is a testy one. In the Drupal community, processes have been set up to accept and management contributions that work for developers -- but they fail the purposes of design completely. Few designers know PHP, and even less are willing to work with tools like CVS, or navigate the quirky and underdesigned morass that is Drupal.org.
Will Drupal continue to grow in the creative community?
Not likely. Even if Drupal were made prettier with a beautiful user interface and Drupal and groups.drupal.org were gorgeous community sites, the fact still remains: Drupal is a remarkably difficult tool for someone who is not a developer.
While the framework is breathtaking at times in its elegance and flexibility, it’s often surprisingly difficult for someone with a traditional HTML/CSS production background to change the HTML that Drupal puts out. This can lead to countless hours spent chasing down functions and arrays, and trying to change their output with trial-and-error.
For a hardcore developer, this is the province of the “theming layer”, a part of the Drupal architecture that produces HTML output. The underlying assumption of Drupal is that “themers”, or those working in the theming layer have strong PHP skills, and are comfortable with the Drupal API and all of its functions. In fact, an entire industry has sprung up for themers, and it’s not uncommon to see ads for themer positions in the job boards.
The high skill level required for theming drastically changes the economics of using Drupal, and not very favorably at that. Most independent designers and small boutiques have creative talent that is quite comfortable working with front-end code, as long as that’s limited to HTML, CSS, and very light PHP. These designers and these firms are the very sweet spot of the WordPress community.
For a design firm in a grinding recession, economics force a grim choice: scale down your projects and designs to work with WordPress, or share your slimmed-down budget by partnering with a development firm. There’s also a third choice of hiring an in-house Drupal developer, but that’s not an option in every geographic area, and it involves maintaining significant overhead in an economic downturn.
As a creative director, partnering with developers changes my experience from working directly on a site to the equivalent of slipping notes under the door. It’s a huge loss of efficiency and control over the process, and creative direction is likely to become far less ambitious as a result. It’s also far less profitable.
As WordPress and other CMS’s evolve and add on more of Drupal’s functionality, the choice will be less dire for a design firm – but it will put brakes on Drupal’s further growth in the creative community.
How can the Drupal community respond?
When released, Drupal 7 will have many usability improvements built into the user interface. For those hungry to experience those improvements today, the Admin module created by Development Seed is a very strong step in the right direction.
A better UI will make Drupal a far better experience for those managing a Drupal site, or for those with very limited site development skills. However, it does not address the challenge of working in Drupal’s theme layer.
Drupal’s mantra is “don’t hack core”. This means that all changes to HTML output need to be handled by overwriting functions and code in the theme layer. Currently, much of that code is absent from the theme layer and a site builder (that could be a designer, themer, or developer) needs to go to through Drupal’s modules or to http://api.drupal.org to track down those functions. Hours or days of research and trial-and-error can slip by before a solution or compromise can be found.
Drupal could make the process far simpler by changing how its theme layer is packaged and presented to the site builder. Each module or theme should be distributed with an embedded library of code snippets, functions, and templates in an easily-removed /FOR_THEMERS folder.
Think of all those design feature requests that go into the Drupal issue queue and are routinely brushed off with “that could be addressed in the theme layer”. These could be used as vital feedback into what people are trying to accomplish with Drupal, and could be the basis for what gets packaged with the module.
What’s a “duh” function to a Drupal core developer is a lifeline to a designer or a novice.
A poor return on design investment?
Drupal has made other investments toward usability and improved design, but these have been very limited in scope. Like a city that builds a single subway line, its investment may be doomed to failure because it’s failed to achieve a critical mass.
If Drupal is to embrace the creative community, time is slipping away. It needs to address the needs of the designers that don’t attend Drupal conferences and meetups. The ones that have quietly chosen to go with other solutions, or who have scaled down their ambitions.
It may require a cultural change in the community, and that change will have to come from the very top. It’s time for founder Dries Buytaert to choose to lead the community aggressively to embrace design, or simply keep Drupal on its developer-centric path.