incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <...@robweir.com>
Subject Re: Apache project community and external community
Date Wed, 31 Aug 2011 17:04:46 GMT
On Tue, Aug 30, 2011 at 6:00 PM, Raphael Bircher <r.bircher@gmx.ch> wrote:
> Am 30.08.11 22:30, schrieb Rob Weir:
>>
>> (renaming the thread since it has drifted)
>>
>> On Tue, Aug 30, 2011 at 3:49 PM, Raphael Bircher<r.bircher@gmx.ch>  wrote:
>>>
>>> Hi Rob
>>>
>>> Am 30.08.11 20:52, schrieb Rob Weir:
>>>>
>>>> On Tue, Aug 30, 2011 at 2:38 PM, Raphael Bircher<r.bircher@gmx.ch>
>>>>  wrote:
>>>>>
>>>>> Hi Rob
>>>>>
>>>>> So you want to split the community into a official apache and a
>>>>> inofficial
>>>>> extendet community? That will happend if you will fellow strictly the
>>>>> apache
>>>>> way. Then we will have the Development here and the rest outthere. If
>>>>> this
>>>>> is good or bad, I don't know. But if it's like that, we should start
to
>>>>> organize te inofficial Community.
>>>>>
>>>> Are there some aspects of the Apache Way that the OOo community does not
>>>> like?
>>>>
>>>>     * collaborative software development
>>>>
>>>>     * commercial-friendly standard license
>>>>
>>>>     * consistently high quality software
>>>>
>>>>     * respectful, honest, technical-based interaction
>>>>
>>>>     * faithful implementation of standards
>>>>
>>>>     * security as a mandatory feature [1]
>>>>
>>>> I'd be interested in hearing why these aspects of the Apache Way are
>>>> unacceptable.  Maybe it would help if you explained what you think are
>>>> the core beliefs of the OOo community and where they are in conflict
>>>> with the above.
>>
>> Thanks for the good response, Raphael, this is useful to discuss.
>>
>>> Not the points above but the flowing
>>>
>>> * That it's strange to organize Events under Apache
>>>
>> Of course Apache events will be organized by Apache, just like
>> LibreOffice events are organized by The Document Foundation.  That
>> should not be very odd.
>>
>> Also, there can be third-party events, not run by Apache.  If these
>> events use the Apache name or project trademarks or logos then they
>> require coordination/approval with the Apache Conferences Committee:
>>
>> http://www.apache.org/foundation/marks/events.html
>>
>> I don't think this is a very severe constraint.  There are a lot of
>> informal "barcamp" style events that could be organized by project
>> members.  If we coordinate with the Conferences Committee I don't see
>> a problem here.  Things ranging from hack fests, etc., are all
>> possible.
>>
>> What will not be possible is for an independent group of volunteers to
>> organized an event in their country, and call it "Apache OpenOffice
>> Foo" and hold this event without coordinating and seeking the approval
>> from the Apache Conferences Committee.  But if they do the
>> coordination, then I don't see a problem.
>
> The Organization is only one problem. But Event need also a budget, even
> they are free. And get money for Events from the ASF would be hard. And
> don't beleve that a other NGO will sponsoring the event if they can't
> presenting themself as sponsor.

Ross gave a good link on this:

http://wiki.apache.org/concom-planning/ConComSupportedEvents

It looks like Apache has a lot to offer for events.  You should read
through that.

It might help, also, to have a concrete proposal.  I think the process
and the possibilities would be much clearer if someone had an actual
event they wanted to propose.  Then we would see how the process
works.

Obviously, end-user related events are hard to do before we have a
release.  But what about an AOOo "MeetUp" (as described in the page I
linked to above)?

>>
>>
>>> * The Apache fundrising politic
>>>
>> That is harder.  An independent group could obviously do fundraising
>> on its own, but I don't see how it could use the Apache brands for
>> this.
>
> That's not the question. The point is that the ASF dosn't cover all our
> needs. ASF covers
>
> * The infrastructure for offizial stuff
>
> * Travel assistence for same elected events (We don't know how many dollars
> they will pay for OOo)
>
> * Maybe, but only maybe same Events, but I'm sure not all.
>
> I see no fundrising for
>
> * Marchendising, Marketing Material usw.
>
> * Direct sponsoring for Devs, eg. Students etc.

Apache participates in Google Summer of Code, so there could be an
opportunity for us to involve students and mentors through that
program.  But in general you are correct.  Apache does not pay for
development.  But nothing prevents you and others from forming your
own non-profit to raise money to fund developers.  Remember, the rule
is not that developers on Apache projects cannot be paid.  Obviously
IBM pays me, for example.  The rule is that ASF and their projects do
not raise money and pay developers.  But 3rd parties are welcome to
sponsor developers.


>>
>>> * The fact that Apache has no concept what to do with people outside
>>> developing.
>>>
>> Could you be more specific?  Marketing, event organizing, fundraising,
>> etc., are all things that can be done in Apache, but they are done at
>> the ASF level, not at the project level.  Similarly, you don't see
>> anyone doing a fundraiser for LibreOffice Calc.  It is all done at The
>> Document Foundation level.
>>
>> Within the project there are ways for everyone else to participate:
>> programmers, testers, documentation authors, translators, user
>> support, UI design, web design, etc.
>
> Sure it's possible, but ASF is not designed for it, and that make it hard to
> do this under apache. Don't forget, you can doing not a load on ASF level if
> you are not a Member or a PMC. And PMC and PPMC are not the same. And for
> same People is also a Language barriere. There exist a load of people with
> strong OOo knowage and a big marketing knowage but with small english
> experiences. This people will never show up at Apache, forget it! But this
> are the people wich are needed for Events etc

I think you are putting too much importance on PMC/PPMC membership.
We don't have many more capabilities than anyone else on the list.  In
particular, the restrictions on fundraising, event planning, use of
trademarks, etc., are equally restrictions on PMC/PPMC members.  We
all follow the same rules.

Language barrier is important, yes.  But that has always been an
issue.  When OOo organized conferences in Lyon, Barcelona, Orvietto
and Budapest, it did not assume everyone spoke French, Catalan,
Italian and Hungarian.  We relied on local event planners to organize
things locally, but then have local members who could also speak
English to coordinate with the rest of the project.  Same thing with
Apache.  You could have a local 3rd party group propose an event, do
most of their planning work in their local language.  So long has they
have a single good English speaker to liaise with the Apache project
and Apache Conferences Committee, I think that would be fine.

>>
>>> * The fact that only no permisive Lisence are alowed
>>>
>> This is certainly true for code and content that are part of a
>> release.  Apache 2.0 license is a key part of how Apache works.
>>
>>> * The fact that we have to rewrite all the documentation including
>>> translation cause Lisence Issues
>>>
>> There may be other options here.  For example, when IBM donates the
>> Symphony code, we can also contribute the documentation and
>> translations.  This is all original work from us, which we can give
>> under ALv2.
>
> Do you ever take a look in our documentation? Do you know how big it is, and
> wich quality level the documentation has? Do you realy think the IBM
> documentation can cover this. I beleve that IBM make a good contribution on
> coding Base. Don't forget, docomentation is one part of OOo that the
> Community has a heigher contribution level as SUN and Oracle. Well you can
> release your documentation under ALv2 but please don't be disapointed if
> people continue to work on the old documentation instead the one from IBM.

It is not useful to get into a quality debate about documentation.
Symphony serves an enterprise market, and has professionally authored
documentation, not community-developed documentation.  It meets our
needs.  It may be worth evaluating it to see if meets the needs of a
wider group of users.

>>
>>> * The Fact that is nearly impossible to get a Native language List.
>>>
>> I think that is mainly a start up issue.  We're trying to avoid
>> premature fragmentation by splitting into too many mailing lists too
>> early.  We want to encourage discussions like this, which everyone
>> (hopefully) will read.
>
> Forget this, only the dev@de.oo.o has more subscribers as the ooo-dev@i.o.o.
> As I said. Many people will never show up there or don't read the list realy
> cause language barrieres.
>>
>>   We'll get more mailing lists over time.  But
>> part of getting the community to come together is to get us all in the
>> same virtual room (this mailing list) and debate these issues until we
>> are said what we need to say.,
>>
>>> It does not mean that we have a complete split. But same kind of activity
>>> has simply no place unter apache, or are so hard to integrate that no one
>>> will do it. So it's much better to do it outside, as to skip it or do
>>> nothing.
>>>
>> There are examples of this already, like oooforums, odfauthors, etc.
>> I think these projects like these could be done under Apache as well.
>> There is nothing procedural, technical or legal that would prevent it.
>>  A sign of a healthy open source projects is that it spawns
>
> Yes, you can grow up a service without the OOo brand. but oooforums and
> odfauthors are bad exemples for it. oooforums was strongly promoted on the
> OOo website and odfauthors was founded because the unhappynes of the tools
> provided by OOo. ODFAuthors make the official OOo documentation as far as I
> know.

And that is fine.  I think we can continue to link to websites of
related projects.

>>
>> derivatives and other projects.  Look at Linux.  Look at OOo, with all
>> the versions and other projects it created.  This has always happened
>> and always will happen.  This is not a bad thing.  But I think we
>> still want to ensure that the "core" work on what we consider to be an
>> AOOo "release" occur in the project, under ALv2, according to Apache
>> procedures, etc.
>
> I'm not say, that it's a bad thing. So maybe a split of the Apache Community
> and the extended community is a big chance. but it needs collaboration with
> the two or more parties and a little bit planing. It makes no sense to try
> to press all under apache. It brings apache stress and makes us unhappy. So
> it's better to be honest, and evaluate what's realy on the right place under
> Apache and for what we have to search for a solution outside.

It comes down to this in the end:  It is easier to complain than to do
something about it.  Novell complained about how OOo was run for
around 5 years before they split off to LibreOffice.  You can ask them
how large the effort was.  It was not easy.  Aside from creating
technical infrastructure, you need to think about non-profit status,
governance, taxes and other filings, fundraising, etc.  And then you
can start thinking about the code, and users and support.

If you work at Apache, you can start working on the code and the other
parts of the release almost immediately.

So I think there is a strong incentive to try to work within the
Apache project, even if it means doing things differently than they
were done with OOo.

>>
>> As always there are forces that tend to split projects apart:
>>
>> 1) Desire for autonomy
>> 2) Technical differences
>> 3) License disagreements
>> 4) Personality conflicts
>> 5) Disagreement on level of formality
>> 6) Disagreement on pace of work
>>
>> and so on.
>>
>> And there are forces that tend to keep projects together:
>>
>> 1) Shared accomplishment
>> 2) Shared infrastructure
>> 3) Economies of scale
>> 4) Critical mass of expertise
>> 5) Personal identification with project
>> 6) Established user base and network of  after-market goods and services
>>
>> and so on.
>>
>> Every project, new or old, deals with opposing forces like this.
>> We're really no different than any other project.  We need to be
>> honest about what the challenges are and face them.
>>
>>
>> Regards,
>>
>> -Rob
>>
>>> Greetings Raphael
>
>
> --
> My private Homepage: http://www.raphaelbircher.ch/
>

Mime
View raw message