While Dries' keynote touched on a number of topics -- from the scalability of Drupal to individual shout-outs to the top 30 core contributors -- the bulk of the talk focused on the roadmap for Drupal 8. Here's a quick rundown of what we can look forward to in the next release of Drupal:

- **Drupal to any device**, particularly mobile ones. If you look at the prevalence of net-connected computing devices in 2011, desktops are a minor, stagnant sector, whereas mobile devices -- anything from a smartphone, to a laptop, to a TV -- are more numerous, and their numbers are increasing. "If I were to build Drupal today," Dries said, "I would target mobile devices."
- **Initiative owners**, who are essentially Drupal 8 co-maintainers in charge of a particular improvement for D8. The list of initiatives may change, but Dries mapped out four that he's identified so far:
- Web services
- UUIDs
- HTML5
- Configuration management

It's an organizational structure that (in theory) should allow for greater communication between decision-makers and core contributors, and which scales a lot better than the two-maintainer system used in D7.
- **A "delightful experience"** for users. The iPhone is a powerful device, yet it's also simple to use. Why can't Drupal be like the iPhone?
- **Feeding the ecosystem** surrounding Drupal. If two solutions are deemed equal, but one solution has a more vibrant, committed and accessible community, which solution would you choose?

But if I had to pick the one thing that piqued my interest the most, it would be the new critical bug threshold that Dries announced. According to Dries' plan, the Drupal 8 project will not be allowed to have more than _15 critical bugs_ at any given time. For comparison, the Drupal 7 project had around 500 critical bugs when it hit the code freeze.

This announcement was met with nervous laughter and cautious applause. Is he serious? Aren't we aiming a bit high? Are we making good the enemy of perfect?

It would seem not. Each piece of code that gets committed to core must first pass a series of checks, or "gates". If a piece of code fails to pass a gate (security, documentation, etc.), the automated testing system flags it; explains the reason behind the failure; and allows you to try again. This system should allow vetted code to move forward, while preventing the kind of critical bug mayhem that plagued Drupal 7.

But the proof, as they say, is in the pudding.

Tags: drupalcon