Everyone’s chiming in on the 2008 predictions thread at drupal.org, and I can’t ignore it, either. A couple of folks have asked for clarification on some of the comments I made, so I figure it’s time for another blog post! Obviously, these are my opinions; any differing ones are welcome.
By May, large-scale Drupal 6 sites will begin launching.
Drupal 6 looks like it’s cruising towards a release in mid to late January. A lot of really critical modules, though – the stuff that large and complex Drupal sites depend on – are not yet finished. Until Views, CCK, OG, the ECommerce package (or Ubercart), and a number of others are ready, Drupal will be awesome but ‘not yet ready for production.’ It probably won’t take long – Earl Miles, or example, has said that he’ll be freed up to concentrate on the Views port shortly, and the CCK port is very nearly complete. The sites themselves have production cycles too, though, and the release of Drupal 6 is when building them begins.
As more large-scale sites roll out using Drupal, the community’s collection of high-performance scaling techniques for Drupal will grow, and become common knowledge rather than black arts. Memcached and complex database configurations will receive even greater attention.
This one’s pretty straightforward, I think. In every one of the sites we’ve worked with in 2007, high traffic and scalability were priorities. Tools like memcached, and D6’s improvements for authenticated users, are both big boosts. It’s still ugly to do certain things, like master/slave DB setups, and I think that will be likely to change as drupal.org grows and Acquia targets enterprise-level customer.
A greater percentage of the community will focus on user experience issues, and the value of our long-standing emphasis on progressive enhancement will become more and more apparent. Adding UI ‘sugar’, reworking troublesome portions of the interface, and improving fundamental workflows will all be easier because we have resisted the temptation to tightly couple client-side script code to server-side processing.
I’m a big believer in the idea of layered design for a platform like Drupal. Core functionality provides a shared set of consistent building blocks for modules, like the hook system, nodes, comments, users, menus, and so on. API modules like Views provide a layer of consistent, predictable functionality that other modules can build on top of, and FormAPI based screens can be decorated and enhanced with a ‘layer’ of client-side script that degrades gracefully. Strip away any layer and you still have something perfectly useful underneath. That last part is important – the temptation to take shortcuts, hard-wiring our system to make certain tasks easier but sacrificing the clean divisions between different subsystems – will only grow.
The groups using Drupal will diversify even further. Large-scale corporate site building, web-app design, hobbyist blogging, and home-grown community management are wildly different domains with different needs. Attempts to compare Drupal to Rails and other frameworks will further muddy the waters. One of the greatest challenges for Drupal in the coming year will be maintaining a coherent and focused project with a clear vision.
This one stands on its own, I think. It’s not a bad thing, just a reminder that Drupal is getting a lot of attention – loads more than many of us imagined when we joined the project! The pulls and tugs in different directions aren’t bad, but figuring out how to balance the needs will be an important task.
Projects to rewrite several major core APIs will be launched, and at least one will stall and ultimately be shelved or delayed for the indefinite future – much disappointment and doomsaying will result.
This isn’t a pessimistic statement, more an inevitable one I think. As systems grow, and age, and evolve, refactoring is essential. However, as Drupal grows and expands, it becomes harder to change many of its components without affecting many others. Rewriting page rendering touches the node system, for example, and that’s an impressively complex ball of yarn. In some ways, the dreams of the community for Drupal’s code currently exceeds its reach: we have lots of developers, but still not enough hardcore Drupal-hackers on deck to affect all of the major changes being discussed in a realistic timeframe. The experience will be good for us: just because we can’t do everything doesn’t mean we can’t do the top priorities well!
The community will begin to realize (in part due to the above stalled project) how much design debt Drupal has accrued over the past several years of rapid expansion and development. While the problem will not be solved in 2008, the realization that it IS a problem will help prevent a long-term meltdown.
Design Debt is something that software accumulates as it’s written – as it’s extended and evolved. It’s not a bad thing, necessarily – it’s an inevitable part of any changing code base. The only way to ‘repay’ it, though, is to re-examine the system and the decisions made in previous iterations and rework them with the evolving goals in mind. (i.e., refactoring) In a lot of ways, the Drupal community is good about that with its “the drop is always moving” philosophy. But the last several years have seen unprecedented growth, dramatic enhancements to Drupal’s functionality, and a huge blossoming of APIs and architectural tools in the contrib repositories. It’s easy, now, to hit points where enhancing things by patching or enhancing or hook_something_alter()ing is a lot more work than just starting over from scratch on some component. In many instances, that’s design debt rearing its head. Recognizing it and taking the time necessary to rethink fundamentals is always worth it.
The non-UI portions of Views will be integrated into Drupal core, and a round of deep structural changes will begin as core pages are rewritten to use it. In the long term, this will be more significant and useful than the shelved API rewrite.
OK, I confess. This is what I’d like to happen alongside the previous ‘design debt’ issue. Grafting Views into core, and leaving it at that, would satisfy a lot of people and add some great features. However, without refactoring other parts of core, we’d have lots of unnecessary code lying around bulking up core and building Views-like pages without actually using Views. The front page listing of latest nodes? The Tracker module? The listing of content at admin/content? The listing of users at admin/user? RSS feeds generated by Taxonomy module? All of those are doing limited versions of what Views module does. That kind of cruftiness is one kind of design debt: the results of things expanding slowly and steadily without being refactored. if Views goes into core we need to invest the time necessary to build those tools on top of it wherever possible. That kind of redesign of Drupal’s internals “pays off” some of our design debt, and puts us in a better position to grow in the future.