incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was re:OpenOffice.org branding)
Date Tue, 02 Aug 2011 15:36:23 GMT
On Tue, Aug 2, 2011 at 10:39 AM, Terry Ellison <Terry@ellisons.org.uk> wrote:
> Rob,
>
> I think that you've missed my point.  The guy didn't THREATEN to leave.  He
> HAS left.  I doubt we will get him back.  My strong reaction was because of
> that entirely avoidable loss of 5+ man-years of project expertise that we
> will be pressed to recover for the sake on an ill-considered shout-down.
>  Was this really wise?
>

No, I do not think it was wise of him to leave.  But, in the end, that
is his choice.  Participating in an open source project, where views
can be aired freely, is not for everyone.  You need the ability to air
opinions and proposals an discuss them respectfully,  But you should
never feel that an idea is unable to be discussed, or that other
members will threaten to leave because someone disagrees with them, or
if they find that their ideas are not loved.  That would only stifle
the free expression of views from other project members.

> Yes, I have only been on the DL for two days, but I have been a major
> contributor to community side of the OOo project for five years.  And in my
> 30+ years in this business, I've seen lots of f***ed up project take-overs
> in my business unit.  I was trying to flag up that this old dog is starting
> to sniff another one, and I would REALLY like to prevent this happening.
>

I assume that the project starts with a random assortment of prior OOo
members, members of related projects, members of other Apache
projects, members of the OASIS ODF standards committees, as well as
some new members "kicking the tires" to see what all the noise is
about.  Some of them will find that this project is not to their
liking.  Some will.  We should try to make this project be inviting to
new members, as well as old members.  But I suspect that incremental
growth will come mainly from new members.

But please tell me, what do you expect I should do when you or anyone
else repeatedly reads your resume to me?  Should I not be allowed to
question proposals?  Should it be considered rude to suggest
alternatives?  Should I feel that it would be in imposition to ask
"why?"  Should I feel that if I don't do exactly what you want,
without question, that you will leave the project?   Really?  Is that
the type of project you would want to work on?  Is that the type of
project that will best attract more contributors?

In terms of project structure and oversight, Apache OpenOffice is a
fresh start.  No one inherits their titles from the legacy project.
No questions are out of bounds.  Nothing is above question.  Yes, of
course, we shouldn't make arbitrary changes, without good reason, just
for the fun of it.  But where something did not work well before, like
achieving a consistent license on the documentation, then we should be
looking at making necessary changes.

And remember, we also have fewer code contributors today, because
there are some developers who are not willing to sign the iCLA or
agree with the Apache 2.0 license.  Should we change that requirement
as well?  I don't think so.  This is an Apache project.  The license
is not negotiable, even though that necessarily means that there will
be some who, for whatever personal reasons and beliefs they honestly
hold, will not be able to participate.


> You seem to be positioning yourself as the project leader and absolute
> arbiter of Apache policy, and YOU have caused a valuable asset to this
> project to walk, yet you seem to be totally unaware of this -- or are and
> don't care.  If we keep this up then this Apache project will drive away
> many if not most of the ex-OOo team who want to contribute.  You'll be left
> with an extremely tidy and well-managed DL but no OpenOffice product.
>

Starting an ad hominen attack does not do credit you or your arguments.

At Apache, every committer has the ability to veto a change.  Not just
me.  Far from it.

In any case, in order to move the argument forward, I'd like to
reiterate the specific concerns that I have, to which I've seen no
response other than "we don't want to change".  But no one is
addressing the fundamental questions:

1) How do we ensure that the future documentation is under the Apache
2.0 license so that it can be copied, modified and redistributed
freely by others?

2) How do we ensure that the documentation is under PPMC oversight and
remains high quality?

I'm open to discussions of various technical and procedural means to
achieve these goals.  But I am adamant in achieving them one way or
another.


> If this is the Apache way, then this will be a sad outcome.  But is this the
> Apache way or just your individual interpretation?  I do wonder what is the
> biggest project that you've run personally, or have you even done this
> before?
>

Did you read the link I sent on decision making at Apache?  Did you
have any questions on it?  If you actually read it, I don't think you
could possibly be asking the above question.


> Regards Terry
>
> On 02/08/11 14:40, Rob Weir wrote:
>>
>> On Tue, Aug 2, 2011 at 9:00 AM, TerryE<ooo@ellisons.org.uk>  wrote:
>>>
>>> <snip>
>>>>
>>>> Regardless... it doesn't matter to me anymore.  I'm stepping out of
>>>> this discussion now, and stepping away from anything to do with OOo
>>>> documentation, including the OOo Wiki.
>>>>
>>>> Clayton
>>>
>>> This was the outcome of an ill considered discussion.  Clayton, is the
>>> one
>>> guy who really understands how the documentation is put together.  He's
>>> been
>>> working full time on this for at least 5 years that I know of.  He was
>>> kicked in the teeth by Oracle, albeit for ration if perhaps impersonal
>>> commercial drivers, and now has to consider his future options.  Despite
>>> this and somewhat to my surprise he was willing to re-engage and support
>>> OOo
>>> in the future within Apache.  His departure would truly be a loss to the
>>> project and one that I think we all should regret.
>>>
>>> In my naiveté I did get the impression that the project would be a flat
>>> consensual collaborative organisation rather than a hierarchical dictat,
>>> albeit with the Apache umbrella.   OK, I fully accept that I don't
>>> understand the "Apache way" yet, but in my days in EDS I had technical
>>> oversight in taking over many account teams and ensuring continuity of
>>> service (most far larger than this project) as well as running large
>>> teams
>>> myself.  I have no interest in shovelling this shit in future but I do
>>> know
>>> how to get the team to vanish like sand through your fingers.  One sure
>>> way
>>> is not to listen to considered and rational experience, to ride roughshod
>>> over peoples input, and to use sarcasm as a tool in sensitive dialogue.
>>>  These people are volunteers contributing pro-bono, not servants.  If
>>> this
>>> is going to be the culture of this project, then it is going to wither
>>> and
>>> die.
>>>
>> By your strong reaction, Terry, after only being on the list for 2
>> days, I suspect that you are not yet accustomed to the way we are
>> debating.  No one is shutting anything down.  We're discussing.  When
>> there is consensus then we move forward.
>>
>> Decision making at Apache is described here:
>>
>> http://www.apache.org/foundation/how-it-works.html#management
>>
>> It is a good read.  In particular I see nothing about trying to force
>> decisions by threatening to leave the project.  But maybe I missed
>> that line ;-)
>>
>> And remember experience at OOo is not the sole fons et origo of
>> wisdom.  There are other sources of relevant knowledge and experience.
>>  We should try to respect all views raised on this list, and not try
>> to close down arguments by saying, "That's the way we always did it at
>> OOo" or "I'm more experienced in doing things my way, therefore
>> everyone else should yield".  Those are not ways to reach consensus.
>> Similarly, there are parts of Apache that are non-negotiable and areas
>> where we have some discretion in the project.  The Apache 2.0 license
>> is an example of something that is non-negotiable.
>>
>> -Rob
>

Mime
View raw message