(uuhm sorry about the former reply that ehh wasn't ready yet.)
Let me point out again that this is open source and not a corporate environment, and hence the difference. Basically everything we assumed about how corporate shops work does not work at all, or not as well in open source. Point true 80%. There are comparable situations, in which similar methods can successfully be applied.
When I asked him how does this apply to open source, and the success it had without this lengthy centralized planning. He did not have an answer. Once you have hundreds and thousands of contributors who never met each other, spread across the globe, each scratching their own (or their client/employer's) itch, we have a new paradigm (yeah, another buzzword). You have organized chaos. This it in fact very true. This is the great method of success for this kind of software. However as the project grows, you get into a situation where the chaos gets too big of a mess. Additionally, one thing an evolutionary software development process does achieve is building experience. Competition also does help in that phase. BUT this all takes part with D6 contrib - and is also creating problems. These can be solved by applying methods which are meant to filter by quality standards - but ONLY because we have such a huge stash of already working code to pick from! In the whole D6 cycle, i'd never have proposed to restrict code committing, just because of all the reasons people have brought up in this discussion! But because we DO have all that GPLed code available, and a great lot of skilled coders, we could now shift focus for D7 from creating modules for each use case to _building a structure that can handle each use case_. We can do so by selecting from all the great code there already is - but the process of careful structural design and _selecting good code_ is a procedure that will filter out all the (small) issues which have come up in the past such as code duplication, disregard of coding standards and low quality. If we want D7 to really rock as hard as possible, we surely want to minimize these problems. That is the reason why i still believe that overlaying a new method onto the drupal project and community as it stands now is a viable way to go. This would not have been the case at any point in time before - simply because we NEEDED the drastic level of competition and free form creativity!
So, jump in and "Do". Write about it 6 and 12 months from now and see if you have changed your mind, and what you learned. Ok well even though i might seem naive and immature at times, i actually have 'done', furthermore always reflect and adapt to reality as it is. I have been with this great project for almost a year, although with low visibility and only few code inside some of core and several modules. But i do have a good understanding of how open source projects work, really (duh i use hundreds of them, and contributed to a handful - still small stuff though, started programming only two years ago.. but getting better ;). Sometimes it really *is* all about the color of the damn bike shed ^ ^ regards marcel.
-- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote: http://hfopi.org/vote-future