Hi Jukka, >>>>>> Graduating into a Lucene subproject is probably out of the question given the structural changes in Lucene, so for now my recommendation would be to remain in the Incubator until the community balance gets better. ... To put things in perspective, since the beginning of this year Karl has made over 96% of all ManifoldCF commits. This makes the bus factor [1] of the project pretty high, and suggests that a more diverse development community is needed. <<<<<<
The nature of this project is unique in that only a few committers are interested in any given connector. Committer interest in proprietary connectors is even more limited; people who are using these connectors do not in general become open-source contributors or committers. I therefore don't think we're going to be able to avoid having a high "bus factor" for this project. Thus, if a low bus factor is the main criteria, it seems pretty unlikely to me that ManifoldCF will ever graduate from the incubator. An approach I've been trying to use is to have at least one committer per connector. This requires some flexibility on the matter of considering what makes a good committer, since for ManifoldCF domain knowledge is perhaps the most important consideration. I am hoping for some consideration by our mentors in this regard, since it is clear to me that we should not expect a contributor that knows about CMIS to also be an expert in Active Directory (for example). So, as I've discussed before, the criteria for becoming a ManifoldCF committer has to be more nuanced and must take domain knowledge into account, if we are to have anything like a committer base that covers all the code. I wouldn't mind not graduating, except for two issues. First issue is that being in the incubator limits adoption of the software. It convinces enterprises that the software is not ready for prime time, which I believe is a false impression, but there it is. It also causes Manning (the book publisher) from withholding the production release of the ManifoldCF in Action book as well. So it becomes a bit of a chicken-and-egg problem. The second issue is that releases and decision-making processes are overly cumbersome when the incubator is involved. This is unfortunate since the goal of being in the incubator, as I understand it, is simply to ensure that the project has sufficient familiarity with Apache standards and procedures to not mess up too badly. I guess what I'm arguing for is a somewhat different set of graduation criteria that is more suited to ManifoldCF's unique situation. Karl On Wed, Sep 21, 2011 at 5:41 AM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Mon, Sep 19, 2011 at 9:06 PM, Karl Wright <[email protected]> wrote: >> (a) what we are still missing as far as incubator graduation is concerned > > There's still quite a bit to be done for community diversity. The > drive to get new committers in is definitely a step in the right > direction, but we'll need to follow up on that to make keep at least > some of the new people as active members of the community. This is an > area where mentors should be able to help (I'll try to increase my > involvement here). > > To put things in perspective, since the beginning of this year Karl > has made over 96% of all ManifoldCF commits. This makes the bus factor > [1] of the project pretty high, and suggests that a more diverse > development community is needed. The solution is not to have Karl > commit less, but to get other people to more actively join the fun. > > The situation here is roughly similar to what we experienced during > the incubation of Apache Tika. In the last year before graduation > (2008) I was responsible for about 87% of all commits, which raised > similar concerns about diversity [2]. The solution then was to > graduate into a Lucene subproject instead of a full TLP, so that the > larger project could still provide oversight and continuity in case > things went wrong. > > Since then Lucene has shed out most subprojects to avoid being too > large to manage, and by the time Tika in 2010 became a TLP by itself > my share of all commits had shrunk to a still high but much more > reasonable 62%. Today I'm still the most active committer, but my > share of all the activity is down to 44%. > > I'd like to see ManifoldCF follow a similar trajectory. Graduating > into a Lucene subproject is probably out of the question given the > structural changes in Lucene, so for now my recommendation would be to > remain in the Incubator until the community balance gets better. > > Some of the key things I did in Tika to help reduce my central role > there were to lower the barriers of entry by working on things like > the Getting Started page [3] and adding tools like the runnable > tika-app jar and the simple GUI interface that make it trivially easy > for someone to get started using Tika. > > The Build and Deploy guide in ManifoldCF [4] and the start.jar > mechanism are good steps in this direction, but I think we could > streamline quite a few of those steps. As Tommaso and others already > mentioned, things like a simpler build process and a nicer UI can be > quite useful. These are things that don't usually mean much to people > already familiar to the system, but for potential new users and > contributors with a short attention span they matter a lot. Thus I > think these are areas that we should try to focus on in near future. > > [1] http://en.wikipedia.org/wiki/Bus_factor > [2] http://markmail.org/message/bvqs2zv762fmlyv5 > [3] http://tika.apache.org/0.9/gettingstarted.html > [4] http://incubator.apache.org/connectors/how-to-build-and-deploy.html > > BR, > > Jukka Zitting >
