incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Why top level is good for you [was Re: [PROPOSAL] PMC Vote to incubate Directory Project]
Date Fri, 19 Sep 2003 12:22:34 GMT

On Friday, Sep 19, 2003, at 10:08 Europe/Rome, Jochen Wiedmann wrote:

> Nicola Ken Barozzi wrote:
>
>> Even if all Jakarta projects get top-level (which I doubt), Jakarta 
>> as a community can still remain. It is a place where Java developers 
>> can get together on common issues. Jakarta doesn't have to dite, it 
>> just needs to find it's own correct space, more about coordination 
>> ang getting together rather than being held accountable for a miriad 
>> of projects that it cannot possibly keep track of.
>
> No doubt. But do you think, the same community could be *established* 
> between, say, alexandria.apache.org, bcel.apache.org, bsf.apache.org, 
> cactus.apache.org, ...?
>
> I know, I am exaggerating. Just for illustration. But: My impression is
> written on the emails on this list, which I have read in the past few 
> days.
> About four or five new proposals, each of them expressing their wish 
> "to
> become a TLP".  Today eight or ten current subprojects proposed for 
> TLP.

Jochen,

you (and many others, I'm sure) probably don't know that the "flat the 
foundation" campaign went on inside the ASF for at least three years 
before the ASF could find consensus on what it was good to do.

When jakarta was created, there was a strong intuition that what you 
are saying above was right. To put it simply: "a project is like a 
family and it's easier to educate people in a family".

As long as jakarta was the only one and contained a few efforts 
(tomcat, ant and a few moved from the deprecated-for-legal-issues 
java.apache.org) there were no problems.

Then came xml.apache.org and things started to get messy. The first XML 
PMC was a political one, homesteaded by the donations of companies that 
wanted to jump on the bandwagon. It looked way to corporate. I was part 
of it and I reported signs to the members.

At that point, a division inside the ASF started to happen: the members 
coming from the HTTP/APR world thought that PMCs were great and were 
working just fine, the members (a great minority at that time) coming 
from jakarta/xml, suggested PMC to be useless beurocratic things that 
shielded people from understanding what the foundation was.

The 'flat the foundation' campaign started but received *strong* 
opposition from the board for at least 2 years.

The board believed that "project containment" was a good thing and that 
eventual problems were due to human issues, they were not structural.

The 'flatters', on the other hand, pointed out that the problem was 
structural: a PMC works best when it is composed by people that care 
about the project and a project must have the fewer number of efforts 
possible.

A few things started to change the picture:

  1) Gump
  2) Problems in the Avalon community that the jakarta PMC was unaware 
of (there was not Avalon representation in that PMC at that time)
  3) Problems in project-inflicted categorization

Let me go thru all of them:

1) Gump shows that dependencies between the various ASF projects don't 
increase "inside the container project". This showed, pretty evidently, 
that the assumption that "projects in the same container cooperate 
better", it's totally and utterly false. In fact, there has been much 
more cooperation between xml and jakarta than between jakarta itself.

2) The jakarta PMC failed to identify problems in the avalon community. 
Jakarta showed three level of containment as efforts such as Avalon and 
Turbine started to build their own sub-sub-projects inhouse in order to 
avoid having to go thru the PMC. If there is no legal oversight, the 
foundation is in danger.

Following the HTTPD/APR history (where PMC were reported to work just 
fine), the flatters suggested to help promoting the concept that a PMC 
should be composed by committers of a particular codebase, or a 
collection of codebases highly intercommunicating.

3) the other problem is that, just like all librarians know: 
categorization is politics. What is good for you, cannot be good for 
me. Jakarta categorizes for programming language, XML for data syntax, 
WS for marketing scope. Cocoon fits in all of them... choosing which 
one becomes a political issue. A political issue which is useless and 
utterly energy wasteful.

                                   - o -

The result of 3 years of debate is the following consensus:

  1) each community should be allowed to escape the trap of umbrella 
containment and acquire their top level domain, if they want so

  2) the foundation will promote this but will not inflict it upon 
communities

  3) each PMC chair will be the link between the foundation and the 
project. the foundation wants projects to be as self-sufficient as 
possible, to allow scalability of the entire foundation, without 
loosing legal and community oversight. [note: PMC chairs are *NOT* part 
of the board, they are not even required to be ASF members]

  4) categorization should not be done by location, but by projects 
exhibiting metadata that is later used to present a software map of the 
foundation. [Needless to say, this software map has not been 
implemented]

                                    - o -

As I understand and resonate with your concerns as a user, I believe 
that Noel is completely right in indicating that there are different 
issues on the table:

  1) usability of the foundation information infrastructure

  2) structure of the foundation itself

Nobody ever suggested that 1) should be a direct mapping of 2) even if, 
historically, this has been the case.

Great efforts have been made by the foundation to improve our 
infrastructue and our ability to cope with new service needs. Work is 
undergoing. Progess (due to lazyness, inertia, need for high 
availability) is slow, but steady.

Believe me when I say that your concerns are well visible in the ASF 
mind, but also, please understand that there are also important reasons 
to change the structure of the foundation itself and impact on users 
(at least initially) is a price that we are willing to pay in order to 
have a more scalable and more legally safe foundation.

HTH

--
Stefano.


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


Mime
View raw message