BDFL decision of Python's DVCS

[Matthew D. Fuller]

On Tue, Mar 31, 2009 at 07:47:34PM +0900 I heard the voice of
Stephen J. Turnbull, and lo! it spake thus:
> Russel Winder writes:
>  > FInally (!):  there is another issue here that again is one of
>  > social psychology and perception, not of fact:  people perceive
>  > Git and Mercurial to be FOSS projects, whilst Bazaar is a
>  > Canonical product.
> 
> That's true, there is that perception, and I guess it matters to
> many people.

I think it's fair to say I've been paying a little attention to bzr
for a little while now.  And *I* have that perception.  I can't help
but think that that (both the [perceived] reality, and the perception
itself) contributes to a general manpower shortage on bzr work,
relative to flavors Y and Z.

Let's see what committer-stats has to say about bzr.dev.  info -v says
there are 23k and change revs in the repository.  How do they divide
up?

    3780 Aaron Bentley

Employed by Canonical.

    3736 Martin Pool

Employed by Canonical.

    3520 John Arbash Meinel

Employed by Canonical.

    2926 Robert Collins

Employed by Canonical.

    2794 Canonical.com Patch Queue Manager

Employed by Canonical (and making scandalously low wages, I wager ;).

    1624 Andrew Bennetts

Employed by Canonical.

     941 Vincent Ladeuil

Ah, finally somebody not so employed.  Responsible for slightly under
a quarter the revs of the #1 contributor by volume, and somewhat over
half that of the 5th place Canonical employee.

     829 Ian Clatworthy

Employed by Canonical.


Now we get a lot more non-employees, among people with 400 revs and
down to their credit.  Look at it; ignoring PQM, 6 of top 7
contributors are Canonical employees, and they're responsible for
16415 revs.  That's 70% of the total, 80% if we ignore PQM.

I'm well aware that many of those revs from many of those people date
from times when they WEREN'T Canonical employees.  But still;
perception trumps reality, even when the numbers DON'T tend to support
that perception.


Pretending I hadn't run those numbers, if you asked me anecdotally who
the biggest ongoing contributors to bzr's core code were, I'd have to
say "a bunch of Canonical employees, and vila and bialix."[0]  And
further, the people who generally wander all over the code base,
working in all the corners rather than just in a few places that they
directly care about, it falls down to "a bunch of Canonical
employees".[0]


I don't think that Canonical is necessarily intending it that way.
And I've never noticed any significant amount of us-v-them attitude
toward outside contributors.  But I do think that various factors (the
self-reinforcing perception probably being one of them) contribute to
keep the scales rather tilted.



> its disadvantages have been large (5:1 "$VCS clone" ratio, 10:1 or
> worse "$VCS log"), and some claims (superior log output and merging
> and better UI) are subjective at best and many consider them
> overblown.

I would say rather that its disadvantages are MUCH easier to
demonstrate than its advantages.  You can't really evaluate the easy
of use or utility of a tool or workflow without using it for a while,
and making necessarily subjective judgements based on that.  But
anybody can run a benchmarking shell script and compare two numbers to
see which is larger.  I'm not claiming performance is unimportant
(quite the contrary), but performance is *VERY* easy to demonstrate
incontrovertibly.  Usability isn't.

bzr is thus in the quite uneviably position of having its
disadvantages easily demonstrated, and its advantages difficult to
convey.  It doesn't make them imaginary, but in the PR sweeps it's the
next best thing.






[0] This is seriously *NOT* intended to denigrate ANYBODY.  Absolutely
    vital and truly wonderful stuff can and does come from people
    responsible for only a few dozen revs out of a couple dozen
    thousand.  Quantity isn't a substitute for quality; but it's still
    quantity.

    Nor am I claiming that perception as absolute truth, or even the
    best expression of my own conception of the community.  But I
    think it's the obvious surface.

    This also purposefully ignores very important contributions to the
    bzr world like writing plugins or documentation or problem reports
    or doing support.  I'm talking about just the people who write the
    code that gets committed to bzr.dev.  It's unfortunate perhaps
    that that metric gets more weight for figuring "the people
    involved with X" than it really merits relative to non-core-code
    contributions, but perception looks there.




-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.