There are already few reviewers for core. Don't expect to have reviewers for contrib. Well the idea was to convert all people currently posessing an SVN account the reviewing collective, not getting additional reviewers. Am i interested in the modules i have submitted codes for? Sure i am. Am i interested in the code quality / functionality of all the other modules aswell? YES i AM - because they all affect what and how i can use Drupal to accomplish stuff.
It is clearer how core gains from public review. It's not that clear how a maintainer may gain from code review. No more maintainers, just contributors. I'm not talking about quality of code... I'm talking about the interest of the maintainers. Well take them out of the equation. Anyone in fear of leaving his title as 'maintainer of module foo' should be soothed by the opportunity that per-module commit statics provide for fame.
Core and contrib are quite different in terms of speed of development, purposes, design, coders sub-communities...
People may use drupal infrastructure just if: - They're looking for public review - They're looking for co-maintainers - They're looking for exposure - They just feel "generous" and they think someone else may make good use of their code without bothering them Well my belief is that enforcing a community process on all developers for any D7 might be a good thing, strengthening the community and resulting in better code. And i highly doubt just out of pride people would take their module code elsewhere just because they won't be the sole 'owner' in the d.o repository.
Release early, release often refers to your users... not to everyone. If I can't release early and often for *my users* because someone else is not going to review my patch, I'm going to move my stuff elsewhere. Having your experimental code reside in a staging repository until the code is ready for being unleashed onto thousands of sites is too much of a pain to take?
If someone is pushing my module in a direction that doesn't fit *my users* I'm going to resist to the change. Veto the change, comment on your reasoning. Is too bad of a way to handle it?
Very frequently the maintainer of a module is the one that keeps contributing the module most. So uhhm that'd make them 'top contributor' instead of 'guy who holds the golden key'.
You're starting from the unproved assumption that for every maintainer code review and exposure are a larger benefit than keep on being the steering committee of its own project and that drupal benefit more from a supposed increase of code quality and reduction in duplication than having a prolific competitive community of contributors. Difficult to answer.. in my opinion most of the stuff that even can be done with a website is already available in some form or another as D6 module. Taking all this great innovative stuff in contrib, there's really not much stuff left to be desired. A lot of this code can be just migrated to D7, continuing as in past drupal version jumps. But having almost every thinkable use case already covered would allow us to take a different direction: cleaning up, merging and refactoring the existing modules, transplanting good code and skipping not-so-good. The competition that has been going on up to now already has created a huge pile of excellent stuff to pick from. Why not make the decision to not take the huge pile, but only the best part of it? Also, frameworks for basic shared functionality should be designed in a way that makes them as expandable and REPLACEABLE as possible, i.e. clear interface definitions. Having competition on that basic fundamental level of groundwork services (the prime examples again: notifications, web forms) in a project of this maturity level at least to me does not seem to be a good idea- because it REALLY REALLY isn't. Other people have stated why they support that statement.
Otherwise you're heading to balkanization of contrib repositories. Really have my doubts people would like to use modules that are not from the official d.o repository. Having all code committed only after quality reviews have been applied is more of an USP than anything other!
While I agree that natural selection may be suboptimal and rationally planning and channelling efforts may achieve better results in a shorter time[1]... natural selection is self testing and it already happens with no extra effort. Yeah so at this point we could look back at the pile of code it created and transplant ONLY THE GOOD PARTS of it into the D7 repository.
Other theories have to be proved and require efforts to be put in practice. Well apparently
Now... if you've something better to substitute to natural selection and you can prove it is better, that's just the starting point as Laura Scott pointed out at the end of her post. How can i prove that on my own? From my level of education on the object of process and quality management aswell as open source communities, i think it does.
If no one feels your hypothesis is worth a test, provide your own test. I'd gladly do everything i proposed myself (if only to show off) but time is the limiting factor again. Maybe i should have used the time debating here with people who misunderstand what i am trying to communicate to come up with a design draft for a D7 notification API, duh.
Then maybe you'll reach the point where "d(em)ocracy" and evolution sucks and you may start complaining ;) There's always this tiny fraction of people warning about shit tending towards the fan long before shit gets there. Not only the current climate change situation is a good example for that. Why is it that the majority can never be convinced to listen to such criticism BEFORE TSHTF?
[1] let's turn this into a flamewar about XP vs. waterfall vs. academia vs. corporate vs. opensource vs. emacs as well ;) ok let's try this: xp is to opensource as emacs is to .. ah well no let's not. marcel, tired of a debate not representing his proposal.
-- "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