incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <>
Subject RE: Why solve a problem that doesn't exist?
Date Thu, 07 Aug 2003 12:02:30 GMT

Jochen, you wrote:

> Quoting Greg Wilkins <>:
> > However, open process is at least as important as open software.
> Agreed. But the ASF has just given a bad example on this (IMO).
> Following the discussions on Geronimo in the last days, my
> impression is that a lot of decisions (in particular architecture)
> has already made behind the scenes. I do not even know who took
> those decisions, or how they look like.

I think that this is a very unfair comment, and would like to take some time
to explain why I believe this.

Apache doesn't have a simple way to start a project from scratch, but does
have mechanisms for accepting existing projects.

I expect that it is simpler and more productive for the sponsoring
individuals and the Apache process to start the project first, and then have
it accepted into the Apache incubator.

There is little reason why any aspect of a project cannot be changed
retrospectively should the community reach agreement, those reasons are
pretty much limited to conforming with the project's charter, the legal
obligations of the ASF, practical constraints imposed by infrastructure, the
rules governing contributors roles[1], and whatever additional rules are
imposed by the project itself.
In this case the governing project is the incubator, but if or when geronimo
becomes a fully fledged Apache project those rules themselves are open to
modification by the community through its project management commitee.
Once geronimo has become an Apache incubator sub-project it will be governed
by Apache's rules and processes, therefore no condition that pre-exists the
creation of the project is treated any differently from any condition
arising afterwards, if you don't like decisions that have been made when the
project was a private one you will be at liberty to comment on them and
lobby for change, or if you are elected as a commiter you will be able to
make proposals and cast binding votes. For example the rules governing
Jakarta and inherited by Jakarta sub-projects are documented here other project have similar
processes[2], it is this, and other interpretations of "The Apache Way" that
characterises the management of Apache projects.

One final point I'd make is that Apache doesn't pretend to have entirely
open management, Apache has to exist in the real world of lawyers and
corporations, but it does exist to foster collaborative and consensus based
process. This commitment can be best illustrated by refering you to the very
first paragraph of the ASF website[3].

"The Apache Software Foundation provides support for the Apache community of
open-source software projects. The Apache projects are characterized by a
collaborative, consensus based development process, an open and pragmatic
software license, and a desire to create high quality software that leads
the way in its field. We consider ourselves not simply a group of projects
sharing a server, but rather a community of developers and users."

I've been part of this community for a bit more than a couple of years now,
and I can assure you that I've never experienced any decisions which have
been sucessfully imposed without either consensus or a majority vote of the
appropriate constituency, and remember this is a meritocracy, to join the
constituency and help make the decsions you care about all you really have
to do is to demonstrate your willingness and ability to participate at the
appropriate level.



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

View raw message