To clarify my statement on project dependencies:
I think that Derby has already grown a large and diverse community around itself, and that is important to consider as well. Projects dependent upon derby, be they ASF or otherwise, have a significant second-order effect on the project's truck number. Other ASF projects dependent on Derby are a useful metric here as we are familiar with those projects, to a greater or lesser degree.
Things Derby depends on (except from the licensing and technical points of view) are not particularly relevant to estimating Derby's viability (1), but things dependent upon Derby are quite relevant to estimating Derby's viability. If you throw away good will and solely base motivation on need, projects which have healthy communities which rely on Derby are strongly motivated to help maintain Derby -- if the current maintainers are incapable of doing so (otherwise most people are happy to work on their own stuff).
That is the point I was awkwardly wandering towards. It is *not* a substitute for the contributor/committer pool on the project itself, but it is a relevant measure of the developer community invested in Derby.
-Brian
On Apr 3, 2005, at 11:51 AM, Brian McCallister wrote:
On Apr 3, 2005, at 11:02 AM, Rodent of Unusual Size wrote:
At least one person from the DB PMC has voted in favour of graduation, which I hope means that the project understands the issues of assuming oversight and feels comfortable doing so. Having more people from the DB PMC/project weigh in on the vote would be nice. :-)
DB PMC hat on:
The only thing weighing on me about graduating Derby is that all the committers, but one, work for the same employer. There are a number of other folks under consideration, but they aren't committers (yet, hopefully).
Ken makes a good point about it not being a TLP, and the DB PMC prodding the developer community growth. I have to agree with this argument, especially when I put it next to the DdlUtils project (commons-sql) with, er, two committers.
Derby depends on nothing else at Apache (except ant for its build), and is depended on by nothing else at Apache. This is *good* from a technical point of view, but is a weakness from a community health point of view.
To use DdlUtils as an example again, despite that project having only two (active) committers on the project, another Db project, OJB is dependent on the project (which is a big chunk of the reason we want to get it out of the commons sandbox), and has a strong motivation therefore to keep it going. OJB has a pretty good sized committer base, and has already pushed past the ~retirement of the initial project leader (who still pokes his head in on big design issues, but is otherwise pretty much inactive). So, despite DdlUtils having a small committer base when aiming for the same level in the ASF hierarchy (subproject), it has a much larger developer community strongly motivated to maintain it, even if they are not committers on it now.
Derby has a much larger committer base, but that committer base is rather homogenous by ASF standards. No other ASF projects I am aware of (except maybe Geronimo?) actually use Derby right now, or use it in such a way that swapping out to HSQLDB isn't trivial. This lack of dependency is good, technically, but does not build a strong community support system (if all the BeanUtils committers were hit by trucks, there is no real doubt that other Struts folks would step in immediately).
DB PMC hat off:
I don't doubt the long-term viability of Derby. It is a great project which works well, and has a responsive and growing developer community. Even if the IBM committers were to be informed they were no longer allowed to contribute under terms of their employment, I am confident that despite the slowdown that would occur, the developer community would step up (the db pmc would just need to do more work in the interim).
I don't know "official ASF policy" on subproject acceptance (if there even is such a thing), so have timeboxed my voting decision so that I can learn more before having to chime in =)
-Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
