8 steps for Drupal 8

The Drupal 7 code freeze triggered a lot of retrospective about Drupal core, and the Drupal core development model. Some of these discussions are collectively referred to as "smallcore".

While I'd prefer to postpone such a retrospective until after Drupal 7 is released and we're about to open up the Drupal 8 development branch, the discussion is already beginning on the web, and it is my responsibility to internalize people's thoughts and recommendations.

I've brainstormed about this a lot the last couple of weeks, and talked about it with various people. In this post, I propose 8 steps to help improve Drupal core development going forward. Some of these steps make Drupal better for end-users, some of these steps make Drupal better for developers, and other steps focus on making Drupal a better product. They might not address every concern that has been raised, but I hope they make for a good start and that they provide some focus.

We'll obviously have more thinking and brainstorming to do about Drupal 8. I'd like to thank everyone for their suggestions, for bearing with some of the growing pains, and for helping us raise our game. It is what makes Drupal so great.

The 8 steps are as follows:

  1. Create better separation between framework and product
  2. Grow Drupal by making it a better product
  3. Select two strategic co-maintainers
  4. Distributions could help, if we do them right
  5. Experiment with distributed revision control systems
  6. Backport small changes to stable releases
  7. Continue to streamline the patch review process
  8. Aim for a shorter release cycle

Step 1: Create better separation between framework and product

As people start to build more products on top of Drupal, it is important that Drupal doesn't get in the way, and that it provides the flexibility and ease of customization for Drupal distribution builders. Drupal has always been king of flexibility, and missing or poorly designed APIs have always been considered and treated as bugs.

The current state of affairs is that, while Drupal is super-flexible, we do have some hard-coded assumptions, and not everything can be reused or replaced. Clearly the work on improving our APIs needs to continue, and creating better separation between the framework and the product will continue to be one of our goals during the Drupal 8 release cycle.

Over-engineering is a real threat though. When people fall in love with framework design, they tend to decouple everything, abstracting it up, down, and sideways. Before you know it, you end up with abstractions that make Drupal harder to develop for, and that could make Drupal a lot slower. When looking for a Drupal 8 co-maintainer, I'll look for someone who can help us walk this fine line. More on co-maintainers below.

I also don't like the term "smallcore" as a term for this work. First, the term seems to drive a wedge in the community -- which I don't support. Second, the term is misleading and deceptive as core is more likely to get bigger as we improve our APIs, add more subsystems and potentially add more features. Third, the term alarms people who see the value in having a strong Drupal product, as it sounds antithetical to that goal. Let's stop saying "smallcore".

Step 2: Grow Drupal by making it a better product

Drupal 7 became more mature as a framework but it is also shipping with new features, as well as a lot of usability improvements that help make Drupal easier to use for content editors and site builders. A number of people are wondering how to undo some of the usability changes, and now dream about an "easy to undo" CMS. Making the framework better is a great goal, but not at the expense of our users.

The single biggest barrier to the success of Drupal is its ease of use. This is repeatedly shown in studies, competitive comparisons and blog posts. The broader market is impeded by Drupal's usability, and not with the fact that Drupal isn't a good framework. It is a fact. This is why usability was the primary focus of Drupal 7, why I decided to hire Mark Boulton, and why this is worth making some trade-offs for.

To focus only on the power and flexibility of the framework mainly serves to keep the Drupal insiders happy, while the market and customer base passes them by to adopt tools that do not need their specialized skills because other products solve the market's needs out of the box.

There is a long history of how successful software projects evolve. In the end, there is only ever one winner in a market segment, and typically one runner-up. Everyone else becomes irrelevant in the big picture. This is true for desktop systems (Microsoft/Apple), server systems (Unix-Linux/Microsoft), ERP systems (SAP/Oracle), databases (Oracle/Microsoft) and so on ... It is what will happen in the CMS market too. My goal as the project lead, is to lead Drupal to become the dominant web platform. We do not want Drupal to be irrelevant.

We should all agree that at the end of the day, success should be measured by the number of people working with Drupal, not by the number of people working on Drupal.

A lot of the motivation for current discussions comes from frustrations with the core development process. I would like to shift the discussion, reframe the conversation, and focus on our goal to make Drupal the number one web platform. Fortunately, creating a better separation between the framework and the product aligns with that goal, but just focusing on making the framework better won't make us succeed. We should focus on making Drupal core a better and easier to use product as that is the number one barrier for Drupal's wider adoption.

We cannot afford to let Drupal remain a niche platform. Any user or organization that depends on Drupal also depends on Drupal's ability to grow. Failing to grow and improve will mean that the easier-to-use CMS competition will pass Drupal by as those products mature. This is what I called the The Ockham's Razor Principle of Content Management Systems back in 2006 and why I'm obsessed with driving both innovation and usability -- even if they sometimes seem to be at odds. I feel very strong about that vision, and can only conclude that so far, it has worked -- we've come a really long way since 2006.

If we want Drupal to be relevant longer term, it needs to be a capable, robust product that people can use out of the box. Distributions can exist to meet different market segments, but they need to build on the usability patterns set by Drupal core, as that is how we lower the total cost and risk of adoption of Drupal solutions.

Step 3: Select two strategic co-maintainers

Every Drupal release has had one or more targets for improvement. Drupal 5 focused on the installer, Drupal 6 focused on internationalization, and Drupal 7 focused on usability. Why? Neil Drumm (Drupal 5 co-maintainer) cared deeply about the installer, Gábor Hojtsy (Drupal 6 co-maintainer) was and still is passionate about internationalization, and Angie "webchick" Byron (Drupal 7 co-maintainer) cares deeply about usability. This isn't a coincidence -- I picked them with strategic objectives in mind.

I think Drupal 8 needs to have two general areas of focus, as reflected by "Step 1: Create better separation between framework and product ". To this end I am considering picking a Core framework co-maintainer and a Core product co-maintainer. The role of the Framework co-maintainer would be to tend to APIs and base level tools, and help steer us to our goal of achieving better separation between the framework and the product. The role of the Product co-maintainer would be to make Drupal the best CMS in the world, by increasing usability and adding and improving features. My role in this plan is to assist and manage both co-maintainers, and to help with decision making, vision and product management.

By picking and empowering two people, and assigning them separate areas of responsibility, all the while coordinating with both of them to guarantee a unified product at the end of the day, I hope to increase the velocity of development for the Drupal 8 release cycle. I also intend to accomplish the goal of making Drupal easier to use, more feature rich, and at the same time more architecturally flexible.

When looking for Drupal 8 Framework and Product co-maintainers, I'll look for people who share that same vision -- but who challenge me at the same time. A number of people come to mind, but is too early to share my current thinking. Watching people during the code freeze is a very important part of the recruiting process. After all, managing bug fixes, saying "no", and stabilizing the code base will end up being a critical part of any co-maintainer's job, especially after the development phase when the branch goes into maintenance mode.

Step 4: Distributions could help, if we do them right

So how do we improve Drupal as a product? We've had Drupal distributions since the Drupal 4.6 era and I first wrote about the potential of Drupal distributions in 2005. Drupal distributions have great potential -- turnkey solutions help us compete in new and different markets, something that could help Drupal become a significant player. The number of verticals is nearly unlimited and the opportunities are numerous.

There is a risk involved with distributions as well, which means that we need to approach them the right way. The risk is fragmentation, and it is why I feel it is important that distributions build on the usability patterns set by Drupal core. Distributions will be most helpful if they are tools that give you a head start towards building a particular type of Drupal site. Distributions that steal focus away from Drupal, or become hard to administer and extend using Drupal core usability patterns, will lead to fragmentation.

Drupal has a lot of momentum today, but we are still a niche player in the bigger CMS market. Drupal feels bigs, but we're still small. If by enabling more distributions all we do is create a lot of inconsistent niche products, some of which will be competing with one another, the Drupal project will lose momentum. If we can build competitive distributions that strengthen and accelerate the shared Drupal brand by using shared design patterns and user experience, we'll win.

Another risk is that small incompatibilities among distributions can drive distributions further and further apart. When distributions start building their own communities of contributors, having their own issue queues, all disconnected from drupal.org, then we have a problem. The difference between a distribution and a fork can be subtle. A proliferation of incompatible, incomplete and disconnected distributions could quickly become problematic. It would make it a lot harder for all of us to support and market Drupal.

We have written a lot of the the packaging scripts needed to put distributions together for Drupal.org, but we haven't decided yet how we want to use it and what a winning strategy could look like. What remains is a strategy discussion, not a technical discussion.

As a community, we have to take responsibility, and make sure that distributions collaborate rather than compete, much like the way that we attempt to work together on modules. That starts by centralizing all the code on drupal.org, by making Drupal core flexible enough, but also by encouraging shared design patterns and user experience. With distributions, community responsibility and leadership becomes even more important. Building one product is hard. Building a set of products in a way that strengthens and accelerates Drupal is much, much harder.

Step 5: Experiment with distributed revision control systems

If the road to success is making Drupal a better product (along with making it a better framework), we need to be able to add new features to Drupal core.

Some features in Drupal core, like forums, blogs, polls and aggregator, haven't evolved as fast as the Drupal framework itself. For many people these modules are fine as they are, but more advanced alternatives have emerged in the contributed module repository. It begs the question: should we advance the modules in core or are they sufficient for 80% of our users? But also; are there any modules that we should be adding to core to make Drupal a better product?

I think we should advance those modules, and add some more. This is what I want the Product co-maintainer to help me with.

Giving more CVS write accounts or splitting core in smaller projects could help those modules advance faster, but it will also hurt us. A much better implementation to accomplish the same goal seems to be to experiment with distributed revision control systems. There are various technical issues to sort out to make this feasible, but I think it is worth the experiment because it will allow us to interact in new ways; ways that empower individual contributors, ways that allow people to self-organize around features, and that enable me to pull in bigger changes in a controlled fashion so we maintain consistency, quality and vision. To do it in a way that I'm comfortable with, it will require a significant investment in the project module and the Drupal.org infrastructure though.

In other words, I see myself experimenting with a distributed revision control system like Git or bzr. Not immediately, but somewhere in the Drupal 8 development cycle. Right now, I want everyone to be laser focused on getting Drupal 7 out. At least initially, I'd want the CVS repository to be the main, canonical repository from which Drupal core is packaged. However, I'd additionally pull in changes through Git/bzr for some period of time, to help decide if Git/bzr is what we want.

Step 6: Backport small changes to stable releases

Some people suggested that the framework and the product could move at different speeds. I am uncomfortable with that concept.

Feature development drives API advancements. API improvements drive new and better features. It's an important feedback loop. My conviction is that feature development and API development are so related that it would be detrimental to try to do them asynchronously. Drupal's APIs have been changing for 10 years and there is no reason to believe that they will all be stable one day.

That said, there might be certain changes, like smaller usability improvements, standalone features, or new hooks that don't break existing code, that could be backported to previous Drupal releases during the development cycle. Of course the changes cannot break any code or invalidate existing documentation, but I think having a good test harness will help. Going forward, I'd be comfortable backporting certain changes that help Drupal advance, as long it is transparent to existing Drupal installations.

Step 7: Continue to streamline the patch review process

A key problem still seems to be that it is difficult to get solid patch reviews, making it slow for some patches to get committed. Finding solid reviewers is hard, especially as Drupal becomes more advanced. I still believe this is a primary source of frustration, and that we should continue to streamline the patch review process.

We've introduced new rules in the patch review process lately (e.g. wrapping at 80 character length, formatting of PHPdoc, capitalization rules, etc). The proliferation of rules makes it more difficult to get your patch in. As a frequent reviewer and committer, I've found that code-style reviews, while important, can add quite some noise to an issue, and that it can derail API and architecture review.

One way to streamline the patch review process is to automate code style reviews just like we automated testing -- at least to the extend possible because coding standards can be both complex and subtle. In an ideal world, code style reviews would take almost no comments, and would be reduced to a green or red status message just like with our automated testing. It could reduce the size of the 'needs review' queue further to things which actually merit review etc. By doing so, it would provide more focus, and help improve our velocity.

It doesn't necessarily solve the problem that one can't find enough good reviewers for one's patch but I think it will help.

Step 8: Aim for a shorter release cycle

There is a sentiment amongst developers that the Drupal 7 core release cycles was too long. It can make it frustrating to contribute to Drupal core development. Who wants to work on a feature that might not be used in production for another 18 to 24 months? Near the end of the code freeze, things heat up, and people submit a lot more patches. In other words, shorter release cycles could make it more compelling to contribute.

At the same time, I don't think the Drupal 7 release cycle was too long, per se. A lot of the big new features, such as the new database abstraction layer and Field API (formerly known as Content Construction Kit (CCK)), took several months of work, and many months more to be usable. We finished converting code to the new database abstraction layer over a year after the initial commit. Drupal 7's Field API is probably the biggest architectural change in the last 5 years -- it will take a couple more major releases for Field API to be truly integrated into Drupal. In other words, sometimes we need a longer release cycle to allow for big, game-changing changes.

How long the Drupal 8 release cycle will be I can't say yet, but let's aim for a shorter release cycle. The length of the release cycle depends on how fast Drupal 7 is adopted, how fast the contributed modules reach the "plateau of productivity", and how fast Drupal 8 shapes up to be a great release. You don't want it to be too long, but you don't want it to be too short, either. Furthermore, as a goal, the length of the release cycle shouldn't trump the larger, overarching goals of any given release. I'll take constant temperature of where we are and balance all the different pros and cons (eg. innovation versus stability).

Another adjustment to the release cycle could be separate code freezes for the Framework (APIs) and the Product (user features and usability). The Framework/API freeze would precede the Product/CMS freeze, and would let us focus on establishing the underlying changes earlier in the overall cycle, with focus shifting to features and usability later in the cycle. This will make feature development easier as the APIs will not be shifting around as much, and it will give a period of time after the Framework freeze where we can focus on bugfixing and performance improving the Framework, even while new features are still being developed.

Some closing thoughts

The 8 steps outlined above describe actions and steps that we can take to help make Drupal 8 rock. As we look forward to Drupal 8 development, I think it is important to focus on the right things. If we want Drupal to win and prevent Drupal from being stuck as a small player in the bigger picture, we need to focus on making Drupal easier to use for both end-users and developers, while maintaining our innovative edge. Some of these 8 steps make Drupal better for end-users, some of these steps make Drupal better for developers and some of these steps make Drupal a better product. I truly believe we can all win.


David Stuart (not verified):

Hi Dries,

Re point 8, I am happy with shorter release cycles but believe this will only work if you support older versions for a longer period of time. As Drupal is adopted by larger projects the cost of upgrading to new releases is very expensive (unless you introduce more of a backward compatibility component). My current client is a large UK Government Department and we are in the process of upgrading to Drupal 6 and if Drupal 7 had been released when it was originally intended we would have been live with a unsupported release which wouldn't have really been acceptable from a compliance perspective.



alexanderpas (not verified):

I agree with David Stuart here, we should ensure that we never get more than 1 release/year, however I think a release cycle of 18 months is ideal.

This gives a new version every 18 months, which i think is ideal. (Drupal 6 was too soon, Drupal 7 will be too late, yet the Drupal 5 to 7 will be close to this.)

Also, this ensures that developers will have the time to develop with the best version of Drupal available, and don't have to start updating right away when their year-long project is finished.

Dries already made a post about this:

Dominik Lukes (not verified):

How about adopting a variation on the Ubuntu LTS model. For instance, there are so many Drupal 5 sites still in existence that it would be really useful if the support for Drupal 5 went at least for 3-6 months beyond the release of Drupal 7. That way sites could plan to go straight from 5 to 7 (using the 6 intermediate stage only for conversion not actual release). I think a lot of the medium-size sites will be quite keen to skip versions (they're too big to convert painlessly but too small to have the resources for a major upgrade with every new version).

Elijah Lynn (not verified):

I like the idea of extending support for 3-6 months after the release and the sites being able to skip straight from 5-7 or 6-8 etc.

arhak (not verified):

6 months wouldn't be time enough to know if the modules you'll need will be actually migrated or have an alternative to count on

Chris Johnson (not verified):

Some institutions move even more slowly. We (my employer) support a large number of U.S government and international organization web portals, most of which are still on Drupal 4.7. I even recently migrated a couple of sites off 4.6! We have upgrade plans in place for a large number of these sites to move to Drupal 6 (skipping D5). Drupal 7 won't even be considered for another year.

Upgrading is an expensive proposition for these kinds of sites, in addition to the traditional bureaucratic slowness of such organizations. Most of them are translated into 5 languages, with training materials and printed documentation as well. Also, there are the using programs registrars, trainers, etc. All have to educated, rewritten, updated, etc. to match the new software.

So support for previous releases is important to us. Personally, I like the idea of smaller, shorter release cycles, if support for earlier releases can be extended.

Magnity (not verified):

Sounds like a roadmap to have, and it is good to be fairly generic at this stage so that individuals can add innovations in their own area.

However, views in core - it could have been mentioned but wasn't... even a vague suggestion of whether it would be approved of.

Matt Farina (not verified):

Dries, you might want to consider checking out Mercurial as well as Git/Bzr. When it comes to GUIs (like on a Mac) and some other things it's ahead of Bzr/Git. The stuff a casual developer/themer cares about.

Garrett Albright (not verified):

I second this - Mercurial should definitely be considered, especially with regards to its relative ease-of-use. We already have a problem where some developers and themers who want to share with the community are hitting a wall with trying to figure out how to use CVS. Choosing Mercurial may be a small step to helping alleviate that problem, and an even bigger step when graphical tools are considered.

John Vandervort (not verified):

For true multi-platform, there are only two choices. For performance and nice gui tools, only one of those works well. Mercurial. I do like bzr too and git less so. All three are worlds better than cvs/svn.

arhak (not verified):

in addition:
- Mercurial over HTTP beats Bzr/Git
- it is almost as Python as Bzr
- it is almost as fast as Git
- it uses changeset/snapshot accordingly to the change's volume

John Vandervort (not verified):

Also, don't forget the huge advantage of Mercurial Queues when dealing with rerolling patches and patch integration.

chx (not verified):

Trying bzr (or git if you must ;) ) is a great idea. I so agree with you on not liking smallcore. Two co-maintainers, well, I wanted more but two is more than what we have now, so that's good too. And shorter dev cycles, that's cool also. It would help if we would know a little bit more (just HOW short? 6 months? 18 months?).

adrinux (not verified):

I'm happy to see you finally addressing the issues raised in #smallcore :)
Even happier to see you starting to embrace it. And agree with most of your thoughts here. I think we're all largely on the same wavelength, but haven't realised it yet.

As for names, yes, smallcore does seem to have acquired a lot of negative baggage, framework seems to be what you've used in this post. Let it be #framework and Drupal CMS from now on. Though frankly people will become just as alarmed by #framework as #smallcore because they'll make exactly the same incorrect assumptions, what it's called matters a lot less than how it's defined IMO.
FWIW I dislike your use of 'Product', Acquia Drupal is a product, Drupal is open source software. Conceptually thinking of Drupal as a product is useful, constantly referring to it as one isn't all that helpful.

Some quibbles though, largely straw men you seem to be erecting for the sake of saying something negative and misunderstandings:
When people fall in love with framework design, they tend to decouple everything, abstracting it up, down, and sideways.
True but most of the people I've heard talking about #framework are fully aware of this problem. No one is suggesting building Druplone.

A number of people are wondering how to undo some of the usability changes, and now dream about an "easy to undo" CMS. Making the framework better is a great goal, but not at the expense of our users.
You're assuming that D7's changes meet everyone's needs and workflow. They don't. They can't. People want to be able to more easily focus their site workflow and UX on their specific use cases and audiences. This is why they talk about 'undoing' changes. You're misconstruing their desire to further improve UX as a desire to degrade UX, it's not.
[well, ok, a few people always want to undo change until they get used to it, but we can agree to ignore them ;) ]

Some people suggested that the framework and the product could move at different speeds. I am uncomfortable with that concept. seems to contradict Another adjustment to the release cycle could be separate code freezes for the Framework (APIs) and the Product (user features and usability).
Surely those are in effect the same thing? Further to that though, what you're suggesting as that all distributions will have to wait for a Drupal CMS release before they can release. That's not a recipe for encouraging distro's to stay on the drupal.org dev platform. 'Two speed' doesn't mean the framework has to race away from the CMS, it just recognizes that there is some decoupling between them.

catch (not verified):

Decoupling means a unified release schedule for at least the Drupal 8 release cycle - because precisely the problem we have at the moment, is that many of our APIs, their implementations, and the UIs relating to them are very closely tied together. To clear that up means massive changes to to all of these.

A decent example for this in Drupal 7, was the rdf patch (http://drupal.org/node/493030) - where an optional module was able to take advantage of brand new APIs added in Drupal 7 - the fledgling entity API, renderables, fields in core, theme system changes etc. This resulted in a very nice, clean implementation of RDF which is almost entirely self-contained in an optional module - this was only possible by deep API changes elsewhere over a period of several months. Trying to do this retrospectively for existing modules like node, comment, profile is a magnitude harder due to needing to support existing feature set and user base.

Having said that, feature freeze / code slush was one of the best things about the Drupal 7 release cycle, although it took a while to get going since it was new and unexpected. If we could somehow bake that concept into the Drupal 8 cycle (start with API thaw, then staggered API/feature freezes and slushes after that?), it might really help with some of these tasks.

However the idea that the APIs (since at the moment there's no separate framework to speak of that can be neatly separated, and that's a long way of) could be frozen a long period before Drupal CMS gets released, that's very dangerous - it's only when we get to widespread user-testing during RC and actual site deployments (which used to include Drupal.org up until Drupal 6), that all kinds of nasty bugs, performance bottlenecks etc. get found - many of which may require API changes on some level. Automated testing can replace some of that, but by no means all of it, and it could be a very costly thing to lose.

David Rothstein (not verified):

You're assuming that D7's changes meet everyone's needs and workflow. They don't. They can't. People want to be able to more easily focus their site workflow and UX on their specific use cases and audiences. This is why they talk about 'undoing' changes.

It's always easier to build a user interface for a very targeted audience or very specific purpose. Drupal already (mostly) lets you do that.

But in Drupal core, the challenge is whether we can build up a set of common interfaces that improve the user experience for everyone and that can be extended upon (rather than completely replaced) to specialize to different audiences. That's hard, but it's worth doing. If everyone goes off and builds their own, it will never happen.

Sina Salek (not verified):

Drupal is getting bigger and bigger with every release. It's really nice to see that Drupal's leader has a good understanding of both the Drupal itself and the community.

I enjoyed reading this post, hope to see all this steps in action. Maybe one day they make it possible even for busy people like me to join core development ;)

Keep up the good work Dries.

Daniel Lewis (not verified):

I like the idea of separating the co-maintainers into Framework and Product. I'm sure we'd get a lot more from something which has had a focus on APIs by an API expert and on CMS Products by a CMS product expert. It's good :-)

I am wondering how Drupal will continue to stay in the same evolutionary line as the web... although we could also see it that Drupal is a contributing factor to how the web evolves. They are some of my thoughts.



Joshua Jabbour (not verified):

I'm excited you're considering a DVCS for Drupal development... I don't think it can be overestimated how big a difference it would make.

As a somewhat-casual Drupal developer, making it easier to work on the codebase, submit patches, and test others' changes means I get more involved. Sure, it's not incredibly difficult now, but every little bit of friction means less people who are willing to do so.

(As someone who uses git daily, I hope you go down that route... but I'm less concerned with the specifics, as any of the big three are leaps and bounds above the current system.)

And no, I don't think this will stop non-coder users from submitting patches. Obviously, we'd still accept .patch files (hopefully along with commit ids), and it's not like CVS is easy for regular users to get up-to-speed on... DVCS isn't more difficult, just different. :)

Jeff Eaton (not verified):

Thanks for taking the time to outline your thoughts on this -- while getting Drupal 7 out the door is definitely the community's top priority right now, Drupal has a long and rich history of starting the work on version Y before version X has been finished.

Because we work with an "All hands on deck, if you have an idea, start writing patches!" approach, there is no enforced post-mortem analysis for a release cycle, or planning phase for the next one. Starting the conversation about a given set of goals and priorities has to be done early rather than late, or it will quickly be overtaken by the rapid pace of change: it will become, by default, a conversation about the next dev cycle of core simply because the current one has already built up its own momentum. Even with Drupal 7's long cycle, the pace of development in the Drupal community is astonishing! There's already a RTBC patch in the queue for Drupal 8 today! If #smallcore does nothing but force careful open discussion of the next version's priorities, it's a success.

Confusion about #smallcore and what it entails is definitely an issue, but at the end of the day the name is unimportant. Whether it's called #smallcore, #framework, #bigcore or #magicponies, what matters is the work that comes out of it and its impact on the development process and the product that results. So far, I think it's proving itself nicely: good, solid patches from #smallcore have been committed to Drupal 7, are in the works for Drupal 8, and the public architectural discussions among #smallcore advocates (and detractors) have clarified a number of important Drupal problems that need solving.

The exciting part is that your post indicates that you agree with us!. At the end of the day, that's what matters and whether you or chx or Adrian or Boris or Acquia or Palantir or CNet like a particular label is irrelevant. Whether the name stays or goes, whether it is loved or hated or just misunderstood, the ideas that it captures are critical to Drupal's future health and we see eye to eye on the key ones.

The point where I think we still have a disconnect is the 'how': you've said that you feel that improving Drupal's framework and APIs is a critical goal, and I think that the diea of appointing both product and framework focused maintainers is an excellent idea. Smallcore is nothing more than an attempt to answer the question, "What constitutes 'improvement?'" Drupal has reached a point in its life where simply saying, "We need to make it better" doesn't give us any helpful direction. We need to know what goals we're trying to achieve, what audiences we are trying to focus on, and what points of pain those audiences have. Then, we need to figure out the best solutions to those needs.

I'm looking forward to the coming weeks and months as Drupal 7 'firms up' and is released, sites begin to be built with it, and early work begins on the improvements that will become Drupal 8. The conversation's already rolling, and I think it's shaping up to make for a very exciting release cycle.

Larry Garfield (not verified):

I will add an addendum here and say that part of the definition of "improvement" requires first figuring out how Drupal works. Right now, we can't explain it, it just does. :-)

By that I mean, can you summarize the entire Drupal architectural design in a meaningful way in a single page? I don't think we can right now. It's too inconsistent, too much is done via stuff layered on top of other stuff, and there's no over-arching architectural vision. Taking the framework side of Drupal to the next level, which in turn lets us take the CMS side of Drupal to the next level, means we need to whittle the Drupal Architectural Summary down to one clean, consistent, easily digestable message.

That helps us work out where there are gaps in our architectural design, work out where there are inconsistencies to be addressed, realize where we could, with a little effort, get a lot more flexibility and functionality, and dramatically improve DX and in turn lower the learning curve for new developers.

"So how does this fit into the big picture of Drupal?" is a question that shouldn't take effort to answer. Right now it takes more effort than it should. Part of the discussion needs to be "what IS Drupal's architecture", with an answer that is more robust than "when in doubt, make a hook". :-)


Cary Gordon (not verified):

It might be a reasonable idea to stagger the framework and product release cycles going forward. I think that this could benefit those who work on both core and modules.

Josh Koenig (not verified):

This is an excellent summation of the discussion. However, I think we need to be careful around this point:

We should focus on making Drupal core a better and easier to use product as that is the number one barrier for Drupal's wider adoption.

While I think core can still get a lot better in terms of usability, the real growth potential within the product space requires a great deal more market/application specificity than core can ever hope to provide. Creating a general CMS as a product is a good goal, but it's much more vital IMHO to empower creative Drupal experts to develop on top of core to create the right product for their targeted user-base.

In other words, Adrien is dead-on when he says:

You're assuming that D7's changes meet everyone's needs and workflow. They don't. They can't.

We need to be able to figure out where to apply energy here. As with performance-related changes (e.g. pressflow) there's always the danger of divergence, but I think if we keep our eye on compatibility things are going to be fine. The main concern is that Drupal itself doesn't become too dictatorial about how things are done.

That said, there are going to be real tensions as we move down this path between things that seem generally useful for core as an "out of the box" experience, but which are antithetical or counterproductive to certain "productized" scenarios.

I would like to see Drupal provide more tools for great UI, but also be more flexible in terms of how they are imposed. We should continue to implement and empower great content management UI tools like Panels, etc.

abhigupta (not verified):

Dries, I enjoyed reading your thoughts and I think they are taking Drupal towards a correct path.

I feel there are two extremes in the CMS market right now, Wordpress, being the super easy and widely used vs Plone, being super flexible but limited uses. Drupal seems to be left of center and more towards Plone then Wordpress. I think we should aim to reach close to Wordpress, so that we avoid the fate of Plone.

Having said that, I would really like to have a strong focus on increasing the performance of Drupal 8. Drupal has been getting slower and slower with every release, 5 > 6 > 7. If we continue with this trend, we will be in lot of trouble. It will be worst thing for Drupal to be labeled a slow CMS. Another PHP framework called Yii has had great success with doing lazy loading ... we should explore to see if we can implement more of it for Drupal http://www.yiiframework.com/performance

Bojhan Somers (not verified):

I will definitly agree with a lot of the points, but as "UX-guy" I feel compelled to give some thoughts. I admire the aspiration to see the Product as that which gives us growth, I feel the same way - it is in the current eco-system of user experiences where the product shines only if the framework - does to, the correct balance is more important than anything.

Although adrian raises a valid point, where D7 doesn't model for every single use case. I don't think it was ever implied it was, it would be foolish to state so. We did our best to optimize it to a large amount, making sure not to let edge cases strain to much of the optimal experience.

1. I believe over-engineering is a true problem, I face in my daily patch work on Drupal 7. There are very few, who can tackle the harder patches - even fewer who can do it with good html/css and javascript output. We need to be very aware of our resource constraint, as it is now - it will be a big issue for the Product maintainer.

4. Distributions are to me, what installation profiles should be. I believe for these to come to true value, they should work together with Core on getting it done. Not by devaluating the assumptions core makes, but by working hard to make them generic enough - that profiles can bend them to their purposes.

7. A lot could be done about the code review process, especially for design-reviews - which don't have the tools to their disposal the code-reviews do. I hope to change that for Drupal 8, and being able to demo patches is the first step to that.

From the comments, I strongly believe any decoupling in release cycle, between the Frameork and the Product - only means that we don't put them on the same standard. We need to ensure that the quality we want in code transcends to that we want in the UI, sadly that is not the case yet. I want the people that care about the UI to flourish, to be part of the discussion and not to be alienated until they can write a patch. We are still in a development-environment it will take years for design in the product to come to maturity. But with great nurture and care, comes the user experience we want, and the numbers will tell us that.

As long as we all collaborate, since we need the Framework to change for a great Product to happen, in D7 it proofed me that changing the Framework for the sake of the Product is really hard. Mostly because of lack of knowledge of the "assumptions" of the user experience.

Anonymous (not verified):

I like the length of the current release cycle. I still have a site on Drupal 5 due to its complexity, and I'm a very active maintainer of several modules totaling some 3000 users according to d.o statistics. I'll probably have my D5 site on D6 by the end of the year though, in time for it to never be unsupported.

+1 for not using "smallcore." +1 for using "framework" instead. People keep saying it doesn't matter what it's called, it's the goal that matters -- well, yeah, that's what we thought until we did usability testing for D7 and renamed most of the crap that we'd used before. Let's use the term that best describes what we're doing and what we want, and IMNSHO that term is "framework."

Having two core co-maintainers is a start, but I'd also like to see a more defined role for branch maintainers and, as sun calls them, "code gardeners." These are the people that are actually writing the code that improves Drupal. Maintainers, for the most part, just commit code, and that takes away some of the best resources our community has for driving changes forward. Empowering branch maintainers and code gardeners will inspire innovation and make the goal of shorter release cycles more realistic.

+1 for code slush... but only if the APIs on which it focuses are not pre-announced or pre-assumed. In other words, we need people to sprint both for the ordinary API deadline and for a code slush deadline in order to get in the changes that are the point of having a code slush in the first place.

Anonymous (not verified):

We want git.

I have used bzr and its super ugly.

Simon Hobbs (not verified):

I am probably in the minority when I say that winning awards, or being judged as "the best CMS product", should not be our primary goals.

I see these things as by-products (albeit very valuable by-products) of the vibrant and inclusive community that exists around Drupal.

Many people get hooked on Drupal development because it's empowering. By attracting the best people, we build everything with emphasis on quality and standards and "doing things right".

By focussing on wider acceptance and kudos, we push things into Drupal that tick boxes, even when they're sometimes half-baked. We try to do too much in a cycle, and invent things like code slush to manage the overflow.

Otherwise, I'm very glad about this announcement, a framework maintainer should help to focus attention on some of the pain-points that we experience using Drupal's APIs. Great stuff.

Robert Douglass (not verified):

The goal of the framework work should be to reduce the amount of stuff that people have to undo. Several commentators have pointed this out here and on other threads, and there is an interesting comparison of Django and Drupal where one of the Django devs says the same thing:

Clifford Ilkay: “On balance, I’d say Django is the more flexible and powerful of the two but Drupal gives the *illusion* of productivity quicker. With Django, I build up from a base, whereas with Drupal, I seem to spend an inordinate amount of time trying to figure out how to make it *not* do something I want done differently. Django is lean and simple by comparison to Drupal, which is neither lean nor simple. Both have very active and helpful communities.”

It's quite common for every even moderately customized Drupal site to have a module that exists just to have a form_alter that hides stuff.

Robbins (not verified):

Stop the release of Drupal 7 to have success of Drupal 8. As modules continue to lag behind and Drupal has no existence other than Drupal.

If you look at the cleintelle of WP and Drupal WP is used more by the mass and Drupal more by the biggies like corporates.

With social net driven sites like FB, Tw etc becoming 'monoplistic' players, Google Wave looming large in horizon and at least 5 other such lurking projects biggies will soon be having just brochure sites, simple few page html-ers, with their web presences branched out in the likes of FB, Tw, Wave. In short the clientelle or future potential of Drupal will not be needing Drupal.

The real usability problem of Drupal are two
- lack of stable API and code structure, fewer and fewer people will be less bothering about so frequent change of APIs. "Why the heck they can't make something stable?"
there's never an easy upgrade click and in the way to upgrade one has to always leave behind some favorit modules
- lack of features, example : users have no privacy controls of their stuffs by default, no useful modern features like draft, ajax unless they muddle with some incomplete modules

There is no need of public release of Drupal 7 - release Drupal 8 when it is ready.

Corni (not verified):

Well, I'm probably one of the few worried by this post. The whole emphasize on "the product", the "drupal brand", "growth" etc doesn't sound like an open source project anymore, but more like what a manager of a company would tell his employees. This is very OS unlike, and investing free time in sth which other people make money with and being treated like it's to make money with just isn't in the spirit of free software.
If you just worry about analysts like gartner, money etc this will eventually harm the overall project, because you've got a financial interest in the project your leading. You maybe should consider switching to a democratic way to develop drupal to be able to focus on money+aquia without doing any harm to the project.
There _are_ more successfull projects out there like apache which do well on the web with being democratic and imho drupal should evolve to that position as well.

Ron Northcutt (not verified):

Are you crazy? Stop Drupal 7 because no one needs it? Drupal is tough to upgrade and unstable/unusable? No APIs?

Look - for the people who have a hard time turning on a computer, Drupal is not for them.

For the average user that can do email and surfing, Drupal MAY NOT be for them... especially if they aren't interested in taking some time to learn the basics on how to administer the system.

For the advanced user (and developers), Drupal is pure gold. Its incredibly easy to use when you know a thing or two, its reliably stable for most features, and upgrading is really easy (even without Drush)... considering that each installation of Drupal is TOTALLY UNIQUE, its amazing really.

Drupal 7 is the next step in the evolution, and stopping the process now would be insane... especially when you consider how many hundreds of hours have already been contributed to the core and contributed modules/themes.

FYI - I don't consider myself a "Drupal evangelist", nor do I think that its perfect... but this is an incredible system that just gets better and better.

I have built WP sites and Joomla sites and yes, they are easier to get going out of the gate (though D7 will shrink that gap consierably)... but over time they get clunky and difficult to manage... especially if you want to add features.

You only want a blog? Use WP. You want a robust, flexible application framework that allows you to get as close to the bleeding edge as possible, while still keeping you prepared for tomorrow? Use Drupal.

Doka (not verified):

Products are the distributions!

Framework is one and only, with mature APIs. However products are targeting various market segments. All products (distributions) will be based on the Framework, and will give the next momentum for Drupal.

Tj Holowaychuk (not verified):

GIT for sure... CVS sucks hardcore

Anonymous (not verified):

I love code freeze. Without code freeze, we never see it growing to drupal 8.

And code freeze in drupal 8 will bring to drupal 9 releases. And Drupal 10 will come when code freeze in drupal 9.

By the way, I dont know much about that. Im newbie

Robbins (not verified):

@ron I did not mean stop Drupal 7, but only the public release of it, so that a half-baked product is not released while most sites are still on D 5. As outlined above we have newer 'realisations' for D 8 - it will be worth waiting so that we imbibe those and have a final D 8, and people do not have to worry about non-functioning modules so very often.

With D 7 do we have new features for the visitors who visit our site? No! Do we have a leaner code and more fast, faster performance? No!

"You only want a blog? Use WP." If Drupal is to achieve step 2 above, this mentality needs to be thrown off. Why can't we have a blog out of Drupal? And even with all its modules and 'framework capabilities' Drupal cannot become a blog like WP, for example
- its not possible to allow multiple blogs by default to each user in a multi-user site
- auto draft capability despite 2 such modules is far from what we have in WP, Google, Yahoo and all those sites that visitors to my site use daily.

Having a door (user interface) to a room is a good idea but the room needs to be there first. I think no one has sat and thought about that room (=features) first.

"You want a robust, flexible application framework that allows you to get as close to the bleeding edge as possible"

That is also not possible. Suppose I want to build a site like facebook ( structurally, I do not mean its crowd or fame ) - as a proof of concept it is just never possible because
- privacy options are impossible despite several modules, you do not have even the choice to put on-off your online status which even phpbb has
- open social or gadgets are just not supported in drupal, while several other php scripts have started supporting it in almost single click out of the box

Those who really want framework are using Python or ROR.
Django, Plone are better frameworks for the dev-minded.

What may be there is that moderate to bigger companies with purchased geek support can churn out sites in Drupal but this may be quick sand as the future net evolves on monopolistic players like Wave, new FB and several others.

Will Drupal stay ? There is already a huge base so it will perhaps, just like Geeklog, e107 is staying on. Or perhaps under the umbrella of commercial Acquia. But to be something like in step 2 above
- it has to have some necessary out of the box features first
- it has to support tomorrow what modules I use today and give me *enough breathing space* between versions. Decide on names, API, API names, admin interface once and for all for at least 5years
- it has to invent and incorporate some new features so that in a visitor-based site I can attract visitors away from other mundane sites.

Anonymous (not verified):

I agree with Corni that parts of this post read more like a company memo than an OS blog post or discussion-starter. And that deeply saddens me. Dries' (as co-founder and CTO at Acquia) is invested in Drupal's future, especially Drupal as a product.

I don't doubt his judgement about what he thinks is best for Drupal, nor do I doubt his intentions. But I do think that he is in a difficult position – a potential conflict of interest. I also think that the community needs to support Dries in making the best decisions for the Drupal project, especially when they might not be the best for Acquia (or any one Drupal company for that matter).

This comes back to Drupal's goals. What is the Drupal community and project trying to achieve? "World Domination" is the often-joked answer. I don't think it's as much of a joke as it seems though. Does the Drupal community want Drupal to be the #1 system for running websites of all sorts? I.e. the system that 90-99% of websites run on? Does the community want "LAMP" to become "LAMPD"?


These thoughts are not new, nor is my style. My vision has always been to grow Drupal, and I've always approached this in a business-like fashion. For example, this blog post links to several blog posts that I wrote in 2005 and 2006, long before I was making any money with Drupal. The vision laid out in those older posts, and the tone of them, wasn't any different. Or, if you look at older DrupalCon keynote presentations I gave, you'll notice that I often rely on business/analytical frameworks when talking about Drupal. I've always believed that there is a lot to learn from the business world. In fact, for a number of reasons, it is easier to learn from corporate success stories, than it is to learn from Open Source success stories.

Anonymous (not verified):

If the answer (your answer) to your last questions is "yes", your post contradicts itself. If you want Drupal to power 90-99% of all websites, you'll desperately need specialized companies to achieve that, like Acquia. Therefore, what's good for Acquia is good for Drupal if you define world domination as Drupal's goal. Therefore, Dries doesn't face a conflict of interest in that case. You may perceive several of such conflicts of interest during Drupal's growth, but those conflicts probably conflict more with your own personal interest than with Drupal's.

Tom Geller (not verified):

Success should be measured by the number of people working with Drupal, not by the number of people working on Drupal.

This is one of the most encouraging sentences I've ever read about Drupal. Thank you.

Jakob Petsovits (not verified):

For the people above who are critisizing Dries' usage of the term "product", please keep in mind that this is not necessarily a business term but is also commonly used as antithesis to "framework", and I believe Dries uses it in the latter sense. "Framework" obviously meaning "something unfinished that you can build a product upon", and "product" meaning "software that people can use out of the box". Please don't misunderstand "product" as "something to make money from".

As for distributed version control, Dries, I appreciate your interest in experimenting with it, but I think the real advantage of DVCS only comes to light when fragmentation issues are removed. As immediate step for fostering a central "upstream wrapper", I suggest official git/bzr mirrors being established on the high-profile hosting sites (Github or Gitorious, Launchpad) so that people can more easily clone from a central source and collaborate through a single channel, assuming they use the same version control system.

The sooner a decision for moving to a specific system is made, the more efficient development will become, because they can focus towards a single way of code sharing. But only when the actual upstream repository moves to a DVCS, people will be able to collaborate under a single umbrella and use actual rebasing instead of manually managing patches. Please do experiment with DVCS, but do also realize that their advantages are not primarily better tools (although that is also true), but streamlined workflows. As long as there are legacy workflows to integrate, the primary strength of DVCS can't unfold the way it should.

I also second the request for narrowing your target audience. It is possible to improve certain aspects of usability for all users of any Drupal, but keep in mind that in order to get a great product, stuff needs to be tailored towards a specific target audience. If you want to make Drupal 8 a better product, you need to abandon the thought that you can make it great for everybody at the same time - other solutions that are targeting a specific use case (wiki, blog, forum, etc.) will always do a better job than we do, because they can focus on their well-defined task.

As a product, I think Drupal 8 would benefit if you focus on a specific use case (while still allowing others to be created on the same framework, but with different target audiences and possibly user interfaces). For example, you could say "let's make Drupal 8 rock out of the box for small community sites with public announcements on the front page, internal communications in a separate area (forum?) and public/internal event management (working towards the addition of Date to Drupal core)". Then make an installation profile that just plain rocks for this use case, and keep the default/minimal profiles for other use cases that need adaptations.

But, for god's sake, if you want a good product, you need to choose a target audience. "Everyone" is not a target audience, and will lead to a product that might work, but does not rock. And indeed, that's what Drupal is today, as a product (not as a framework, where it does indeed rock already). Give yourself a push, I know you can do it :P


"Framework" obviously meaning "something unfinished that you can build a product upon", and "product" meaning "software that people can use out of the box". Please don't misunderstand "product" as "something to make money from".

That is (obviously) correct. Thanks for helping to clarify that, Jakob.

donquixote (not verified):

6. / 8.
For me the feature freeze is a major source of disappointment, each time I report an issue. I know that even when D7 is finally released, it will take a long time until all contributed modules have a D7 release. Users are stuck with a core that is outdated at the moment of its release.

Anonymous (not verified):

As a developer, i have another concern about revision control apart from the DVCS versus CVS discussion: Versioning of Drupal configuration. We usually maintain our projects by having dev, stage and production servers. Now with Drupal, there is no clean way to bundle all changes that had to be made to the configuration. (If there is, i am more than happy to be told how ;-). Copying the database around is /not/ an option). I think this is something Drupal should support right in Drupal core and impose on all modules that allow you to create structure.

Derek (not verified):

Thanks for Dries for a thoughtful post.

I like the long term goal of "World Domination" with Drupal, at least in the CMS space. :-)

To achieve this long term vision, Drupal must succeed in three directions (3D). The first one is the target audience, the second one is the technology (release) strategy for Drupal, and the third one is a thriving development community.

1. Target audience/Customers
I will start with customers because without them, Drupal would be dead.

We must define the core target audiences for Drupal: is it for WordPress-like blog sites? is it for Corporate sites like Sony Music? is it for portal sites? Newspaper sites ? Intranet sites? Commerce sites (Ubercart?) Big traffic sites via small traffic sites. Each of those sites have different requirements and needs.

To achieve the long term vision of making Drupal as the number 1 CMS system, it means that we should make Drupal viable choices for majority, if not all of those sites.

2. Technology strategy and release strategy

Understanding the diversity the target audience is the key for a proper release strategy.

Starting from Drupal 5, with the introduction of installation profiles, Drupal has evolved into a four tiered system:

1) Foundational API (the framework)
2) Core Release (the base release like Drupal 5, 6, 7, 8, ..)
3) Distributions (or installation profiles) such as Open Publish, Open Atrium (for intranet), Ubercart (for e-commerce), Open Media project, Prosepoint (for newspaper), etc. Not to mention the Aquia Drupal.
4) Additional optional modules that the people can pick and choose for use with Tier 2 and Tier 3.

At this point of time, Tier 1 and 2 are tightly coupled and are released at the same time. I predict that this coupled model will change in the future to serve the diverging needs of target audiences. Dries already plan to introduce two maintainers in Drupal 8.

In the future, I am suggesting an explicit separation of Tier 1 and Tier 2. The future releases can be something like

Foundational API release (major releases in 3 to 5 years) -> Tier 2 Release (major every 12 to 18 months, minor 3 - 6 months) -> Tier 3 releases ( 12 to 18 months)

Optional modules can be released any time.

In this model, all releases are tightly coupled to the foundations, but only loosely to each other.

This type of release strategy balance the needs of large and small sites, will help greatly help the long term strategy of Drupal.

The foundational API team (tier 1 team) should be focused on building a world class CMS framework. Those API should be rarely change (3 to 5 years life span). The performance, extensibility, stability, longevity, security, forward looking, and ease of migration are the charted goals for the team.
A 3 to 5 years lifespan for foundational API can work because, frankly speaking, the foundations should not change, and does not have to change every 12 months. The core foundation for Drupal, PHP and SQL, does not change that often. New APIs can be added as part of the minor release without need to change other APIs as long as the foundation team.

The core release team (Tier 2 team) is focusing on the usability of the base features. The charted goal is make Drupal the number 1 choices as out of box CMS tools for blog and brochure ware sites.
The success of the core release team is measured against Wordpress and Joomla installations.

3. Maintain a thriving development community

Drupal already has a thriving development community. I will not say more here.

Chris Charlton (not verified):

Adobe ran into adoption slowdown of their commercial products because the releases were really close together, and the products didn't change much (to the consumers). People were fine with waiting. Flex, when open sourced, saw huge growth and because a cornerstone in the Flash world.

The same could be said about Microsoft's operating system and office suite. Too often of a release confuses or aggravates users & companies. Too infrequent of a release gives people time to look around and see what's hip/new/updated.

Personally, besides the patch review process being slow, the documentation and way people "find" how to do something is in desperate need of an overhaul. The docs and how people find a hook/theme function needs to change. Not everyone is comfortable with digging into core/module code just to find out what to type in their theme/module to integrate. This bar has to be lowered, a lot. Not the quality of code, the way people are supposed to "dissect" a module/feature/function. I think this is a software issue, but Drupal.org can help folks get farther regardless of their IDE choice.

Kevin (not verified):

This is one of the most well thought out long term product posts I've read from any CMS project leader.

It's why Drupal stands out amongst the crowd. People care.

Anonymous (not verified):

I second that notion & further elaborate by stating the obvious ~ Dries you rock!

donquixote (not verified):

Another note on point 6 / backporting.

That said, there might be certain changes, like smaller usability improvements, standalone features, or new hooks that don't break existing code, that could be backported to previous Drupal releases during the development cycle.

I think hook backporting is really the way to go. New hooks, if done in a sensible way, do little damage to an existing stable release, except for a few theoretical nameclashes. More importantly, they invite contrib developers to prepare solutions that could be adapted by a future core release.

The motivation to produce modules for a stable version is much higher than for a future release, and it will reveal the weak spots in the hook approach, providing useful feedback for the next version.

We don't even need to backport the complete solution. While the next release might introduce a complex hook system, it might be enough for the stable release to introduce one single hook to set a handler that replaces a core function.

The motto for a new and stable releases would be different:
new releases: We want useful and stable default behavior, and provide a flexible API to extend and alter.
stable releases: We want defaults that replicate legacy (mis)behavior, and simple API changes, on top of which modules can come up with their own APIs.

Linulo (not verified):

Mischievous summary:

  • Let's work super-hard on D7.
  • I'm gonna choose 2 maintainers.
  • I'm afraid of forks.
  • I don't like it but Drupal will bloat.
  • We have too few reviewers and no idea how to get more.
  • We are gonna switch do Mercurial in 2012.
  • D8 will be released when it's done.
  • World domination!

Did I get this about right? ;-)

NancyDru (not verified):

Overlapping release cycles may be a way to help reduce/stabilize core development cycles. For example, the D7 APIs are largely stable now, so why not go ahead and open the D8 branch? Those who care about their features getting into 8 can start making sure those features are core-ready. And perhaps this would also give them time to figure out if a back-port or contrib can help ease the next transition.

My biggests concern with this approach is that someone who might have helped with issue review/fixing might get distracted and not do that.

Ubercart Themes (not verified):

Things which need to be improved in my opinion for developers is improving the dev, staging, stable workflow. The idea of exportable/importable datatypes is something I would like to see in Drupal 8. Chaos Tools and Features are something I'd love to see in the core for Drupal 8.

Also I'd like to see some improvement of regions, blocks. Panels and Context are the two competing modules, which assist with these. Taking the best from these modules and overhauling core block/regions with that would be wonderful.

I would also like to see the default "add on" modules that come with Drupal be less flexible, but become fully featured. Otherwise I'd like to see them removed. Blog is useless, Forum is useless. Poll is useless in their current states. They don't satisfy the needs of users. I believe effort should be made to make these full featured robust modules and perhaps remove them from core, but have them be coded and supported by core developers. Otherwise just drop them into the community. I feel having poor core modules takes away from the community building proper alternatives.

domidc (not verified):

Better staging possibilities should definitely be considered for Drupal 8. If it is the goal to make Drupal enter the enterprise market this is a very imported (missing) feature. It is still an obstacle to introduce Drupal at the enterprise level because of this. The current Drupal staging problem is described here http://dominiquedecooman.com/blog/drupal-staging-problem
There are several solutions to this problem. There are features based solutions, there is Dave Cohen's solution (http://www.dave-cohen.com/node/3932), ...
Let start thinking about the reliable, the most flexible and most easy method to make Drupal stage.

lagpro (not verified):

There is a lot of talk from the brick by brick point of view in building the 8 pyramid. However, if you want to be the top CMS and stand out as the clear winner, then you need to look at it from three directions.

1) Resource Efficiency - it has to run fast and efficient. If it costs too much to deploy and scale, then you are not going anywhere fast.

2) Feature Efficiency - Why would I use Drupal instead of WordpressMU for a blogging site? Why would I use Drupal instead of Microsoft/IBM/Oracle/Joombla with xxx app servers for my online content solutions? etc. etc.

3) Maintainability - This is the engineering goal. Build something that can live and be maintained, and not die a horrible death of bad code

Although this sounds like a "ton" of common sense its important in sorting out "real" delivery goals. Debating frameworks and models is more fun from the engineering point of view but if that was the real answer then CodeIgniter, Kohona, Zen, etc. would be conquering the world.

Somebody noted that blog and forums should be removed because they are not very useful to most users (i.e. they replace it with better parts). The problem you will have is that the core becomes an exercise in abstraction since it has no focus. Not good.

How does Drupal want to become a leader? The releases have been building towards a great goal.
1) Easy Install
2) Easy internationalization
3) Better Usability

The product is getting better but the question of how it is used and how it is deployed are critical issues. Cost/Features/Usability are key issues to remember in engineering 8.

And one last note - There should be a plan for Major and Minor releases.

Major = Change the core
Minor = Add to the core

Ovo (not verified):

For the choice of the DVCS, here's my experience as a very casual developer (webmaster of simple websites, contributed a few patches to drupal contrib modules, coded simple apps for Win and Linux) :
I discovered the distributed system a few months ago and surveyed the various solutions with the help of the comparison tables on Wikipedia for revision control system and hosting web platforms.

Overall, bzr looked the most promising to me. Launchpad, although having a messy interface, has a great slideshow introduction to the DVCS world and looks quite complete to me, I especially appreciate the support for translation, I just miss project page/wiki/forum hosting. The major GUI, Bazaar Explorer, is perfect for a casual use at least and was simple to apprehend with its built-in help and the tutorial on its website. The bzr software itself, well, I can't tell how good or bad it is but I read this article from Mark Shuttleworth and it convinced me :^), despite the childish debates in the comments... Finally the fact that all of this is supported by Canonical, but also entirely open source (if I'm not mistaken), is reassuring.

Mercurial has a cool GUI in the form of TortoiseHg. But what seems to be the major platform, Bitbucket seemed too commercial at first glimpse so I didn't investigate beyond the front page...

Git has the best looking web platform of all, Gitorious, sadly it's quite limited in functionality. The GUIs I've found available for Linux, qgit and gitg look ok but I have yet to find a simple tutorial to get on tracks. I'm currently trying github, the starting guide looks somewhat intimidating, going to try and read it right now.

I hope this helped a little bit...

Benjamin Rowlands (not verified):

36 - 48 months is a ball park figure I'd use between releases, 18 months simply doesn't allow enough time for developers to fix, update, improve code and site owners don't want to update their site in such a small period. Note, many modules go straight from version 4 to 6 precisely because of this, leaving 5 owners no look in. Site owners need reasons to switch to a newer version, time and effort spent on developing modules for a fast release cycle is therefore wasted, whereas a slower release cycle means the majority of site owners will upgrade.

Drupal should do what Wordpress does out of the box ... and more, installing and updating modules needs to be as simply as possible to attract complete novices as well as seasoned Drupalers or other software developers. You might argue Drupal isn't intended for complete novices and products such as Wordpress already exist for that niche, however, the spotty 15 year old who's just started a simple blog using Drupal 8 because it's now as simple as Wordpress might in 3 or 4 years time become a seasoned Drupal developer committing patches and helping out on forums etc. You don't suddenly become a Drupal officiando, it's a learning process but the learning curve for Drupal is initially too steep, remove that initial hurdle and the market for Drupal is much more suited to all levels of expertise.

The theme situation needs improving, there are so few good quality themes available on Drupal something must be done to address the situation. To start Drupal.org itself should produce 5 really top notch distinct themes with all the goodies, text font/colour selection, cufonisation, colour switches, skinr integration, node pictures, rtl, fluid width etc. Secondly, the tools to build themes should be easier and more apparent to potential developers. Finally there should be some way of distributing homebrew themes, that is themes which have been adapted by end-users made available as options to the original theme. It's no good putting a Ferrari engine in a Ford, it will still look like a Ford and at the same rate a Ferrai with a Ford engine will look good but won't perform. Themes are a very important aspect of the presentation of a website and not to be sniffed at.

The core forum and blog modules require much more functionality as should be considered priority. It's no good having a half performing core module, create forum and blog replacements in version 7 available to community developers so these can be incorporated into version 8. Spam protection should also be considered a core usability issue.

Drupal.org itself is becoming bloated big time, so much duplication, misdirection and poor commentating means time wasted. There must be some way of improving the situation, to start I suggest allow users to flag comments as irrelevant, helpful, best reply etc and incorporate these statistics into meaningful search results.

Anonymous (not verified):

Step 3: Select two strategic co-maintainers who care deeply about ACCESSIBILITY for Drupal 8.

Usability and accessibility are subset of the user experience. Usability and accessibility are two sides of the same coin.

In Drupal 8, we should focus on making it the most accessible CMS ever.

rodenp (not verified):

Drupal is getting better and better, and I look forward to seeing it mature into the best CMS out there.

For me personally the learning curve in Drupal is massive, like concurring Everest.

What would set Drupal way ahead of the rest in my opinion is a GUI development system, based on say eclipse.

Drupal with its hook system is comparable in a fashion to Eclipse with its extension points.

Just imagine being able to develop using visual components, and be able to create modules to extend functionality. WOW