www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Undermining the Incubator
Date Tue, 13 Jan 2004 04:21:50 GMT
Andrew C. Oliver wrote:

> I suggested that Blojsom might be a good choice for hosting ASF
> project news and might also make a great ASF project as I know
> the author is already indoctrinated

> I didn't say it would be a good project for the incubator.

The Incubator is how projects get into the ASF.

> I think the incubator is the #1 worst problem of the ASF presently.

Two things reduce the effect of your statement:

 1. The fact that your complaints demonstrate a lack
    of awareness regarding the current Incubator.

 2. The fact that your proposal essentially outlines
    how the Incubator *does* work.

We'll get to the latter shortly, but first ...

The Incubator exists for the purpose of importing codebases and projects
into the ASF.  There are basically three cases:

  (a) an externally developed codebase intended to go into an existing
  (b) an externally developed codebase intented to become a project within a
  (c) an externally developed codebase intended to be a new TLP

In the case of the (a), we need to clear the IP.  The Incubator STATUS file
provides an outline and diary for doing so.  The Community issues are
addressed because the code is going into an existing project.

In the case of (b), we need to clear the IP, and ensure that the project has
a viable community.  Again, the STATUS file has the guidelines.

Lastly, in the case of (c), we need to clear the IP, ensure that the project
has a viable community, and that the community is ready to take its place as
a TLP.

In all cases, decisions are made by a group made up of the Incubator PMC,
the project's committers, and the destination PMC (if any), and known as the
PPMC.  That is one group directly empowered to manage that project's
decisions, reporting through the Incubator, and collaborating together as
peers.  When the PPMC decides that the project is good to graduate, based
upon fulfilling the necessary criteria, it is done.

Now, since I know that you had a bad experience with the old form of the
Incubator, let's first address your complaints compared to the way things
work now.

> It doesn't legally protect the ASF.

The Incubator ensures that the proper paperwork is done regarding CLAs, code
grants, etc., are filed.  Something that the other projects failed to do
consistently enough to result in the Incubator's formation.  Ideally, the
Incubator provides a focus and location, and the project(s) interested in
the code perform the due diligance, but the process ensures that it gets

> * Exposes the Foundation to undue legal issues by protecting projects
>   to their legal issues being sorted out.

As opposed, for example, to exposing the Foundation to undue legal issues
when projects import codebases directly into releases without permission
from either the Foundation or the author?  That is one of the things the
Incubator exists to prevent.

In any event, only the Board should, and can, talk authoritatively about
legal protection afforded by the ASF.

> * Has a high potential to create a dead project zone over time (but this I
>   guess we'll see) as we give hosting and a fuzzy idea with many different
>   opinions on when a project gets out or not.

In actuality, one purpose of the Incubator is to help prevent non-viable
projects from becoming ASF projects, and to help projects become viable,
when possible.

We have a pretty good opinion as to when a project "gets out or not."  It is
embodied in the STATUS document, and in the minds of the PPMC, which would
vote for the project to graduate.

> * Has a number of people not involved in the project sitting roost over
>   project.

The Incubator doesn't work that way.  The people involved in the project are
directly involved in the project's management.  Ask the members of the Spam
Assassin PPMC, the Geronimo PPMC or the Directory project whether or not
there are "a number of people not involved with the project sitting roost"
over them.

> * Hurts already healthy communities by putting them back into an alphaish
>   state.

Healthy communities with clean codebases are not intended to stay within the
Incubator.  Projects in the Incubator are there because they have not yet
been able to complete the STATUS file successfully.  Whatever reasons exist
for them to be in the Incubator are those that a potential user should know.

> * Creates confusion.  Most people will believe the project is an Apache
>   project at the point of incubation.

Which is it?  Confusion that the project is an ASF project, or provides some
sort of indicator that the project is in a particular state?

> It doesn't protect the users

Incubation status indicates that a project is not yet an official ASF
project, and may have IP issues and/or community issues that could effect
its viability and suitability.

> is a big fat bureaucratic mess where the disinterested/uninvolved
> sit roost over the project.

The Incubator process is about as direct as it gets, without bureaucracy.
Each project has a STATUS file listing acting as a combination checklist and
fill-in-the-blanks project diary.  The form needs to be filled out.  If
everything is OK, the project is good to go.  If there are issues that need
to be addressed, the PPMC collaborates to resolve them.

So now let's look at your proposed solution, which you feel:

> * Protects the foundation
> * Makes the responsible people responsible and less "help"
>   from the peanut gallery.
> * Gives the "acceptance" to the project and the people
>   accepting it.  No more tricameral votes.

You propose that:

> * A project must have at least sponsoring MEMBER willing to go join the
>   project and help them adopt the voting rules, document legal issues by
>   performing an audit

We call such people Mentors.  They are members of the project's PPMC, and
participate as peers on that collaborative body to direct oversight of the
project.  You know: the way an ASF project is supposed to work.

The primary difference between your proposal and reality is that we don't
require every Mentor to be a Member.

> * A project's acceptance is governed by a PMC accepting it or the members
>   voting to create a TLP.  This should be ratified by the board who should
>   have veto power.

Projects are accepted into the Incubator based upon the vote of a PMC:
either a PMC that wants to oversee the project upon exit, or the Incubator
PMC on request of an ASF Member or Officer.  The Board does have to vote to
create a TLP in the event of such a project exiting.

The primary difference between your proposal and reality is that the Board
is empowered to create a TLP.

> * To propose the vote a project must prove that all CLAs are turned
> in and a license audit has been performed under the supervision of
> the said sponsoring member/members.

Correct.  All of which are in that STATUS file.

The primary difference between your proposal and reality is that the PPMC is
the body vested with supervisory responsibility, not an individual, which is
a legal issue.

> * prior to the project's acceptance into Apache it has no Apache status
> (legal/otherwise).  I suppose we could give it a candidate logo.

You mean like http://incubator.apache.org/images/apache-incubator-logo.png?

> I would warn any prospective project what it faces with the incubator

It seems to me that since the Incubator is essentially what you propose, all
you are doing is damaging the ability of the Foundation to grow by
needlessly poisoning projects against entry.

> I will continue to speak my mind publicly about things that I see as
> broken or incorrect

> When will I stop?  When they are fixed.

Based upon comparing the Incubator with your own proposal for it, it is
evident that the Incubator was fixed.  Things did change.

	--- Noel

To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message