incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: What do we do at Apache versus what do we do elsewhere?
Date Mon, 20 Jun 2011 09:23:04 GMT

> 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

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:

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

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
- 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:


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.


>   - 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


View raw message