Re: CentOS Project Infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Monday 10 August 2009 21:12:11 James B. Byrne wrote:
> On Sun, 9 Aug 2009 03:23:57 +0100  Marko Vojinovic <vvmarko@xxxxxxxxx>
> wrote:
> > Unfortunately, governments are typically not made of experts, but of
> > opportunists. Name one president of <insert your favorite political
> > entity here> that has been elected because he has a PhD in political
> > sciences/history/law/whatever, or because he had enough hands-on
> > experience in governing the state (maybe without a formal degree).
>
> Woodrow Wilson.  Ph.D. in Political Science (John Hopkins),
> President of Princeton University, Governor of the State New Jersey,
> President of the United States of America.

Born December 28, 1856, died February 3, 1924. I could also name someone from 
middle ages or ancient Greece, for that matter. But today is 2009. :-)

However, you are right, I agree that I went over the line with this, and since 
it is OT, let me be the one to drop my own argument. ;-)

> Your pride in what you know is blinding you to the value of
> knowledge of others in areas where you know little and presume much.

This is not about pride, just signal-to-noise ratio, as I stated. Also, 
regarding presumption, in areas where I have no serious knowledge (building a 
CentOS distribution from scratch being the one that matters here), the only 
thing I can do is build *trust* to the people who *do* have appropriate 
knowledge, and let them guide and make decisions about the project.

I understand your argument that project consumers (ie. the community) are in a 
bad situation when their trust gets shaken, but in the CentOS case I see no 
alternative but to continue to trust the core developers. They have several 
years of demonstration of rock solid performance behind them, and that 
accounts for something. The proposed alternative is to change the inner 
structure of the project, expose more the development process and change the 
decision-making authority (the "board" proposal). This proposed alternative 
comes from people who have little to no credibility and trust established (in 
my eyes at least, and it seems in core dev's eyes as well). Therefore I would 
never support such an alternative over the "old way".

The way I see it, the multiple-years-rock-solid-distro showed an inner problem 
in public, and a couple of loudmouths (no insulting intended) took the 
opportunity to "offer suggestions" and criticize. Of course, holding as well no 
credibility with the core devs and the rest of the community, I myself also 
fall into this "loudmouth" category, the only difference being that I offer a 
counter-argument to previous ones. This is based on my point of view, and 
offers a balance of arguments to an outside reader of this thread.

I also agree that everyone's motives are for the greater good, it's just that 
the approach is different. And every reader who cares for the subject will make 
up his mind based on the opinions presented.

No pride and no presumptions here, except when I simply need to assume 
*something* (ie. trust someone) in order to have an opinion at all.

> I have had much experience with volunteer organisations.  I now stay
> well clear of any involvement with them.  This recent string of
> interrogations by concerned people, whether ignorant or not, and the
> aggrieved tone of the responses of some of the inner circle
> demonstrate the type of emotional blackmail which I frequently
> encounter and find so distressful in these bodies.
[snip]

The whole thread put shortly (the way I see it) goes like this:

* A community member shouts "Because of recent dev-internal events, I don't 
trust the developers any more, I want the project changed so that I can regain 
my trust!"

* The developers answer "The changes you propose are unacceptable from our 
pov, so you have a choice to continue trusting us, or go find another distro."

* The member than says "No, I want in on development and decision-making in 
order to rebuild my trust, regardless of the fact that I have no appropriate 
technical skills."

* The developers answer "This is a ridiculous proposal, you are a fool to 
think we will ever accept that. Our product is there, use it or don't."

During the discussion, things may get emotional and tense to the point of 
aggrieved tone and name-calling on either side, but essentially --- who is 
trying to make a blackmail here?

As a casual thread-reader/ordinary-member-of-the-community, one can choose to 
ignore the discussion or to pick a side. When picking sides, the developers 
have some credibility in my eyes because of past performance. The other side 
has little to no credibility from my pov (being "just another community 
member", afaik), and their behavior is as emotional as that of the developers.

With pro's and con's evaluated, I say the developer's pov wins here. That is 
all I am saying. Others may have different opinion, of course.

> Having inoculated doubt it is now incumbent upon those who sowed it
> to address specific concerns raised by those who fear.

I disagree here. The developers have been doing all the heavy lifting here 
from day one, and have demonstrated superb performance. They have no 
obligation to address raising fears from members of the community. Past 
performance is the only objective indication of future performance (however 
"only potential" this may be), and if this is not enough assurance for the 
members, they should indeed go elsewhere. But the fearful members instead 
choose to press the developers into changing the project structure, only to 
address their fears. This is irrational and undeserved, especially when one 
looks at the details of the proposed changes.

> Telling
> people who voice concerns to get lost and find another distribution,
> even if their concerns are presented in the form of ill-considered
> suggestions, smacks of arrogance to me, however it appears to
> others.  Further, it does absolutely nothing to address the fears
> that prompted the suggestion.

True, this behavior is arrogant, but completely called for, since the fearful 
members had the same arrogant attitude to begin with. Maybe not in profane 
words, but the general attitude that they are Members of The Community, and 
they *demand* the the developers to obey their requests. This is extremely 
arrogant, even when phrased politely. From a developer's point of view, being 
a Great Member of The Community doesn't mean squat. People who do the work get 
to make decisions, others can use or not use the end-product. They don't ever 
get to demand anything. If they do, the developers have every right to be 
arrogant as well.

> The fact that one is a volunteer leader does not lessen the
> requirement that to receive the trust and support of others one must
> meet satisfactorily the expectations of those who follow.

Is several years of rock-solid distro not satisfactory enough? The developer, 
being the one who does all the work, is not required to do anything more than 
that, as far as I can see. If he is willing to do more, great. If not, let him 
be, he is doing more than anybody in the user community anyway.

> Nonetheless, it is very evident from the heated exchanges on this
> mailing list that there exists a substantial divergence on which
> path to take from here.  It seems to me insupportable that the past
> practices of a small coterie of initiates deciding on everything
> without community input will suffice for the future.

Community can provide no useful decisions if the members are not knowledgeable 
enough to do so. A child cannot educate the parent. A patient cannot educate 
the doctor. (I seem to be reiterating my previous post... :-) )

> If that does
> become the choice taken then I foresee the community splitting in
> the future in consequence.

The way I see it, the developers have no problem with community splitting 
(they even say "use it or don't" quite openly). As a community member, I have 
no problem with that either, those who are not satisfied here are free to go 
elsewhere.

If somebody chooses to fork, he'd better be equipped with knowledge and 
resources to do all the heavy lifting, if he is to succeed. And I wish him 
luck. But the problem is that "fearful users" do not wish to to fork a 
project, they wish to redesign the current one, without any merit other than 
satisfying their own fears about the project's future. And this redesigning 
puts extra work on developer's shoulders. More pain, no gain for the 
developers. If I were a dev, I would never accept that.

> Finally, please drop the word "meritocracy" in future
> communications. It implies a natural worthiness of those to whom it
> is applied which is simply not appropriate to these discussions.
> The proper word in this circumstance is "oligarchy."

Well, the difference between the two terms is ultimately in the eye of the 
beholder, ie. the way one defines "merit". So you are free to take your pick.

But for completeness sake, let me just quote some pieces from wikipedia, and 
let the readers decide for themselves :-) :

"Meritocracy is a system of a government or other organization wherein 
appointments are made and responsibilities assigned based on demonstrated 
talent and ability (merit)[1], rather than by wealth (plutocracy), family 
connections (nepotism), class (oligarchy), friendship (cronyism), seniority 
(gerontocracy), popularity (democracy) or other historical determinants of 
social position and political power."

"Technocracy is a form of meritocracy, whereby appointments for positions are 
made based on demonstrated technical expertise."

"Open Source
------------------
There is a general tendency among open source projects toward meritocracy; the 
more able a programmer or developer seems, the higher their position (albeit 
informal) will be. The Apache Software Foundation is an example of an (open 
source) organization which officially claims to be a meritocracy."

Best, :-)
Marko


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux