community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: Some clarification needed for Apache Extra projects - Apache Extra in specific
Date Fri, 28 Sep 2012 21:45:55 GMT
I though Ross was very clear in his explanation, but apparently not...
<rant please-ignore="true">Unfortunately this thread (happens too often 
at the ASF) is digressing into hypothetical, vague and philosophical 

Quoting Ross: "this *is* completely different". As an aside, I 
personally don't consider subscribing a private@ PMC mailing list to 
another list the smartest thing to do, I'd rather have individual PMC 
members subscribe and inform the rest of the PMC. That however doesn't 
cause any issue because, quoting Ross again, that's just a 
"communication link". I would add that that is a unidirectional 
communication link, by which the external project communicates something 
of interest to an audience, and a PMC happens to be part of said 
audience. The PMC is a *passive* participant.

This is not the case of the camel-extra project. Apache Camel is an 
integration framework. Its intent is to simplify integration by 
providing a common API and bridging glue components for a large number 
of protocols and data formats. The specific protocol implementations 
however come from 3rd party libraries. For most of the technologies of 
interest, Camel found/uses libraries with a compatible license. The 
camel-extra project was created to extend the reach of Apache Camel to 
technologies available under non-compatible licenses (e.g. xGPL). The 
project was started and controlled by Camel committers on google code 
and later moved to apache-extras (kinda the same thing). The camel-extra 
project was never governed as an ASF project from many points of view, 
including oversight, release process and IP management. The project had 
committers who are not ASF committers for instance. The Apache Camel 
committers have control over the project and are *active* in the 
government of the project *as individuals* (albeit not completely 
following the ASF guidelines). This is the difference.

There is a (valid) perception that the camel-extra is an extension of 
the Apache Camel project. That was fueled by the fact that some 
camel-extra components are documented on the ASF camel site. This thread 
was actually started by an enthusiastic request of a new Apache Camel 
committer on the premises that "it would be nice if" Apache Camel were a 
one stop shop for both projects/communities. I.e. why work in 2 places, 
2 sets of infrastructure, etc, when Apache Camel is already the 
established/recognized one. While it would be nice for users indeed, it 
is not compatible to the way the ASF operates. (To use your analogy, 
think more like the LibreOffice community operating from within the 
Apache OpenOffice community, using the same site and mailing lists).

FWIW, this was mentioned on the camel lists, but that was probably not 
considered enough. Christian, the Camel PMC chair, knowing full well the 
dynamics of the community, did the right thing and decided to forward 
the question/request to a more authoritative forum. In the meanwhile the 
Camel community got the message from all replies in this thread (I 
think) and the changes currently made to the camel-extra project reflect 
the differences between the two communities. However the thread lingers 
on on this list...

I hope this clarifies the current status a bit better.

On 09/28/2012 03:44 PM, Rob Weir wrote:
> On Fri, Sep 28, 2012 at 4:13 AM, Ross Gardler
> <> wrote:
>> On 28 September 2012 02:41, Rob Weir <> wrote:
>> ...
>>> Specific example.  OpenOffice podling has signed up for a security
>>> mailing list where we receive security-related bug reports from
>>> LibreOffice, an open source project that is LGPL/MPL, not ALv2.  We do
>>> this by subscribing our security list directly to theirs.  Is this
>>> against policy?   This seems directly analogous to a project receiving
>>> bug reports from a non ALv2 Apache Extras project.
>> This is completely different. LibreOffice is a separate project with a
>> separate infrastructure and community. The subscription of an ASF list
>> to a LibreOffice list is nothing more than a communication link
>> between two distinct entities. The proposal here is to not create a
>> separate project with a separate management structure but to simply
>> host incompatible code externally and manage it from within an ASF
>> PMC.
> Exactly my point.  To the question put earlier:
>   "whether mailing list connections and other conveniences would create
> unacceptable confusion
> about the distinction between 'things the PMC does' and 'things some
> PMC members happen to do elsewhere.'"
> IMHO, the mailing list connections are not the issue.  The issue is
> the relationship between the Apache Extras project and the Apache
> projects.  If the relationship is improper, from a control and
> dependency perspective, then that is the problem.  The mailing list
> use connection does not create the problem.  And I suspect that
> avoiding the mailing list connections would change nothing fundamental
> if there were a control and dependency issue.
> Regards,
> -Rob
>> Ross
>> --
>> Ross Gardler (@rgardler)
>> Programme Leader (Open Development)
>> OpenDirective

View raw message