On 2/20/09, J Aaron Farr <[email protected]> wrote: > > On Thu 19 Feb 2009 01:12, Henning Schmiedehausen <[email protected]> wrote: > >> I agree, we do suck at managing small projects... > > Because small projects don't need to be managed. > > The ASF is setup for development by peers, not single, small projects. > Our organization just doesn't "scale down" that way. Labs is the best > approach we've had so far, but we deliberately put limits in place that > make Labs uncomfortable for projects that will remain small.
As Henning posted, the only way that a new TLP would be feasible would be adopting rules to make things uncomfortable for products that don't remain small. One mailing list, one authority for releases plus some sort of high barrier to committership (perhaps no new outside committers). The board should require frequent reports with collective responsibilty for failure (Sam's nuclear option - every project must report or the project is closed to all). > Honestly, I'm not sure if there's a good solution for something that's > bigger than labs, but likely never large enough to escape the > incubator. Of course, some TLPs are pretty small, so really as long as > there were three committers / members interested in taking something > from labs to TLP, incubation should be pretty straight forward. Incubation relies in a credible exit strategy. Projects which are tiny cannot graduate without a suitable TLP to act as a home. For example, RAT had a useful codebase, enthusiastic mentors and was staffed by all old Apache hands. Incubation has just about killed the project since the code is mature but there's no suitable TLP for graduation into. > > Finally, there's technically nothing stopping anyone from doing releases > of Labs code outside of Apache... The issue I see is that some of these codebases will become important or essential for existing Apache products. Having a proj...@apache gives us the paperwork we require to smoothly find alternative maintainers in the event of the creators going AWOL. More broadly, as we approach the end if our decade, we should start looking at the future with decades in mind. Projects are born, live then die. The cost of forking a GPL'd project is low - the viral license ensures contributors grant enough rights. Forking a permissively licensed project is much more costly in terms of auditing. Forking a permissively licensed project after the community and infrastructure have died may be too risky. Apache needs to think about ways to ensure that it's ecology is protected for the future. I think we need to start thinking about evolving our model to encompass a wider range of services. Robert > > -- > J Aaron Farr jadetower.com [US] +1 724-964-4515 > 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 > > --------------------------------------------------------------------- > 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]
