As pointed out, what is currently holding up the adoption of Drupal 6 aren't sweeping changes in Drupal core. It is a number of contributed modules, like Views and CCK, that have decided to do a major architectural redesign. When a popular Drupal module is not maintained properly or released in time, it creates all kinds of problems, and it is routinely identified as one of the main issues with Drupal. It's frustrating indeed. As a result, the Drupal community has a strong desire to make sure that important modules are always stable and up-to-date. In practice, however, this isn't always the case and important modules are sometimes slow to be upgraded. Sometimes this is due to a failure of leadership and poor planning. Sometimes there are good reasons for it -- like the complexity of the task at hand. Drupal developer must promote a culture that uses peer pressure to encourage responsible maintainership. Drupal users, on the other hand, need to realize that sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off. APIs are not changed for the fun of it, sweeping changes take a lot of work, and we can't hold volunteers to deadlines. When members of our community set out to address important limitations and to improve the status quo they should be supported. In volunteer-driven projects like Drupal, innovation and collaboration (must) go hand in hand. All that said, the shit has hit the fan, and what exactly does that mean for Drupal 7? Drupal 7 will be ready when it is ready, and more importantly, when the Drupal community is ready for it. At no point, release dates are set in stone, and I'll always continue to listen to input and zeitgeist from the community at large. Our ability to innovate is independent of release dates. I'm willing to adjust release schedules, but I'm not willing to slow down the rate of change and innovation. -- Dries Buytaert :: http://buytaert.net/