You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ap...@robweir.com> on 2011/06/17 14:43:29 UTC
What do we do at Apache versus what do we do elsewhere?
I've seen several posts asking about how the core OOo development project
will relate to the other activities such as user forums, translations,
releases, language projects, etc. I thought it would be good to have a
single thread to discuss the general issues.
As many of us know, with OpenOffice.org under Sun/Oracle, there was a
widespread community of semi-autonomous projects, under the
openoffice.org"umbrella". One way to divide this is by the
"development" functions, by
which I mean the things that lead directly to the artifacts that were part
of the official OOo releases:
- programmers, including localization and accessibility
- testers
- product documentation
- UI design
- content designers for templates, samples, etc.
- build/release management
I think that it will be ideal to get all volunteers working in this set of
functions into the same Apache OpenOffice.org project, under the same
license, and working together.
And then there are other functions that helped promote and support the
releases and the users who adopted the releases:
- marketing
- support forums
- event organizers
- and many other similar functions
I think these groups are welcome to join the Apache project, but they would
need to consider the trade-offs. If they have autonomy now, run their own
servers, elect or appoint their own leaders, etc., then moving to Apache
means merging their structures into the Apache project, mapping their roles
into contributor/committer/PMC member roles, adopting their web sites to the
Apache infrastructure, working openly on the Apache mailing lists, allowing
anyone to work on it, as well as allowing anyone to review and comment on
their work. In other words, they give up some control and in return have a
potentially larger group of people to help them.
But let's be honest. If the Romanian language project decided to work
entirely in Apache on their translations, the chances are that very few
existing Apache members would be of much assistance to them, as a volunteer
or as a reviewer. So I'm not seeing a compelling benefit for all of the
language projects to join Apache. But I could see something like this:
- Language projects remain autonomous, but agree to put a compatible
license on all of their work, e.g., the Apache 2.0 license
- Each language project appoints one of their members to join the Apache
OOo list, so we can stay coordinated.
- Ideally, there will be one or more volunteers from the language
projects who get more involved, in larger localization issues, and via their
feedback and patches, ensure that OOo continues to meet the needs of a
international audience. These volunteers would likely then be voted in as
committers and PMC members.
For marketing, user forums, event organizers, etc., I can easily see these
being done in the Apache project, to the extent they are "international" in
scope. But It isn't clear how in an Apache project we would coordinate a
group that, for example, was only interested in planning marketing, support
and events for Romanian OOo users.
I'd be interested in other views on this. In particular, if we went down
the other road, and assimilated all language projects into Apache, how does
the process of lose consensus and meritocracy work if project members are
segregated into mailing lists where discussions occur in, e,g., Romanian.
So in summary, I think the different function groups need to consider the
costs and benefits of adapting to an Apache project model, which would
include:
- Working openly on the Apache mailing lists, allowing anyone to
participate and allowing anyone to review your work, and potentially even
veto it.
- Moving servers and websites onto Apache infrastructure
- Giving up titles from other organizations and working in the Apache
project meritocracy
- Agreeing that your product contributions will be available under Apache
2.0 license
-Rob
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Jean Hollis Weber <je...@gmail.com>.
On Fri, 2011-06-17 at 18:25 -0400, Rob Weir wrote:
> On Fri, Jun 17, 2011 at 5:33 PM, Jean Hollis Weber <je...@gmail.com>wrote:
>
> > Just a small comment here: the "product documentation" in your first
> > list is, I assume, the Help shipped with the product.
> >
> > There is another set of documentation, the user docs, which mostly
> > produced by the community. These include user guides -- available in
> > ODT, PDF, wiki (OOo 3.2 and earlier), and printed form -- and the
> > documentation wiki (containing, among other things howtos, tutorials,
> > faqs, etc). IMO these user guides and wiki items are in the "user
> > support" area, along with support forums -- a subset of your "many other
> > similar functions".
> >
>
>
> So you call the integrated product documentation "Help", and the
> supplemental guides "user doc"? I understood the distinction, but didn't
> know the existing naming convention.
>
> -Rob
Yes, I use the generic term "user docs" to distinguish between
supplementary material written for ordinary users and documents written
for developers and programmers, which I call "developer docs". BTW, the
latter are not produced by ODFAuthors.
--Jean
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Rob Weir <ap...@robweir.com>.
On Fri, Jun 17, 2011 at 5:33 PM, Jean Hollis Weber <je...@gmail.com>wrote:
> Just a small comment here: the "product documentation" in your first
> list is, I assume, the Help shipped with the product.
>
> There is another set of documentation, the user docs, which mostly
> produced by the community. These include user guides -- available in
> ODT, PDF, wiki (OOo 3.2 and earlier), and printed form -- and the
> documentation wiki (containing, among other things howtos, tutorials,
> faqs, etc). IMO these user guides and wiki items are in the "user
> support" area, along with support forums -- a subset of your "many other
> similar functions".
>
So you call the integrated product documentation "Help", and the
supplemental guides "user doc"? I understood the distinction, but didn't
know the existing naming convention.
-Rob
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Jean Hollis Weber <je...@gmail.com>.
On Fri, 2011-06-17 at 08:43 -0400, Rob Weir wrote:
> I've seen several posts asking about how the core OOo development project
> will relate to the other activities such as user forums, translations,
> releases, language projects, etc. I thought it would be good to have a
> single thread to discuss the general issues.
>
> As many of us know, with OpenOffice.org under Sun/Oracle, there was a
> widespread community of semi-autonomous projects, under the
> openoffice.org"umbrella". One way to divide this is by the
> "development" functions, by
> which I mean the things that lead directly to the artifacts that were part
> of the official OOo releases:
>
> - programmers, including localization and accessibility
> - testers
> - product documentation
> - UI design
> - content designers for templates, samples, etc.
> - build/release management
>
> I think that it will be ideal to get all volunteers working in this set of
> functions into the same Apache OpenOffice.org project, under the same
> license, and working together.
>
>
> And then there are other functions that helped promote and support the
> releases and the users who adopted the releases:
>
> - marketing
> - support forums
> - event organizers
> - and many other similar functions
Just a small comment here: the "product documentation" in your first
list is, I assume, the Help shipped with the product.
There is another set of documentation, the user docs, which mostly
produced by the community. These include user guides -- available in
ODT, PDF, wiki (OOo 3.2 and earlier), and printed form -- and the
documentation wiki (containing, among other things howtos, tutorials,
faqs, etc). IMO these user guides and wiki items are in the "user
support" area, along with support forums -- a subset of your "many other
similar functions".
The user guides are produced by an autonomous group formerly known as
"OOoAuthors" (now called "ODFAuthors"), which uses its own website (on a
server provided by TDF) for tracking production of the documents. Those
documents are then made available for download through the OOo wiki.
I think we therefore fall into the category that you describe below,
with all the potential tradeoffs that you have mentioned. So I am very
glad that you started this thread. I shall have more to say later.
--Jean
> I think these groups are welcome to join the Apache project, but they would
> need to consider the trade-offs. If they have autonomy now, run their own
> servers, elect or appoint their own leaders, etc., then moving to Apache
> means merging their structures into the Apache project, mapping their roles
> into contributor/committer/PMC member roles, adopting their web sites to the
> Apache infrastructure, working openly on the Apache mailing lists, allowing
> anyone to work on it, as well as allowing anyone to review and comment on
> their work. In other words, they give up some control and in return have a
> potentially larger group of people to help them.
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Christian Grobmeier <gr...@gmail.com>.
> Could you say a little about "subprojects" and how they work at
> Apache? Are they the same as "components"? Do they have their own
> PMCs and their own list of committers?
If you look at logging.apache.org, you see log4j, log4php and log4net
among others. These projects have only little in common, except they
have similar configuration files. I (log4php) am not even subscribed
to the log4net lists.
They do not have the same list of committers in common, but sometimes
they overlap.
But the PMC is global across all products.
Guess you can name it "components" as well. There are no guidelines on that.
Here is a link which illustrates a bit more:
http://people.apache.org/committers-by-project.html
Look for the "logging*" sections.
Cheers,
Christian
>
> -Rob
>
> On Mon, Jun 20, 2011 at 5:23 AM, Christian Grobmeier
> <gr...@gmail.com> wrote:
>> Rob,
>>
>>> And then there are other functions that helped promote and support the
>>> releases and the users who adopted the releases:
>>>
>>> - marketing
>>> - support forums
>>> - event organizers
>>> - and many other similar functions
>>>
>>> I think these groups are welcome to join the Apache project, but they would
>>> need to consider the trade-offs. If they have autonomy now, run their own
>>> servers, elect or appoint their own leaders, etc., then moving to Apache
>>> means merging their structures into the Apache project, mapping their roles
>>> into contributor/committer/PMC member roles, adopting their web sites to the
>>> Apache infrastructure, working openly on the Apache mailing lists, allowing
>>> anyone to work on it, as well as allowing anyone to review and comment on
>>> their work. In other words, they give up some control and in return have a
>>> potentially larger group of people to help them.
>>
>> You are right, they share control. This is what every apache project
>> has to consider. But anyway I would welcome every of the groups which
>> wants to join. There is a Community project at the ASF (Ross is active
>> there) and there is an Event-Project around, who already organize
>> Barcamps and such things. I can imagine that a merge of that groups to
>> the other ASF groups will give some kind of turboboost to all related
>> parties.
>>
>> Marketing: this is so important for ooo. Do you think it would be
>> efficient to let them do their job "somewhere outside"? I am afraid in
>> that case communication will start leaking and marketing will finally
>> stop somehow. The near "location" of these two groups, dev and
>> marketing is a benefit. And if marketing people would like to join, I
>> think I would be very glad.
>>
>>> But let's be honest. If the Romanian language project decided to work
>>> entirely in Apache on their translations, the chances are that very few
>>> existing Apache members would be of much assistance to them, as a volunteer
>>> or as a reviewer. So I'm not seeing a compelling benefit for all of the
>>> language projects to join Apache. But I could see something like this:
>>>
>>> - Language projects remain autonomous, but agree to put a compatible
>>> license on all of their work, e.g., the Apache 2.0 license
>>> - Each language project appoints one of their members to join the Apache
>>> OOo list, so we can stay coordinated.
>>> - Ideally, there will be one or more volunteers from the language
>>> projects who get more involved, in larger localization issues, and via their
>>> feedback and patches, ensure that OOo continues to meet the needs of a
>>> international audience. These volunteers would likely then be voted in as
>>> committers and PMC members.
>>
>> So, if the language projects are outside from the ASF, do we need to
>> copy over their files into our own source control? Or is it "just a
>> dependency"? If we need to copy the files over, how can we make sure
>> the IP is clean?
>>
>> Maybe the language project should be treated as an own subproject
>> within OOo. But I don't think it would be so much easier for all the
>> language people to stay outside the project. At least when you start
>> having some "core volunteers" at the ASF doing the bigger chunks
>> you'll end up having a i18n structure at the ooo project and probably
>> a subproject.
>>
>> At least I guess it is not very motivating for people. I mean, one
>> could say, he has done something for OOo, but is not part of the team.
>>
>>> For marketing, user forums, event organizers, etc., I can easily see these
>>> being done in the Apache project, to the extent they are "international" in
>>> scope. But It isn't clear how in an Apache project we would coordinate a
>>> group that, for example, was only interested in planning marketing, support
>>> and events for Romanian OOo users.
>>
>> Please look at this page:
>> http://barcamp.org/
>>
>> This might be a good starting point for such a discussion.
>>
>> I am not 100% sure how these barcamp stuff all works. I just know
>> there are ASF fellows who work with that.
>>
>> Additionally we could collaborate with community.apache.org.
>>
>> If we can propose some kind of a standard way for the organizing
>> people, then we have made the game. I somehow believe it could happen
>> with the three elements:
>> - Orga-ooo for generel questions, tipps, announcments
>> - community.apache.org for - no idea - ASF wide marketing, help,
>> community building?
>> - barcamp for the organizing of events
>>
>>
>>> I'd be interested in other views on this. In particular, if we went down
>>> the other road, and assimilated all language projects into Apache, how does
>>> the process of lose consensus and meritocracy work if project members are
>>> segregated into mailing lists where discussions occur in, e,g., Romanian.
>>
>> Good question.
>>
>> My first idea would be, ooo needs subprojects.
>>
>> ooo-language as a global i18n container
>> ooo-romania as a local part of this project
>>
>> I believe the romania people can have their consens on language
>> related matters on their own (wording, grammar etc.).
>> For all things which are more global (whatever that could be) the
>> ooo-language list is needed. For example, format of the i18n files,
>> new language discussions, or other decisions.
>>
>>
>>> So in summary, I think the different function groups need to consider the
>>> costs and benefits of adapting to an Apache project model, which would
>>> include:
>>
>> Yes.
>>
>> Not sure what the others mentors say. But my personal feeling is, a
>> project should work on one place. I am not sure if a separated ooo
>> will survive.
>>
>> BTW, my answer are feelings and opinions, not "mentor advises". In
>> fact I have no experience with what I responded too and just want to
>> help to get out the best.
>>
>> Cheers,
>> Christian
>>
>>>
>>> - Working openly on the Apache mailing lists, allowing anyone to
>>> participate and allowing anyone to review your work, and potentially even
>>> veto it.
>>> - Moving servers and websites onto Apache infrastructure
>>> - Giving up titles from other organizations and working in the Apache
>>> project meritocracy
>>> - Agreeing that your product contributions will be available under Apache
>>> 2.0 license
>>>
>>>
>>>
>>> -Rob
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>>
>
--
http://www.grobmeier.de
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jun 20, 2011 at 8:41 AM, Rob Weir <ap...@robweir.com> wrote:
> Could you say a little about "subprojects" and how they work at
> Apache? Are they the same as "components"? Do they have their own
> PMCs and their own list of committers?
This is a controversial subject within the ASF.
It is possible to partition code by subdirectories and manage
authorization by these partitions. Some have done this in the past.
Some still do. Others believe that committers can largely be trusted
to stay within their area of expertise, and that it is always possible
to revert inappropriate changes and deal with bad behavior.
It is important that PMCs have oversight of all of the subprojects.
The canonical anti-pattern that is often cited is when I was chair of
Jakarta, which at the time was loosely "all things Java at the ASF
excluding XML". This covered a lot of area and suffice it to say that
the PMC did not exercise sufficient oversight over all of the areas.
The solution was to spin off a number of top level projects... ant,
tomcat, etc. Each has their own PMCs. Each is self-governing.
That's the true goal here: establishing one or more self-governing
projects. If you can demonstrate that a single project with
subprojects is capable of self-governance, then this podling could
graduate as a separate project. If, however, there really is little
overlap between different efforts, then it is best structured as
multiple projects.
> -Rob
- Sam Ruby
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Rob Weir <ap...@robweir.com>.
Could you say a little about "subprojects" and how they work at
Apache? Are they the same as "components"? Do they have their own
PMCs and their own list of committers?
-Rob
On Mon, Jun 20, 2011 at 5:23 AM, Christian Grobmeier
<gr...@gmail.com> wrote:
> Rob,
>
>> And then there are other functions that helped promote and support the
>> releases and the users who adopted the releases:
>>
>> - marketing
>> - support forums
>> - event organizers
>> - and many other similar functions
>>
>> I think these groups are welcome to join the Apache project, but they would
>> need to consider the trade-offs. If they have autonomy now, run their own
>> servers, elect or appoint their own leaders, etc., then moving to Apache
>> means merging their structures into the Apache project, mapping their roles
>> into contributor/committer/PMC member roles, adopting their web sites to the
>> Apache infrastructure, working openly on the Apache mailing lists, allowing
>> anyone to work on it, as well as allowing anyone to review and comment on
>> their work. In other words, they give up some control and in return have a
>> potentially larger group of people to help them.
>
> You are right, they share control. This is what every apache project
> has to consider. But anyway I would welcome every of the groups which
> wants to join. There is a Community project at the ASF (Ross is active
> there) and there is an Event-Project around, who already organize
> Barcamps and such things. I can imagine that a merge of that groups to
> the other ASF groups will give some kind of turboboost to all related
> parties.
>
> Marketing: this is so important for ooo. Do you think it would be
> efficient to let them do their job "somewhere outside"? I am afraid in
> that case communication will start leaking and marketing will finally
> stop somehow. The near "location" of these two groups, dev and
> marketing is a benefit. And if marketing people would like to join, I
> think I would be very glad.
>
>> But let's be honest. If the Romanian language project decided to work
>> entirely in Apache on their translations, the chances are that very few
>> existing Apache members would be of much assistance to them, as a volunteer
>> or as a reviewer. So I'm not seeing a compelling benefit for all of the
>> language projects to join Apache. But I could see something like this:
>>
>> - Language projects remain autonomous, but agree to put a compatible
>> license on all of their work, e.g., the Apache 2.0 license
>> - Each language project appoints one of their members to join the Apache
>> OOo list, so we can stay coordinated.
>> - Ideally, there will be one or more volunteers from the language
>> projects who get more involved, in larger localization issues, and via their
>> feedback and patches, ensure that OOo continues to meet the needs of a
>> international audience. These volunteers would likely then be voted in as
>> committers and PMC members.
>
> So, if the language projects are outside from the ASF, do we need to
> copy over their files into our own source control? Or is it "just a
> dependency"? If we need to copy the files over, how can we make sure
> the IP is clean?
>
> Maybe the language project should be treated as an own subproject
> within OOo. But I don't think it would be so much easier for all the
> language people to stay outside the project. At least when you start
> having some "core volunteers" at the ASF doing the bigger chunks
> you'll end up having a i18n structure at the ooo project and probably
> a subproject.
>
> At least I guess it is not very motivating for people. I mean, one
> could say, he has done something for OOo, but is not part of the team.
>
>> For marketing, user forums, event organizers, etc., I can easily see these
>> being done in the Apache project, to the extent they are "international" in
>> scope. But It isn't clear how in an Apache project we would coordinate a
>> group that, for example, was only interested in planning marketing, support
>> and events for Romanian OOo users.
>
> Please look at this page:
> http://barcamp.org/
>
> This might be a good starting point for such a discussion.
>
> I am not 100% sure how these barcamp stuff all works. I just know
> there are ASF fellows who work with that.
>
> Additionally we could collaborate with community.apache.org.
>
> If we can propose some kind of a standard way for the organizing
> people, then we have made the game. I somehow believe it could happen
> with the three elements:
> - Orga-ooo for generel questions, tipps, announcments
> - community.apache.org for - no idea - ASF wide marketing, help,
> community building?
> - barcamp for the organizing of events
>
>
>> I'd be interested in other views on this. In particular, if we went down
>> the other road, and assimilated all language projects into Apache, how does
>> the process of lose consensus and meritocracy work if project members are
>> segregated into mailing lists where discussions occur in, e,g., Romanian.
>
> Good question.
>
> My first idea would be, ooo needs subprojects.
>
> ooo-language as a global i18n container
> ooo-romania as a local part of this project
>
> I believe the romania people can have their consens on language
> related matters on their own (wording, grammar etc.).
> For all things which are more global (whatever that could be) the
> ooo-language list is needed. For example, format of the i18n files,
> new language discussions, or other decisions.
>
>
>> So in summary, I think the different function groups need to consider the
>> costs and benefits of adapting to an Apache project model, which would
>> include:
>
> Yes.
>
> Not sure what the others mentors say. But my personal feeling is, a
> project should work on one place. I am not sure if a separated ooo
> will survive.
>
> BTW, my answer are feelings and opinions, not "mentor advises". In
> fact I have no experience with what I responded too and just want to
> help to get out the best.
>
> Cheers,
> Christian
>
>>
>> - Working openly on the Apache mailing lists, allowing anyone to
>> participate and allowing anyone to review your work, and potentially even
>> veto it.
>> - Moving servers and websites onto Apache infrastructure
>> - Giving up titles from other organizations and working in the Apache
>> project meritocracy
>> - Agreeing that your product contributions will be available under Apache
>> 2.0 license
>>
>>
>>
>> -Rob
>>
>
>
>
> --
> http://www.grobmeier.de
>
Re: What do we do at Apache versus what do we do elsewhere?
Posted by Christian Grobmeier <gr...@gmail.com>.
Rob,
> And then there are other functions that helped promote and support the
> releases and the users who adopted the releases:
>
> - marketing
> - support forums
> - event organizers
> - and many other similar functions
>
> I think these groups are welcome to join the Apache project, but they would
> need to consider the trade-offs. If they have autonomy now, run their own
> servers, elect or appoint their own leaders, etc., then moving to Apache
> means merging their structures into the Apache project, mapping their roles
> into contributor/committer/PMC member roles, adopting their web sites to the
> Apache infrastructure, working openly on the Apache mailing lists, allowing
> anyone to work on it, as well as allowing anyone to review and comment on
> their work. In other words, they give up some control and in return have a
> potentially larger group of people to help them.
You are right, they share control. This is what every apache project
has to consider. But anyway I would welcome every of the groups which
wants to join. There is a Community project at the ASF (Ross is active
there) and there is an Event-Project around, who already organize
Barcamps and such things. I can imagine that a merge of that groups to
the other ASF groups will give some kind of turboboost to all related
parties.
Marketing: this is so important for ooo. Do you think it would be
efficient to let them do their job "somewhere outside"? I am afraid in
that case communication will start leaking and marketing will finally
stop somehow. The near "location" of these two groups, dev and
marketing is a benefit. And if marketing people would like to join, I
think I would be very glad.
> But let's be honest. If the Romanian language project decided to work
> entirely in Apache on their translations, the chances are that very few
> existing Apache members would be of much assistance to them, as a volunteer
> or as a reviewer. So I'm not seeing a compelling benefit for all of the
> language projects to join Apache. But I could see something like this:
>
> - Language projects remain autonomous, but agree to put a compatible
> license on all of their work, e.g., the Apache 2.0 license
> - Each language project appoints one of their members to join the Apache
> OOo list, so we can stay coordinated.
> - Ideally, there will be one or more volunteers from the language
> projects who get more involved, in larger localization issues, and via their
> feedback and patches, ensure that OOo continues to meet the needs of a
> international audience. These volunteers would likely then be voted in as
> committers and PMC members.
So, if the language projects are outside from the ASF, do we need to
copy over their files into our own source control? Or is it "just a
dependency"? If we need to copy the files over, how can we make sure
the IP is clean?
Maybe the language project should be treated as an own subproject
within OOo. But I don't think it would be so much easier for all the
language people to stay outside the project. At least when you start
having some "core volunteers" at the ASF doing the bigger chunks
you'll end up having a i18n structure at the ooo project and probably
a subproject.
At least I guess it is not very motivating for people. I mean, one
could say, he has done something for OOo, but is not part of the team.
> For marketing, user forums, event organizers, etc., I can easily see these
> being done in the Apache project, to the extent they are "international" in
> scope. But It isn't clear how in an Apache project we would coordinate a
> group that, for example, was only interested in planning marketing, support
> and events for Romanian OOo users.
Please look at this page:
http://barcamp.org/
This might be a good starting point for such a discussion.
I am not 100% sure how these barcamp stuff all works. I just know
there are ASF fellows who work with that.
Additionally we could collaborate with community.apache.org.
If we can propose some kind of a standard way for the organizing
people, then we have made the game. I somehow believe it could happen
with the three elements:
- Orga-ooo for generel questions, tipps, announcments
- community.apache.org for - no idea - ASF wide marketing, help,
community building?
- barcamp for the organizing of events
> I'd be interested in other views on this. In particular, if we went down
> the other road, and assimilated all language projects into Apache, how does
> the process of lose consensus and meritocracy work if project members are
> segregated into mailing lists where discussions occur in, e,g., Romanian.
Good question.
My first idea would be, ooo needs subprojects.
ooo-language as a global i18n container
ooo-romania as a local part of this project
I believe the romania people can have their consens on language
related matters on their own (wording, grammar etc.).
For all things which are more global (whatever that could be) the
ooo-language list is needed. For example, format of the i18n files,
new language discussions, or other decisions.
> So in summary, I think the different function groups need to consider the
> costs and benefits of adapting to an Apache project model, which would
> include:
Yes.
Not sure what the others mentors say. But my personal feeling is, a
project should work on one place. I am not sure if a separated ooo
will survive.
BTW, my answer are feelings and opinions, not "mentor advises". In
fact I have no experience with what I responded too and just want to
help to get out the best.
Cheers,
Christian
>
> - Working openly on the Apache mailing lists, allowing anyone to
> participate and allowing anyone to review your work, and potentially even
> veto it.
> - Moving servers and websites onto Apache infrastructure
> - Giving up titles from other organizations and working in the Apache
> project meritocracy
> - Agreeing that your product contributions will be available under Apache
> 2.0 license
>
>
>
> -Rob
>
--
http://www.grobmeier.de