incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <>
Subject incubation process for open development open source projects [WAS Re: Glasgow - community? specs? other issues?]
Date Sun, 06 Aug 2006 20:05:13 GMT
On 8/5/06, Eelco Hillenius <> wrote:
> On 8/4/06, William A. Rowe, Jr. <> wrote:
> > Eelco Hillenius wrote:
> > >> I understand that there are some specific circumstances in this case,
> > >> but in general I believe this sort of criteria is why we get
> > >> complaints that it's impossible to "innovate" at Apache any more.  We
> > >> require all the grunt work of innovation to occur outside of Apache.
> I did not write that actually. I'm sorry I hijacked the VOTE thread.
> It's one of the (hopefully) few things to get used to over at Apache,
> as at Wicket we aren't that formal about it.

it's not a formality here - it's a necessity. the volume of mail is
just too great otherwise.

> Here is the blurp that attracted my attention, followed by my thoughts:
> > I understand that there are some specific circumstances in this case,
> > but in general I believe this sort of criteria is why we get
> > complaints that it's impossible to "innovate" at Apache any more.  We
> > require all the grunt work of innovation to occur outside of Apache.
> >
> > The issues of an open specification is one thing.  But aren't "proven
> > an actual community" and "work the standard 'apache way'" graduation
> > requirements, not entry requirements?  If we expect something coming
> > into the incubator to already have a fully functioning, health
> > Apache-style community, then the only point of the Incubator is for
> > handling licensing issues.
> This is quite interesting...
> Over at Wicket we have been operating 'the Apache way' from a very
> early stage in the project (about two years).

just FYI the consensus now is that 'open development' is a better term
than 'the apache way'

> We have mail archives,
> commit logs, releases, and history of letting new committers in to
> prove all that if people are willing to spend an hour looking for it.
> But we feel we have to prove ourselves all over again as the
> incubation process expects it's podlings to prove themselves within
> the confines of the incubation process.

i think that a certain amount of public scrutiny is an inevitable
consequence of the democratic nature of the process. i'm hoping that
better documentation will help the people who have to go through it
feel a little better about it...

> The incubation process might benefit from having a categorization of
> projects that want to enter. Such categorization basically answers:
> * How old are these projects, how many committers, how large is the
> community of developers and users?
> * Has the project been working apache style for a certain time (the
> time being a categorization in itself). If it has, there is no
> question about prove - it'll be there as that is one of the key
> factors of working the apache way (mailing lists, committers etc.)?

AFAICT the proposal was intended to cover this ground

i have it in mind to try to add specific sections into the entry guide
under development ATM targeted at the different categories of project
that might want to entry the incubator.

> This categorization would then be the starting point for answering two
> things that I think are currently missing in the whole incubation
> process (please do tell me if I am wrong/ missed something):
> * To what extend can information about the project's readiness be
> gathered based on the (outside) history of the project, and how much
> information needs to be gathered additionally during incubation? The
> availability of such history could get some load of the backs of the
> involved parties and might mean a shorter incubation time.

this should be covered by the status file. i would hope that mature
open development/source open source projects would be able to tick
everything but the legal stuff straight away. the legal stuff usually
takes a while for open source projects. how long depends on how good
the records tracking contributions are.

> * What would be the proposed time estimate for the whole incubation?
> Factor time currently seems to be non existent in the incubation
> process. But 'it takes how long it takes' imo does not cut it.

"it takes how long it takes" really is the only good answer whether it
cuts it or not

the process is democractic - graduation is by election

> I believe the incubation process would benefit from formalizing
> timelines and milestones so that both parties keep focussed on making
> progress. Having a schedule for incubation would also mean that
> involved parties could use that schedule for any other plans they
> might be making.

there's no reason why a project shouldn't set it's own goals. for
projects with a strong community and a history of open development, a
lot depends on the energy expended towards the goal of graduation.

> For example, we (Wicket) would like to have our 2.0
> version to be released at Apache, after (if) we're done with
> incubation. There is currently no way to even remotely predict when
> that might happen. This is inconvenient for our users, but also is a
> problem as we are writing a book on that version and our publisher
> *does* want to know when that book will be ready for publishing.
> Having a code base that is release-ready but that's just waiting for
> months for the incubation process to move on for some unknown time is
> unacceptable to us.

the problem with due diligence is that it's not possible to tell a
priori how long it'll take to complete. it does seem to have a habit
of dragging on.

> The kind of schedule I am thinking of would be
> semi-binding. If we meet the requirements for the milestone in time,
> we go on to the next stage, unless there is absolute consensus we
> shouldn't based on something other that the milestone requirements. If
> we don't meet the requirements in time, incubation may be terminated
> for that reason alone.

requirements are assessed democractically. graduation is proposed when
the mentors feel that the project is ready. the incubator PMC votes.
this may then be followed by a board vote if the project is heading
for top level status.

IMHO the incubator should not impose timescales or a schedule on a
project but a project may decide to impose a timescale on itself. the
project is (of course) equally free to ignore or interpret this
schedule as it pleases since it is not binding on apache.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message