avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [VOTE] Stephen McConnell as a committer
Date Tue, 28 Sep 2004 00:29:59 GMT
Peter Neubauer wrote:

> On Sun, 2004-09-26 at 08:24 +0900, David Leangen wrote: 
> 
>>I know I don't contribute much to the project. I am merely a user that began
>>using Avalon recently. I hope to become a contributor to the project, but
>>for now, I'm not. So, it's probably not really my place to make any comments
>>here.
> 
> 
> Thanks David for that reply. It is exactly that position that I am
> myself and that made me pull off this vote in the first place.
> 
> As for users/non-committers being part of the community, at least
> 1.whoever can start a vote,even a user
> 2.whoever can vote, even a user
> 3.only votes from members of the "community" (which is to be defined,
> but I think in this case accepted committers) are counted. Which I think
> highlights your point about who is counted part of the community.
> 
> The other question I think is relevant here is how long/much vetos are
> valid and why they are for lifetime right now, which can lead to
> inactive members of the community blocking progress because of old
> merits.
> 
> It would be great if a project could be able to renew itself on it's
> own, and not, as it seems now, be forced to rebrand, refocus, restaff,
> relocate just to get on with some new thoughts on the same base concept,
> as it is with Excalibur etc.. To me, it seems that this is a waste of
> effort and above all distracting for users that will have to keep track
> of which new project the driving people are heading off to right now
> because the current project is blocking their thoughts, not on technical
> grounds (which could lead to forking) but on political reasons.

<board-hat mode="off">

Peter,

the board sent back the resolution *exactly* because it doesn't want to 
make decisions for you, it either says "yes we like it" or "no we don't".

for excalibur was "if you want this, take it". I personally thought it 
was a bad idea, but as a director I voted yes because that's what they 
wanted and I would be pretty bad for me to abuse my director hat to 
enforce my personal views on something.

for metro, the board was concerned in stephen's style and community 
vision that has created more problems than it solved.

Stephen has his own view about community dynamics. This is just great 
and I personally respect that. But I have seen that this style doesn't 
really match well with the rest of the communities that follow a 
different style.

Is that bad "per se"? no, but I am concerned about this because it's 
drawing energy away from the board and for little/no overall benefit 
(since all the projects now dislike avalon's attitude and try to move 
away from it).

Forking? I personally would love if the metro "community" as defined by 
Stephen went somewhere else to show that they can do that: use this 
style of community building to work.

JBoss is an example of a community where this style of friction-based 
consensus was incouradged because they thought it fostered innovation. 
[little sidenote: ask the Geronimo people how they liked that]

The ASF has one style of doing communities and we created the incubator 
to filter communities based on that style.

The board will *NOT* allow other styles to get to top level without 
being put in a sandbox first because we don't trust this style of 
community building. Period.

It's a conservative approach, true, and might even be wrong and Stephen 
might be the biggest innovator in community-building procedures for what 
I know, but he lost trust here and will take a long time to build it back.

Would Metro decide to go somewhere else, I would be a strong supporter 
of that, including making the ASF release the code under public domain 
so that you can do whatever you want with it, including relicensing.

But you want to stay inside, you play by the rules.

And if you don't like the rules, you get on community@ and you start 
advocating for changes.

You will find a lot of inertia but this is because the ASF created a lot 
of value with these rules and the biggest the organization the harder it 
is to change it (believe me, I know what I say here).

But I'm  personally very open to changes, just you need to show that the 
ASF as a whole can benefit from them, and so far this "community" 
behaved in such a sellfish way that alienated everybody around it (and 
even some inside of it).
</board-hat mode="off">

<board-hat mode="on">

Now, the equation I have in my hands is:

   o) friendly consensus -> slow pace -> poor PR -> self-managing 
projects ->  long-term stability -> ASF scales

   o) friction-based decision making -> fast growth -> great PR -> 
one-man-shows -> long-term instability -> ASF does not scale

and I am asked to decide to promote this "other style" to top level.

The answer is no.

I don't buy it.

It's dangerous.

I see it as a disease that might spread like fire in other projects 
because it does have a short-term benefit that might be attractive to 
some (like all the users around here that benefit from free-riding) but 
have very big side effects down the road (like when they realize that 
this train has ransomed them and they can't get off).

So, my goal is to contain it or expell it entirely.

not the code, not the community, but the community-building style.

</board-hat mode="on">

-- 
Stefano.


Mime
View raw message