So, like I said, I clearly missed what you suggested as fixes to the
problems that you perceive. While I'm sure that this discussion belongs
on the incubator list, rather than here, I have a strong suspicion that
you're going to respond with a note to the effect that you've already
been through this and don't want to again.
Okay Rich, I'll take you up on one. I don't feel like digging up the stuff
I've noted on the JCP so lets talk about the incubator.
Hopefully you don't mind me quoting that much publicly, if so I apologize.
I feel this should take place on community@ as its a question on whether the
incubator is serving the interests of the foundation and should exist at
all. Seems kind of funny to discuss should this thing be here there.
Problems:
* Exposes the Foundation to undue legal issues by protecting projects PRIOR
to their legal issues being sorted out.
* 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.
* Has a number of people not involved in the project sitting roost over the
project.
* Creates confusion. Most people will believe the project is an Apache
project at the point of incubation.
* Hurts already healthy communities by putting them back into an alphaish
state.
Solution:
* Disband the incubator.
* 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
* 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.
* 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.
* prior to the project's acceptance into Apache it has no Apache status
(legal/otherwise). I suppose we could give it a candidate logo.
This:
* Protects the foundation
* Makes the responsible people responsible and less help from the peanut
gallery.
* Makes members responsible.
* Gives the acceptance to the project and the people accepting it. No
more tricameral votes.
Issues:
What about how things were before?? The incubator sought to solve what was
essentially a communication issue via more process. I suspect it was also
created (I read this in emails by some of its proponents and Sam replied
that¹s not what I voted for as a board member or something to that effect)
originally as a flood gate to slow or prevent the growth of Apache. I think
the communication issue (about oversight) has been solved. In fact I rather
thing we've gone a little too far in the other direction. Some projects are
just lazy and haven't done their auditing. Other projects are more
vigilant. I think this is normal. What could be done about it I don't know
for sure but the incubator doesn't further that, maybe the PMCization thing
did, but I think moving the responsibility down the latter will do more,
then some manner of accountability (dirty word I know in a volunteer
organization).
The incubator was also supposed to help projects obtain their base
resources. What is really needed here is a request tracker for the
infrastructure project (which should become more of a project and less of
well what it is but that is a rant for another day).
To reduce contention and further compromise, I support grandfathering. I'm
not going after Geronimo.
Let me go on record, I do not hate Apache or the whole institution I just
think some of the decision made over the past year or so have been in
conflict with the letter if not the spirit of the open in open source. I
also want to help people in, not force them out. I think Apache has its
place, of course we all have different opinions on what that is.
-Andy
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership. In fact they probably most definitively disagree with
everything espoused in the above email.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
