The link[1] Thomas Barregren posted was quite interesting. Indeed, Drupal seems to be experiencing some of the issues the Linux kernel faced some years ago, albeit not nearly as drastically. Reading through that post and the rest of the comments on the mailing list here bring me to some observations. 1. Gabor has done a great job. In particular, he has led the drive for i18n features in core. That's awesome. 2. Gabor came in almost as if he had a mandate to focus on #1, and indeed, he has focused nearly exclusively on #1. 3. Whether this was by accident or design, it worked well and would seem to be scalable and repeatable. 4. Dries could "scale" his vision of Drupal architecture by assigning more such targeted committers. He could say "Jeff Eaton... for D7, your job is to make sure the Data API gets in, and that it rocks." Or "KarenS, for D7, your job is to make sure CCK hits core, and that it rocks." Or "Earl Miles, get your query builder into core and integrated at a deep level, and make sure it rocks." 5. Whether or not the people in #4 get core commit privileges is nearly irrelevant (though I'd opt for them having commit privs, with the understanding that they were to be exercised on a limited domain of applicability only.) The important part would be that one person was understood to be "in charge" of the features. Any other developers wishing to see those features into core would have to work with the target committer, and the target committer would be responsible for tracking and coordinating the effort. We do this in a way now, so codifying it would only be a reinforcement of current patterns. Yet by making it formal we'd be enhancing the efficiency and scale of the operation. Such an approach may be the way in which we get high quality features into core while Dries maintains the overview and flexibility to do what he's been doing so well. -Robert [1] http://lkml.org/lkml/2002/1/28/83