BDFL decision of Python's DVCS
Matthew D. Fuller
fullermd at over-yonder.net
Wed Apr 1 06:35:45 BST 2009
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.
More information about the bazaar
mailing list