Good call Serge (and Sam). This (IMHO) takes us back toward what open
source is all about. I have been a heavy user (and occasional contributor)
of open source software since linux 1.2 was released.
In recent times, open source projects seem to be to have become far more
rigid in their scope and direction than used to be the case. It used to be
that if you wanted to add a feature to an open source app, you just got the
source, added the code and submitted a patch. Now, committers seem to be
less receptive to code that does fit with thier idea of "project scope" and
"direction" and/or has not been discussed to death on the dev list. Check
out the tomcat list archives for a discussion just prior to the 3.3 release
where most of the active commiters disagreed with one guy who was keen on
continuing active development of the 3.x codebase rather than the 4.x
codebase. That was, (IMO) resolved the "right" way - the code was branched
and both parties got their way. (I was a heavy tomcat user at the time and
would not have been pleased with having to step up to the 4.0 codebase that
early on in its life.)
While it is important to retain design cohesion, it is at least as
important to allow contributors to "scratch their itch" [Homesteading the
noonsphere]. That is what get people interested enough to contribute code
and thus makes for a healthy and lively development community. Take a look
at ant, netbeans and the linux kernel for examples of projects that allow
huge scope for feature diversity, without compromising the project at all.
ADK
--------------------------------------------
There is no magic.
Serge
Knystautas To: [EMAIL PROTECTED]
<sergek@lokite cc:
ch.com> Subject: [Fwd: Convergence, vetoes,
forks, and projects]
24/12/2002
03:46
Please respond
to "James
Developers
List"
Last week there was some disagreement about the impact of vetoes and
related matters, and in light of signficant changes we're expecting for
James and mailet API "v3" and the discussions that would preceed them, I
thought it would be useful to build some consensus as to how those
discussions should be structured. This would be to minimize procedural
disagreements and bring everyone closer to a single set of assumptions,
as well as guidelines how to contribute to the discussion.
I'm attaching an email from Sam Ruby on [EMAIL PROTECTED] that (IMHO)
captures how many ASF projects work, and I think begins to lay this
framework.
Any and all comments appreciated.
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
----- Message from Sam Ruby <[EMAIL PROTECTED]> on Tue, 19 Nov 2002 20:11:12
-0500 -----
To: [EMAIL PROTECTED]
Subject: Convergence, vetoes,
forks, and projects
One nice thing about conferences is it permits a number of high
bandwidth conversations that aren't practical via e-mail. I've talked
to a number of people about the topics that have been discussed on this
mailing list, and thought I would share some of my notes. These are
merely meant to capture my understanding at this point in time, and not
meant to be interpreted as authoritative.
- - -
All ASF projects need to move towards a direction whereby participants
with commit privileges, voting rights, and PMC membership are largely
converged. The current model whereby an umbrella project is permitted
to exist with separate code bases with separate communities and is
administered by a PMC which is largely separate from those committers is
neither sustainable nor legally defensible. This is not a statement
about number of CVS repositories or mailing lists, but merely one of
commit privileges and voting rights.
Vetoes are, as a general rule, anti-social behavior and are to be used
sparingly. They are to be used to draw attention to stop-ship types of
bugs and resolvable design disputes. Simple bugs should simply be
handled routinely via e-mail, bug tracking mechanisms, or by directly
making the fixes. Significant design disputes should be handled via
internal forking ? allowing a separate proposal directory or perhaps
even CVS tree to be created whereby a speculative design is explored.
Forks should be clearly identified with separate names per the rules for
revolutionaries e-mail. For external forks, i.e., ones that reside
outside of ASF servers, this is all that is necessary. For internal
forks, it is important to realize that the PMC is still accountable for
that code and the rules for voting and commit privileges still apply.
In other words, the creation of such internal forks is to be done based
on consensus on the scope, visibility, and design direction of such an
effort. This does not mean that there needs to be consensus of opinion
on the viability of the design approach; merely that the idea merits
exploration - even if the ultimate result is only to prove that it is
indeed a dead end.
As long this code resides under the purview of an existing PMC, no
separate voting or commit rights should be sanctioned for this code.
Nor should vetoes be used after the fact to change the agreed upon scope
of such an effort.
Separate code bases with separate communities should be separate
projects. Independent of the size of the codebase, if the size of the
community is only a few people, then it is not an ASF project. Such
efforts can be pursued outside of the ASF, be pursued inside the
Incubator, or be incorporated inside an existing community ? as long as
all participants in that larger community are treated as peers.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
