Taking a more focused approach to Drupal 8 development

Last night, as I read through the conversation that is happening on the "Make core maintainable" issue (http://drupal.org/node/1255674), I couldn't help but feel that while this conversation is important, it may be the wrong conversation to be having at this time. I am glad this conversation has continued coming out of DrupalCon London, but I feel like we haven't answered the fundamental question of "what is Drupal?", which may help steer the conversation in a direction that will help us select the features that really need to be in core. I posed the question to Dries at the conference, and was surprised when he stated Drupal is "a product, a framework, and a community." I mean this as no critique of Dries' vision of the platform, but I felt like that answer was really vague and needs further definition given the maturity of the project, and, looking a the open source CMS landscape, the competitive disadvantage we are in due to our lack of positioning.

The current debate about whether to remove some of the core modules (Aggregator, Blog, Book, Color, Contact, Dashboard, Forum, Overlay, PHP Filter, Profile, Shortcut, Statistics, Toolbar, Tracker, Trigger, and Poll), seems to stem from the question of whether Drupal is a framework or a content management system. The argument can be made that it is both, and there are valid reasons why we might want it to remain that way. There is something to be said about having a platform that is flexible and extensible, and will evolve as the content management needs of the user evolve. Many proprietary systems don't offer this level of extensibility. BUT, being flexible and extensible can mean many things depending on who we are targeting as our primary user audience/demographic.

Let's use Wordpress as an example. Wordpress is a full featured content management system that offers an amazing assortment of full featured plugins that meet the use cases of end users. Wordpress.org states:

WordPress started as just a blogging system, but has evolved to be used as full content management system and so much more through the thousands of plugins, widgets, and themes, WordPress is limited only by your imagination. (And tech chops.)

The Wordpress community has set the expectation for a person who is looking to download the software that they are going to get a system that has primarily been used for blogging, but is a full featured content management system out of the box which can be used for more. So, I know when I download and install this system, I will be getting a full featured content management system.

Let's look at Drupal in contrast:

Drupal is a free software package that allows you to easily organize, manage and publish your content, with an endless variety of customization.

We do not clearly state what Drupal is. The above description could be a document management system, a CMS, a social CMS, an online community platform, a blogging tool, or what have you. We also set false expectations that it allows you to "easily organize, manage, and publish" because Drupal doesn't exactly do this out of the box.

The Wordpress project has done a good job at staying focused on what they are trying to be and what features they are trying to offer. The platform is quickly evolving into a full featured content management system that is easy to use for people managing websites. Their target audience for the platform is the website manager. While designers and developers probably make up the bulk of their community, the software is designed with a specific user demographic in mind.

I would argue that to date, Drupal's primary user demographic has been developers. While people can download the software and create websites themselves, the system has really been a base platform for building more robust solutions, providing a lot of the core features a developer building content management solutions needs (a UI, content administration, user management, content categorization, menu system, etc.). With things such as the D7UX initiative, we seem to desire moving in the direction of making website managers our primary user audience, but we are putting lipstick on a pig. Instead of providing the features website managers need to run websites, we but a new user interface on a system who's target user audience is still developers.

Rather than debate which modules go into core, I think we need to seriously step back and determine a clear direction for the project. There are some great proposals out there, but by continuing to develop the platform while figuring out what it is, we are building a house in a hurricane. We will continue to have these debates and frustrations, and, quite frankly, we will continue to waste precious, donated time on developing platform features which are not adding any real value to the platform.

Secondly, we need to make a distinction between features which create an experience for end users of the website being built and features which are needed by the website developer or website administrator. This is important, because if we are truly seeking to build a content management system which is feature rich or a framework for building content management solutions, we will find that modules such as blog, forum, and poll, really don't add much value to either developers or website managers. The experience I get when I install Wordpress or Joomla is what I would expect from a content management system. When installing Drupal, my expectations are not really met because there is a mix match of features targeted at the website manager/developer and at the end user. Depending on my needs, I most likely will never use the features targeted at creating an end user experience. These are things that are specific to each project, and are better left to the strategist/designer/developer to determine. We should just seek to empower them with the tools they need to create that experience.

The value that Joomla and Wordpress provide to website developers and website managers is not that they come out of the box ready to run a website. They don't. They provide some tools that make it easier to build a website (i.e. Wordpress comes with some themes out of the box that create a blog experience for the end user). Just like Drupal, there is still a level of configuration that needs to be done with these other systems. The value that these platforms add is that they have identified the core features they feel their target user audience, not the end users of websites, need and have continually developed those core features, only adding news ones as the needs of their target user audience evolve.

Looking at the modules which we are currently discussing removing from core, these can be separated based on the experience which they add to:

Provide End User Experience:

• Blog
• Book
• Contact
• Forum
• Profile
• Poll

Provide Website Manager Experience:

• Aggregator
• Color
• Dashboard
• Overlay
• Shortcut
• Statistics
• Toolbar

Provide Developer Experience:

• PHP Filter
• Tracker
• Trigger

There is overlap, as some of the modules that primarily provide and end user experience also provide an an experience for website managers, such as forum module. We will find in some cases overlap is needed. But we should focus on providing an experience for our primary user audience, and only provide that secondary experience as needed. In example, we need to create a primary experience which allows website managers to manage users, but secondarily provide a way for end users to register on the website.

So, the question I pose to you all is: who is our primary user audience/demographic for Drupal? If we approach this through the lens of our primary user audience being website administrators, we aren't focusing on building the right set of features for the platform.

When you install Wordpress, Joomla, Expression Engine, or other comparable open source content management systems, you don't have a bunch of front end features crammed into the system, such as community forums, multi-user blogs, etc. You get robust backend administration tools that get website managers started, and just the necessary tools they need build the end user experience. They put the onus on the website builder to create the end user experience they want. That is the way things should be.

Rather than make assumptions about the needs of our primary user audience, we should perform a formal assessment to see what the core features are that they look for in a content management system; perform a competitive analysis to see what other open source content management systems are offering and how; and then perform a gap analysis to determine what is missing from core that we need to include in order to make it possible for our user audience to effectively use the platform in the way they intend to.

Let's also make a distinction between features for front end users and the features that empower website managers or developers. Dries' comment on the "Make core maintainable" issue (http://drupal.org/node/1255674#comment-4917848) recommended some of these - etter media/asset management tools, WYSIWYG, mobile support, more UX improvement and content staging. I think these were made through the lens that our target user audience is website managers, which may be fine if that is who we are in fact target.

Looking at Dries' recommendation, you can see the distinction between features that provide tools for website managers to be able to effectively create and manage content, versus features that provide front facing functionality for end users. I would argue that a module that provides an experience for an end user should never make it into core. Again, the line can get blurry because each of the end user-focused modules (such as blog and forum) provide some website administration functionality, but the primary user audience is end users. We need to stay focused on providing features for our primary user audience.

To sum up my thoughts:

1. We need a better definition of what Drupal is (i.e. "Drupal is a framework for building content management solutions" or "Drupal is a flexible, full featured content management system that allows people to manage a website out of the box").
2. We need to define who our target user audience/demographic is. Are we targeting developers who are building robust content management solutions for clients? Or are we targeting non-technical people who need something they can easily install to run their website and possibly extend with some plugins to add full-featured functionality? We cannot be all things to all people. It dilutes our product and brand.
3. We need to really understand what the needs are of the primary user audience/demographic we are trying to reach. This will define what is needed in the core. Much of the conversation currently happening around what modules need to go into core are based on opinions or people's experiences building Drupal websites, which can be rather narrow depending on who they service or their personal motivations. We will be targeting a very large group of people who we want to use Drupal and join the community, which requires that we first provide them with the tools we know they need, not the one's we think they want or that we individually think are useful.
4. Once we have that clearer definition/vision of the n state for Drupal, we should start developing a roadmap to take us from where we are towards that vision. As an example, we may not need a WYSIWYG in core if we are driving Drupal to be more of a framework with a series of install profiles people can download to meet their specific use cases

Having that vision will help prevent diminish the current frustrations in the community. While I don't think this process will solve all our problems, and I don't think it will prevent future frustrations and disappointments, it will at least give people a consistent lens through which we look at the project when we have conversations about the direction Drupal is going in and provide a framework by which we evaluate and prioritize core development.

I hope people do not take offense to any of this, as it is not meant to be a critique or slap in the face to anyone. These are my thoughts which I hope others appreciate and/or agree with, and help to possibly change the way we approach planning for the Drupal project.