On Fri, Jun 17, 2011 at 2:55 PM, Manfred A. Reiter <[email protected]>wrote:
> Can you understand, that due to the nature of OOo it always > had very strong language specific communities, wich significantly > contributed to the huge success of OOo? > > Interfering with the habits and cultures established within these > communties will in fact not take you any further than somebody > can say "we obeyed the Apache standard rules". > > The power of local communites which can act independently, > has proven to be especially usefull in these areas were competing > products simply couldn't offer a "consumer focused" localised solution. > > I'm just worried that you will alienate some very active contributors > by enforcing PMC rules just ... "because ..." > > For things that impact the product release, things like code contributions, documentation, translations, etc., things that actually could make the bits and bytes of the release different, I think it is very important that these pieces are done in Apache. And by being in the Apache project, they are covered by the Apache 2.0 license and by our consensus decision making process. For the activities that do not impact the actual contents of the release, things like user support, country- or language-specific marketing activities and so on, for these I could see other models working as well. Remember, with any Apache project, anyone is free to take the project's source code, translate it, build it and market it or even sell it. This could be done with modifications and enhancements. This is all possible under the Apache 2.0 license, whether you participate in the project or not. So if there are existing groups that do such activities under Sun/Oracle OpenOffice.org, then they can continue to do so, by using Apache OpenOffice. But when we start talking about the Apache project, then we are not talking about "groups" joining. We're talking about individuals joining. I don't think we want to have independent, autonomous groups within an Apache project. But I wonder whether one solution is this: 1) Strong existing language projects continue to operate independently, according to their own rules. 2) They ensure that their work is all done under Apache 2.0 license so it is usable by Apache OpenOffice as well as by LibreOffice 3) Language projects each appoint at least one member to join the Apache OpenOffice project as a liaison. -Rob
