What's Canonical thinking about Bazaar?

[Stephen J. Turnbull]

Ben Finney writes:
 > Ian Clatworthy <ian.clatworthy at canonical.com> writes:

 > > I really, *really* struggle with this FUD.
 > 
 > I hate it too (though, as I say, I am wary that it not become less FUD
 > and more truth).

Ben, don't pull punches here.  "FUD" as applied to Microsoft PR is
scary statements that sound plausible because the audience is
*ignorant* and thus uncertain.  Here the uncertainty is *real*, and
your "hypothetical quotations" are *not* FUD in that sense.

The fact of the matter is that Canonical has announced that it wants
to get more for its money in the future.

This implies that Bazaar developers don't know what Canonical wants
and haven't been addressing it in the past.  Given some of the other
statements made so far, I suspect that Canonical doesn't know
either.<0.5 wink>  But what's important is that several core Bazaar
developers can't be expected to be able to accurately predict what
their employer will demand of them, thus creating real uncertainty.
There will be changes in direction, and users don't yet have a handle
on what they will be because *nobody* knows yet.

Worse, it seems likely that policy will thrash for a while.  The about
face on focusing on UI improvements *may* indicate that thrashing has
already started.  AfC's post demonstrates that this is of *real*
concern to at least some users, and it was part of the agenda that
Mark Shuttleworth laid out in a post to this list about a year ago.

 > > If you need to debate Bazaar's "independence" (whatever that
 > > means) with others, stick to our track record. [...]

Sorry to say, Ian, this is B.S.  Your track record doesn't impress
your employer, and it is pulling the power to set the agenda upstairs
precisely because it wants to change that track record.  If you're
serious about pointing to the past, then you are taking this
announcement far too lightly.

 > By the time *I*, or others like me, get to debate with such people,
 > the impression is already made. It would be foolish to think that
 > mere facts presented later can do much against the emotional impact
 > of a deliberate branding effort's first impression.

+1

To gloss that, especially since a deliberate effort is being made to
change the direction of future progress, so that the actual facts that
matter most won't be available for a year or so.  This is not Ben
Finney's problem, this is a problem that (*if* it needs attention)
must be addressed by the Canonical employees who work on Bazaar and
Canonical itself.

Does anything need to be done about it?  First, the announcement could
be a no-op, a solution to some internal Canonical problem: taking
marketing advantage of a heavily Canonical-sponsored project's good
image, or fending off complaints from Launchpad or Ubuntu devs that
Bazaar is getting too many resources for its contribution.  "Move
along, nothing to see here" (ie, Ian's advice to users) would be
appropriate, and would verify itself in a couple of months.

Second, Canonical may effectively change the direction of Bazaar
development in such a way that the community gets equivalent benefits
to what it expects now.  I think this is highly unlikely, but if so, 
again, nothing to worry about.  It'll blow over.

What I think is most likely is that some things that at least some
existing users really want are going to have to take a back seat in
*some* cases to Canonical-imposed tasks that are specialized to "large
GNU/Linux distros" and not relevant to most users.  Cf. AfC's post for
one that you've already announced.  It's really a bad idea to argue
that canceling the "Year of the UI" doesn't matter.  Bzr Explorer is
not a panacea, and many users (eg, me, and I don't think it has ever
been mentioned on emacs-devel) won't touch it.

In this third case, I think you really want to step forward and say
"our resources for 'this kind of thing' have been cut dramatically,
and we're sorry but we have to postpone this task indefinitely."  You
want to be very visibly allocating a fixed minimum of resources to
"community relations".  They don't need to be Canonical resources, for
example, if you can find a volunteer respected by both Canonical and
the community, and they needn't be large as long as they are visible.
But Canonical/Bazaar needs to take responsibility for assuring those
resources (eg, if the volunteer quits w/o finding a replacement).

You need to get the actual agenda on the table as quickly and clearly
as possible.  Up to now, the reputation of the developers for being
responsive to user needs has been sufficient, but the developers
(those employed by Canonical) may not be *allowed* to be responsive in
the future.  This means that now the community is much more interested
in seeing what the devs have been *assigned* to work on in order to
judge how that aligns with their needs.  (See my assessment of PEP 374
below.)  This is most important.

Finally, there certainly are GNUbies who will be upset by the whole
idea.  I'm sure Tom Lord will feel a certain amount of self-righteous
indignation (satisfaction?) when he hears about this, for example.  I
don't know what, if anything, needs to be done about them (see below
for my take on Python's PEP 374, which suggests maybe they can be
ignored).  I suggest you delegate the community representative to
monitor the emacs-devel list.  If those Free Software Fanatics don't
balk (and I suspect they won't, except for a couple of git fanboys who
will say "I told you so, can't we change to git?"), I don't see a real
problem; the litmus didn't turn color.

 > > Taking some time to focus on our most important customer is good:
 > 
 > Agreed; again, the above action doesn't follow from that.

+1

Also, note that Canonical is not your customer, it's your employer.
It's not the same thing.  You're not doing this because you've judged
it to be in the interest of the "aggregate of your customers".  You're
doing this because your employer has decided it is in its interest.

 > > * Git got better by being a good tool for kernel developers.
 > > * Mercurial got better by being a good tool for developers working on
 > >   Sun projects.
 > 
 > Both Git and Linux are user-run organisations,
 > Mercurial is *not* branded as "Sun's Mercurial".

+1

Again, Ian, you're not helping your cause by using inaccurate analogies.

 > This makes it very easy for large projects (e.g. Python) to choose
 > them, *because* Mercurial is perceived as quite independent from
 > single controlling interests.

As one of the PEP 374 junior proponents, I can say that wrt Python
this is FUD.  The PEP recommended (weakly), and the BDFL chose,
Mercurial because it was found to be a product that is mature on all
the important development platforms, and had a much better image on
the UI front than git.  Bazaar would surely be in the running if the
choice were to be made now.

 > Surely we've long been in agreement that Bazaar has an image problem,

Yes.  In the case of the Python VCS PEP, however, the main image
problem was performance, and naive tests as well as the experience of
Emacs (which is still using CVS 20 months after RMS pronounced for
Bazaar!) did nothing to dispel that image.  Bazaar's association with
Canonical was mentioned, and the fact that Bazaar's advocate is a
Canonical employee had to be dealt with.  But it was not a major
factor; Python is well-used to commercial entities having effective
control over open source projects, and knows how to deal with that.

 > and that people are choosing other VCSen in droves largely because of
 > the poor perception Bazaar has?

No, I don't agree.  This is highly informed by my PEP 374 experience,
of course, and so my view of other projects' choices may be biased by
that.  Still I think there are some general lessons to be learned.

Bazaar is *still* incomplete by DVCS state of the art, and would have
real problems to overcome if the Python PEP were to be written today.
For example, Robert's loom and Aaron's pipe plugins are not enabled by
default, and it would seem not distributed with Bazaar (at least, I
can't find them with "bzr plugins" or in 2.6/lib/site-packages, and I
thought there was a bzr-loom MacPort but I can't find it now, nor does
Gentoo seem to have a bzr-loom ebuild).  But support for such
in-process lines of development was considered essential by many
Python developers, and in fact looms were one of the Bazaar advocate's
main selling points.

This problem is not impossible to overcome (but I'm not willing to
predict the outcome if PEP 374 were redone today! git would be a
formidable competitor now).  However, the performance and format churn
problems were (having to upgrade the sample repository during the PEP
period definitely hurt Bazaar).  And as I wrote, the "corporate
product" image "problem" was too far off the radar to really matter.

To sum up, my belief is that the Python developers would take this
announcement in stride.  Were PEP 374 redone today, it would hurt
Bazaar adoption only to the extent that Python-Dev perceived
requirements for improvements in Bazaar that would be postponed
indefinitely in favor of Canonical-internal tasks.  It's quite
possible that Ian's conjecture is correct: the things that Python-Dev
would demand are quite congruent to those that Canonical is going to
be interested in.  But until Canonical's agenda is posted, there would
be uncertainty, and that uncertainty *would* harm Bazaar advocacy to
some extent.

 > The perception that Bazaar is unduly tied to a single corporation
 > is *part of that image problem*. I want it to lose that problem,
 > not have it further entrenched.

This may hurt for true-GNU projects.  I doubt it matters in the open
source world.  Cf. Ghostscript, Lucid Emacs, sendmail, Berkeley db,
Eclipse, MySQL, Qt, and Mozilla, all of which got huge adoption during
their corporately-controlled periods.  Can you mention some projects
that deserved to win that were really hindered by a "corporate image"
problem (as opposed to being really twisted by a single corporation's
strategic needs a la Java)?