Drupal is a registered trademark of Dries Buytaert
I was already planning to provide an overview of what’s been going on in the various Drupal 8 initiatives even before last week, when Dries announced the timeline for Drupal 8 , which includes a “feature freeze” for Drupal 8 in only a little more than nine months from now, and planned release at the DrupalCon  Europe, in late August 2013.
While most of the top Drupal 6 modules are now available, in some state or another, for Drupal 7, and I would certainly choose Drupal 7 for a large Drupal-based project that is not expected to be deployed for some time, from the outcry of protests I think there are a lot of people who would not agree that Drupal 7 is yet at its Plateau of Productivity. I would choose development in Drupal 7 for most projects, but there is still plenty of reason for site builders to work with Drupal 6, especially if they need particular features (e.g Nodewords  / Metatag  functioning properly, among others) and if they need to deploy the site now, with those features ready for use. Dries indicated that he thought Drupal 6 reached its Plateau of Productivity in late 2009, about 18 months after its initial release. At that point, there were fewer than 20,000 sites using Drupal 5 and more than 200,000 sites using Drupal 6. While this order-of-magnitude-greater-usage is not likely to ever be seen comparing Drupal 7 vs Drupal 6 usage (at least not before Drupal 8 is released), I do think that it’s significant that Drupal 7 usage has finally overtaken Drupal 6. That said, I don’t think we are truly at Drupal 7’s Plateau of Productivity, the point where building a new site on Drupal 6 would be “pointless”. Both in terms of time-after-release and usage statistics, it is arguably premature to say we are quite to that point yet.
Quibbling aside, I also don’t think it matters whether we believe we have reached the Plateau of Productivity for Drupal 7, or not — and it certainly doesn’t matter whether we are all in agreement about that. I do think Drupal 7 is very “ready for use”, though and I do think we are ready to see core  development for Drupal 8 get kicked into high gear and I don’t think it will significantly delay the development of certain lagging contrib  modules or resolving core issues in Drupal 7 which are the final barrier, in my view, to truly reaching its Plateau of Productivity. Additionally, many of the fixes and features going into Drupal 8 are regularly being back-ported to Drupal 7, and there is increased discussion of relaxing the criteria for what can be back-ported to Drupal 7 , so I see the increased attention to Drupal 8 core development as exciting: a win-win for the whole Drupal community. We now have a release date for Drupal 8, which is important for business decisions, and a better timeline to facilitate a roadmap for the final stages of determining feature inclusion.
Currently there are 6 official Drupal 8 Core Initiatives which are working on various aspects of desired improvements to core. There are others likely to be added to the list as soon as a bit more progress has been made on the current list and/or as qualified individuals step up to take on some of the other “top 10” desired improvements we had on our collective community wishlist. Some of the improvements require fixes to issues plaguing Drupal 7 and 6 and have been backported. Most of the others involve dozens, if not hundreds, of related issues. Following is a brief summary of each of the current core initiatives and what their priority goals are for Drupal 8. In the interest of brevity, the explanations leave out a lot of juicy details, but for those who haven’t been paying close attention and who might like to get involved, I hope this summary is useful:
The Web Services and Context Core Initiative (WSCCI, pronounced “Whiskey”) , formerly referred to as the “Butler” project, is a core initiative led by Larry Garfield  of Palantir.net , aka “Crell” on Drupal.org. While the traditionally typical HTTP request has been for HTML pages, the modern Web has brought with it the need for HTTP services which deliver information which is not necessarily in the form of HTML. This is especially true for mobile applications, but also applies to feeds and other communications via HTTP. The goal is to “take Drupal from being a first-class Web CMS  to being a first-class REST  server which includes a first-class Web CMS”. Really, this initiative spans a huge range of related issues and without writing an article many times the length of this one, I could not possibly cover everything, but…
Using Symfony2 components is a big part of this effort; Symfony2 is an open-source application framework with a lot of nicely abstracted and discrete components, several of which are being integrated into Drupal to build on its strengths as a CMS. The HttpFoundation and ClassLoader elements have already been added to Drupal 8, but the latest WSCCI Sprint , attended by almost all of the Drupal core developers most of us can probably name, along with Fabien Potencier, the Symfony lead developer, determined that several other Symfony2 components would also be included. While these changes may sound daunting to many long-time Drupal developers, it should actually make the core much more approachable for developers new to Drupal, while also making Drupal inviting to experienced Symfony developers. Additional benefits include reducing a the heavy load of Drupal requests, making it more “lean and mean” and providing partial page caching for example, while also delivering a number of powerful features for Panels-like applications, better blocks, and much, much more. Some of the work related to the WSCCI project has been underway for some time now and was encapsulated in a Drupal 7 development module called “Butler”. [Update: I had linked in the Butler project, but Larry Garfield has indicated it is “vestigial” and there is no way that any of the final WSCCI changes will be back-portable or functional as a D7 module.]
If you want to learn more about WSCCI, Daniel Kudwien  (aka ‘sun’ on Drupal.org) has recently posted an excellent article  which, similar to Dries’s post about the Sprint , also focuses largely on what was covered at the recent WSCCI Sprint and goes into greater technical depth about what it all means. Update: There is also a new post from Larry Garfied which also explains some of the latest developments in WSCCI . Again, this is a huge and crucial initiative for Drupal 8 to live up to the envisioned dreams, and there are ways for community members of all experience levels to dive in and contribute to its success. There is a ton to do in the months remaining.
The Multilingual Initiative , led by Gábor Hojtsy  of Acquia, covers a wide range of issues related to improving Drupal 8’s support for multilingual support (internationalization  and localization  issues). The issue queue  is daunting, but there are a lot of experienced developers pitching in. If you’ve worked with non-English sites in Drupal or sites with more than one language, or have written and contributed  a module and then realized you had to sort out how to deal with all the issues related to multilingual support, this work should be of interest. I’m not going to go into all the pain points you might be aware of in Drupal 6 and Drupal 7 or which of the improvements have been or might be backported, but we can only hope that many of them will be. Issues related to language negotiation, translation, and associated APIs are a particularly confusing area of Drupal and the more they can be improved, the better. There was a Multilingual Sprint which was just held in Budapest  (with participants in other areas communicating via IRC) and a multi-day Sprint is planned to follow the Denver DrupalCon .
Since a primary reason for the existence of the Cocomore Drupal Core and other related Cocomore-maintained contrib module forks has been issues related to multilingual support, this is of particular interest to the Cocomore development staff, as it should be to anyone working with non-English or multilingual Drupal sites or who cares about making their modules and themes properly locale -aware. So jump in and help out if you can!
The primary goal of the Drupal 8 Mobile Initiative , led by John Albin Wilkins  of Palantir.net , is to make Drupal the leading mobile CMS. While there are naturally overlaps between the goals of the Mobile Initiative and the WSCCI (web services needed for native mobile applications) and HTML5 initiatives, there are still a wide range of goals left for the Mobile Initiative to work on, including (but not limited to):
I should mention, for readers who are new to Drupal, that mobile support is not something new to Drupal 8; you don’t need to wait for it since there are already ways to produce mobile content  in Drupal 6 and Drupal 7. But the mobile initiative will hopefully take a lot of the current pain out of working with all the inter-related modules, themes and other technologies required to have anything approaching an ideal solution to mobile issues in current versions of Drupal. You should still do a search to find the right solution for your use case, but some of the popular mobile-related modules include: Mobile Tools , the Mobile Theme module , Browscap , SMS Framework , WURFL , and Mobile Codes , Phonegap , among other common modules which are not specifically for mobile development, but can be helpful. And DrupalGap  is another promising module which is still in the developer’s “sandbox” at this time. There are a number of themes which are well suited to Drupal development, including the Mobile theme , which can be used as-is or as a basis for a custom mobile theme, AdaptiveTheme  (as well as all of the themes based on it, such as Pixture Reloaded , Sky , and Corolla ), and Boilerplate . You’ll find numerous blog articles, recorded DrupalCon sessions, and resources. There is also a new book  which is expected soon and which you can already pre-order and start reading (RAW): Drupal 7 Mobile Web Development Beginner’s Guide .
The HTML5 Initiative , headed by Jacine Luisi , is another of the major initiatives for Drupal 8, which (as mentioned, above) has strong ties to the success of the Mobile Initiative, as well. You probably saw the announcement a few months back that Drupal 8 already has HTML5 as its default “doctype”, but that was just the first step toward getting Drupal 8 fully HTML5-ready. Templates, theme functions, markup… everything needs to be ready and there are still plenty of open issues related to HTML5 in Drupal 8  if you’d like to join the effort.
The HTML5 Initiative also has close connection to the web services and mobile initiatives, of course, so getting this all working is a vital part of the effort.
The Configuration Management Initiative  (CMI), led by Greg Dunlap  (aka heyrocker on drupal.org), aims to sort out the issues related to maintaining, storing, and deploying configuration of a Drupal site. Currently, all the configuration for a Drupal site (except, of course, for the basic database access settings stored in settings.php) is stored in the database, and deploying it is a pain. Furthermore, if someone changes settings and it breaks site functionality, there is no simple way to “roll back” just those changes. The CMI moves all configuration from database to disk in a standard format which can be more easily deployed, can be stored in a version control system, and can be used in multiple sites more easily. This provides a much better development workflow  to easily take configuration used on one site to another, and to modify it, as needed. Of course it should provide for much more useful distributions  and installation profiles .
You can read more technical details about the CMI, at least as it was initially conceptualized, in Webchick’s summary of the first CMI Sprint held in June 2011  and there is ongoing discussion of the initiative in this Drupal Groups thread . Needless to say, this should be a big improvement over what’s currently possible to do with Drupal’s Features module , but if you need to package configurations to use them on multiple sites, the Features module is currently your best friend.
Last, but certainly not least, the Design Initiative , led by Jeff Burnz  of AdaptiveThemes , aims to give Drupal a new look for Drupal 8 Of course the theme design will also be fully mobile-ready. Part of the effort involved designers collaborating about the new look before the coding phase for the theme was begun. According to the official timeline set out by the initiative team, we are now in the middle of the development phase. If you are a theming expert and want to help, contact the initiative team and see what you can do. Currently all work is in the initiative development sandbox, so you won’s see it committed to the “current” (Git) version of Drupal 8 until it’s pretty well done.
I know, I know... my graphic for this section has more to do with UX than “Design”, per se, although they are closely related. Good designs should be user-friendly. Anyway, strictly speaking, Usability is a completely different initiative which is not currently on the “hot-plate”, at least not for Drupal 8. Why? I guess there is always time to improve the UX of a product as long as it does not break (too much) and does more good than harm, so improvement to UX can continue even after product release. And of course we still have 18 months before Drupal 8’s release, so getting the core features right, first, is of most importance. If you are interested in Usability issues, however, there are regular meetings held in IRC. You can connect with the Drupal Usability group here . You might be particularly interested in the discussion of the recent Drupal 7 Usability Study at Google . The videos videos from usability study  are particularly useful for identifying current “sticky points” in Drupal 7’s usability. Presumably all of these usability issues will be fixed in Drupal 8 and hopefully most can be backported to Drupal 7 without causing more harm than good.
As a point of reminder, don’t expect to see much of the progress in Drupal 8 if you check out the project from Git. Not a lot has been pushed to the central repository and is, instead, on individual developers’ repositories and/or in shared initiative “sandbox” repositories. By keeping experimental code out of the “master” repository, the hope is to keep the issue count down and prevent issues caused by incomplete code in one area of the product from wreaking havoc (or masking issues) in other parts. This is the benefit of a distributed VCS like Git, but it also means that in order to test the latest, most experimental features, you will need to work with the sandbox versions.
If you are like me, you are now inspired but you might be having trouble picking where to best apply your talents. Check out the issue queues for each initiative if that’s the case. You might find something you can take on and help lay a few stones in the foundation of what’s sure to be the most awesome version of Drupal yet!