By the end of DrupalCon Chicago 2011, one concept had managed to weave its way throughout the three days of talks and presentations, hinting at where Drupal (news, site) is heading as both a community, and a project. Here's the synthesis, as I interpreted it.

Ecosystems, not Features

During the opening keynote, Drupal founder Dries Buytaert said that the future is about more than features. If people have a choice between two equally capable platforms, he feels that they're going to choose the one with the best ecosystem.

When it comes to software like a Web CMS, its ecosystem consists of the supporting framework for both users and developers. So, the quality and quantity of developer's tools and the availability of something like an app store both play significant roles in the ecosystems' strength.

Developer Tools and Processes

Note that he said tools for developers. A strong community is an important, even vital, component of any open source project. It's the size and enthusiasm of the project's community that gives birth to thousands of modules and extensions. But if it's onerous and unpleasant to code for the project, let alone get your work submitted and accepted, adoption won't grow.

Buytaert discussed the project's GitHub (Git) integration as essential for improving their developer ecosystem, along with a new project hierarchy to prevent one or two people from becoming bottlenecks. The way he envisions Drupal 8 being developed might work something like this:

  1. The developer codes in a Git sandbox, which pulls the Drupal source code into a private environment where they can make changes without affecting the official code
  2. When they submit changes, their code goes through automated bug testing, whether they're working on Drupal's core or on a module
  3. If there are no critical bugs, their code goes through automated accessibility testing to ensure that accessible UI guidelines are followed
  4. If the code passes this test, it's sent to the initiative owners, who will examine the changes for performance, usability, documentation, or whatever issue that particular owner is in charge of
  5. The initiative owners will send back comments and suggestions, giving the developer more of a feedback loop than they've had in the past
  6. The developer iterates through this process until their changes are merged into the main tree

This type of structure has worked well for Linux kernel developers for years, offering a good balance between hierarchy and egalitarian development. It could work well for a project as complex as Drupal, too.

Let There be an App Store, Maybe

Mention a Drupal app store and you get one of two reactions: raw excitement, or raw puzzlement. Many of the puzzled people just don't see the point. "Can't you get all of your modules from", they might ask. The excited folks tend to fixate on a particular aspect, like easy installs or new business models.

While yes, you can get your modules at, you can't add them with the ease of something like Apple's app store. Back in August, Ravish at discussed some of the challenges that those new to Drupal face, such as a steep learning curve and too many modules that need to be modified in order to work. An app store would force, in a way, a move toward a simplified experience, with modules designed to easily plug into an existing site. Doing so requires a different approach to module development, but that's not a bad thing.

Companies like Phase 2 Technology (news, site) are already experimenting with this model, building app browser functionality into OpenPublic. They've invited anyone who wants to participate in their experiment to look at the OpenPublic app modules already are in place, and use those as examples to add to the pool. Doing this will help everyone understand what's really involved in approaching modules in this way, and will suggest some best practices to go along with it.

Business Models and Popularity

Everyone needs to eat. Walking the show floor made it obvious that plenty of companies survive selling Drupal services such as hosting, site building and custom development. But what about things like premium themes and modules? Selling these for GPL-based projects can be challenging, since you can't restrict what someone can do with the code. However, communities like WordPress and Joomla both manage it.

Ravish pointed out that "Today, the state of Drupal is like WordPress was in 2007," which was when premium WordPress products started to appear. He states that this market contributed to WordPress's wide adoption today, in part because the number and quality of free themes and modules increased along with the pay ones. But whether WordPress has an app store is up for debate. It's easy to install free themes and plugins through the WordPress administrative interface, but you can't always use it for the commercial ones.

So can Drupal do them one better? Should Drupal move in that direction? After all, Drupal is more of a platform than a turn-key product. It's easy to argue that app stores and premium add-ons are a natural fit.

What do you think? Let us know in the comments.