There have been many pretty obvious signs in the recent past for what can only be considered as a critical milestone:
February 2008: Drupal 7 opened for development.
Oktober 2008: 285 unresolved bugs for Drupal 7.
March 2009: A user experience initiative for Drupal 7 launches.
June 2009: 3,120 unresolved bugs (13,763 total).
September 2009: Originally intended code freeze, but 10 new product features are still allowed to be developed (from scratch) and get into Drupal 7.
January 2010: First alpha of Drupal 7 published, loads of critical bugs in new APIs, but even more so in new product features.
July 2010: Too many bugs and lost focus; Drupal introduces a new "major" bug priority to make any sense of the high volume of bugs.
October 2010: First beta of Drupal 7 published.
January 2011: Drupal 7.0 released, with more than 300 unresolved major bugs and a broken upgrade path.
May 2011: Drupal 8 gets a constrained co-maintainer in order to fix bugs in Drupal 7.
June 2011: More than 200 previously critical and major bugs get demoted to normal.
July 2011: New issue count thresholds of 15 critical and 200 major bugs/tasks effectively block progress on Drupal 8.
August 2011: 4,153 unresolved bugs (22,181 total - nearly doubled within two years), upgrade path still amiss for many users stuck on Drupal 6, close to zero progress on Drupal 8.
More than 150 unresolved bugs and tasks exist for the new Dashboard, Shortcut, Toolbar, and Overlay modules alone. These modules were invented from scratch after code-freeze (which is no wonder because the very design for them started only six months earlier), partially had to be rewritten at least once after getting in, and had a huge impact on the delayed Drupal 7 release.
I think its essential to recognize that with how the feedback process was handled during D7UX, we demotivated a crucial group: our core developers, who can do the heavy lifting required for some of the proposed changes.
We have roughly 450+ core contributors, of whom about 10 are working on the core interface.
...was an early reflection by one of the Usability team leads — in other words: "Core developers really didn't want to take on this burden, but it happened nonetheless."
Those last-minute product features not only blocked Drupal 7 from being released. They also distracted and prevented many high-profile core developers from working on the much more important API and subsystem issues in Drupal core, of which many still remain unresolved today.
Newly introduced subsystems in Drupal 7 have a fair amount of complexity and interdependencies on even more complex subsystems. Newcomers are locked out, unable to help with resolving open bugs. Almost all bugs require in-depth knowledge of various subsystems as well as a solid understanding of the consequences of a change. They need to be tackled by already burnt-out core developers and contributors, or at minimum, require careful reviews and sign-offs from them.
If they don't care for them, then they are not able to move forward with their development goals for Drupal 8. Even though these developments are mostly targeting low-level core functionality. But yet, core developers have to care for completely irrelevant functionality that someone thought would be nice to have for their mainstream product. Get it into core, let the community maintain it.
At the same time, some of the most active and most proficient core developers started to work for said company within the past three years, and in some cases, their core contributions suddenly and sadly dropped to nearly zero. Without any doubt, it's merely an economical truth that free contributions and commercial enterprise interests are mainly incompatible, and of course, everyone needs to decide on their own on how to use and invest their resources. Nevertheless, 19% of all core maintainers (including the only two people being able to commit changes) are paid and influenced by a single, dominant (third-)party, which obviously presents a serious conflict of interest today and in the long run.
In addition to the half-baked, single-purpose product features mentioned above, Drupal core still carries around very old cruft from earlier days, which no one cares for. All of these features are not core functionality of a flexible, modular, and extensible system Drupal pretends to be. They are poor and inflexible product features being based on APIs and concepts that Drupal core allowed for, five and more years ago.
Drupal core blocks its very own modernization and innovation, and started to heavily lack behind competitors and the overall industry in the past years. It is a stupidly old, poor, and monolothic beast.
There's only one way to get it back under control:
Move the Standard installation profile into an own project.
And move modules providing "standard" product functionality into contrib.
Make http://drupal.org/project/standard the new default download page for "Drupal".
Rip out everything that is not core functionality and which does not have to be in core.
Only keep stuff that provides or exposes crucial functionality or patterns.
In short: Make core maintainable.
- Stop caring for shit. Attack the real, horrible design failures in core instead.
Lastly, eventually, and finally, architecturally revamp Drupal core through the iniatives.
Make it easier, less complex, and faster. No more nostalgic ballast to care for. Focus.
We need to be a solid framework, and also a basic but extensible CMS, like we've always been.
We need to stop painting lipstick on a giant pig. There are no intentions to help maintain the current disaster of a half-baked product anymore. Core developers are getting sick of the argument that we can cope with the bloat by doing "more marketing and training new contributors". That's simply not true and utterly wrong, because it doesn't remove the burden from existing contributors, consumes a lot of time, and also scaling has an end. Those people who continue to argue for it will see an even longer delayed release of Drupal 8.
In case Drupal core gets influenced and pushed too far into a unmaintainable and unsustainable direction, a middle-term solution might very well be to move core development into an official Drupal core distribution that's cut back down to a maintainable size and allows us to focus on its architectural design. The option exists, but should only be a last resort.
Now, have fun at DrupalCon London! Miss you.
Final note: If anyone feels personally offended by this post, let me assure you that I definitely and absolutely did not think of anyone while writing it. I tried to remain as objective and factual as possible. But well, I'm just a human, too, and English is not my mother language.
Read the follow-up about first conclusions.