Quoting Greg Knaddison - GVS <Greg@GrowingVentureSolutions.com>:
I'm mostly just disagreeing so that we can investigate these ideas fully.
On Wed, Mar 19, 2008 at 12:05 PM, Steven Peck <sepeck@gmail.com> wrote:
A monoculture produces no innovation.
How about "tends to produce less innovation."
Protecting the existing contributed modules which may or may not have active maintainers, which may or may not have maintainers who cooperate and/or may or may not have maintainers that share a vision is not good.
In the specific case of a project that is no longer maintained we can give maintenance to someone new, right? I don't see how that's an argument to create (or allow the creation of) a new module.
Forbidding innovation or competition produces a protected class of elite people who were first to arrive but may not actually be doing something now.
Sure, but we've also got a policy that inactive maintainers get replaced. So, I don't think your conclusion is entirely accurate.
As this is not a new debate, I shall introduce a new one. Fire is bad. Support or refute this statement.
It's not new, but it is something where there is some disagreement in the community. I'd like to have a discussion about this to see if we can come to a closer agreement. If you can point to an existing decision on this topic, please do. The closest I can see to a guiding decision is the last bullet on http://drupal.org/principles
Greg, in principle I agree with you. But to enforce the principle changes to the d.o structure would need to be made and CVS write access only be given at the module rather than the contributions level of the directory tree. An application process would need to be implemented for new modules and someone would need to review the applications to make a decision if something similar already exists. However, I don't think we want Drupal contributions becoming something similar to SourceForge so what we have is a good solution that serves the community well. If you find modules with similar function then as a community member you could begin conversations with the module maintainers to try to come to common ground and combine the best of each module. If one of those modules is already defunct then request that the project be closed. Also realize there may be good reason to have them separated that you are not aware of. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/