It's not so much "dissonance" as an exception. In an incubating project, the developers are usually new to the ASF, and skipped the meritocracy step by virtue of association with the project before it entered Apache ("here's the list of committers"). Therefore it's reasonable to ask the incubating project to prove that not only can they write code, but they can build an active multi-participant community. If there really is still just one outside committer, then in my opinion the community has not yet passed that test; and rather than coding, those who care about that project should be advocating its existance to others, giving presentations at conferences, getting the middleware projects to support it as a peer to mysql and postgres, that sort of thing - all in the name of getting more outside involvement.
The irony here is that there is a steady increase in the size of the user community - both existing Cloudscape users converting over and new users looking for alternatives. This is demonstrated in the traffic on both the dev and user lists.
This is actually not limited to incubator projects - we've had issues before with projects whose committership was overwhelmingly from one employer. The issue wasn't the employer corrupting the decisions of the employees so much as the employees communicating privately with each other because they could, leaving out other developers; it also meant they were not incented to reduce the learning curve on the code or document internals, which would have increased outside involvement. The solution there is to slow down the pace of coding and do more community development, and ask "why are there so few other developers?". Even if the project is widely, you should ask "why are so few users of this software interested in becoming developers?".
One factor, I believe, is that this is mature technology that just works. My company embeds Derby in our product offering and, to date, we have not needed any changes from the engine itself and have been able to work with the documentation already provided by the project.
We have been involved in peripheral projects - integration between Derby and Geronimo, connector support in TranQL, porting sample applications to it (such as XPetstore), and more. However, all the work there has been in other projects.
Similarly we have seen involvement from Sun who were very quick to add Derby support to their appserver and whose people remain as active participants on the lists. Again this meant changes in their product and they did not need anything new from the project.
As usage increases we are seeing requests for new features and bugfixes and are seeing more people step up to develop them. This will lead to the increase in the committer base.
If you look at the community now, we do not see the warning signs Brian mentions above. The committers are acting independently, they just happen to work for the same employer. That remains the main concern of the IPMC and the project needs to work to address it.
-- Jeremy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
