On 08/16/2010 09:32 PM, Justin Erenkrantz wrote: > On Mon, Aug 16, 2010 at 6:26 PM, Ross Gardler <rgard...@apache.org> wrote: >> I've already decided that I'm going to have to recruit a number of key >> mentors to help me protect the project during incubation. > Historically, I think there are two classes of podlings: > - one which has a self-governing community and just needs to get > indoctrinated in the "Apache Way" (SpamAssassin, Subversion, etc.) > - one which doesn't have a self-governing community (thrift, traffic > server, etc.) > > Perhaps Greg is on to something with having us split up the process. > It's always bugged me that there were two different classes that we > tried to shoehorn into one process. > > Accordingly, in these two models, the role of the mentor is very different: > - self-governing community: making sure they get introduced to the > right people and understand the minimum requirements; but, really, > they shouldn't interfere with the actual day-to-day governance. > - no self-governing community: helping the developers understand what > it means to self-govern.
As a non-member, with cursory interaction with Apache over a very long term (some very small contributions to some projects), and a very recent interest in getting a project into incubation at Apache, this problem looks very different to me. Supposition: Involvement in projects will always follow a power-law for # of interested parties. Even within Apache, some projects will dominate with a large number of interested parties, and the rest will eventually taper off into a "long-tail." Supposition: Due to potential "bit-rot", Apache wants to make sure that projects have an ongoing commitment over time. Otherwise, projects will start out, gather some interest, and then people will drift off an do something else. Unchanged left-over code will "bit-rot" - as the language/compilers and supporting libraries for the code in question change, the code that works on top of those libraries/languages needs to stay current. Security problems might crop up in the most obscure places, and need to be addressed by an active community. Consequence: Apache wants to make sure that projects sustain a commitment over time. Incubation is the proxy for judging this question - if a project makes it through incubation, presumably it will sustain itself. The proxies are indirect data points, like three independent committers, filing reports on time, voting out a release, nailing down licensing issues. This brings me to Justin's analysis. The distinction that Justin makes above doesn't seem quite right to me. To me, it isn't a question of "self-governing" - Apache should be able to clearly lay out a process, deadlines & guidelines - and sure as heck, people who write down rules for how a computer works ought to be able to follow rules/processes for people. If they cannot, they don't belong at Apache, as they cannot self-manage. Lay out the rules, however odd they might be, and as long as they're clearly communicated, and there are people who are familiar with the rules to guide newbies along, you'll get people who can self-manage. For the projects that fall on the high end of the power-law spectrum, following the rules isn't a problem. And I suspect, actually, it isn't really for projects on the low-end of the spectrum - except that they're simply unfamiliar just like everyone else, and might need more training/attention/mentoring, because they're less likely to have the experts from Apache already deeply involved. Putting my former management hat on, (and oversimplifying dramatically) this seems like a training/education problem, and you solve it with a bunch of techniques - training sessions, "quizzes", materials that everyone is expected to master, presentations/interactions at conferences, etc. This probably isn't all that theoretically hard, it just needs a little bit of constant attention, and needs to be applied to all newcomers. What makes it practically difficult is that it isn't interesting to people who want to right code, and it is actually hard to do well, as the best materials take the viewpoint of a newcomer. I see a particular problem screaming out of the incubation reports for many of projects in incubation (and the problem we're having with our proposal). How to attract and sustain attention from people already involved with Apache, and attracting committers from everywhere? As I see it, this almost by definition falls out of the "power-law" curve I mentioned above. There will be some percentage of projects (1/2, 1/3rd?) that struggle to meet the criteria laid out. Self-governing *shouldn't* be a problem, because people should be told up front - "understand these materials, then see if you really want to join the party." What will naturally be a problem, though is that the bottom half or bottom third of the incubating projects need to attract and sustain attention. Seems like developing and sustaining that attention really should be the role of the incubator - training on the rules ought to be an incidental piece. Anyway, coming back to Justin's division, I see three or four chunks instead of his two: - high visibility projects. Really no doubt that they have commitment over time. Just need training on rules. Switch from incubation to full project should involve as few rule changes as possible, so as to minimize retraining. - near-high projects - like high-visibility projects, but run the risk of having "spoilers" that can sap the community, and other things that can derail the involvement. How do you protect against that? - middling projects - can get lost in mechanics - like simply delivering a release. Can be killed by a small amount of community-sapping behavior. Need prodding from the community to release early, release often, and sustain high standards. Need some help gathering interest, and need to fend off community sappers. - low visibility projects - like middling projects, but need lots of help with gathering interest. Need prodding to spend less time coding, and more time community building - reaching out to other Apache projects, contacting and engaging with similar open-source projects not at Apache, perhaps working with people in academia, blogging, etc. My point - a one-size fits all approach is effectively doomed to cause some unnecessary failures. That doesn't mean that you cannot have one set of rules for what must be done, but it does mean that how those rules are applied is effectively different. Put differently, does the incubator aim to help projects succeed at Apache once accepted into incubation, or does the incubator simply let chips fall where they may, and let interesting projects die? Maybe I'm just a naive newbie to look at it this way, but I thought I'd throw out my $0.02. -Eric. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
