What's Canonical thinking about Bazaar?

[Stephen J. Turnbull]

Sorry, this is too long and somewhat rushed, but I'm going to be
travelling for three days, then catching up at work after that.

Martin Pool writes:
 > 2009/11/4 Stephen J. Turnbull <stephen at xemacs.org>:
 > 
 > > > Fortunately, we don't need to *know* exactly what it means in
 > > > order to promote a perception of it.

Ben Finney wrote that.

 > > Nevertheless, "what's in it for Canonical?" is a crucial question
 > > here.
 > 
 > Canonical wants to (in some kind of order of generality) get more
 > people onto free operating systems, to make tools to build and ship
 > those systems more efficiently, to build healthy communities around
 > those tools and to get recognition for the work we put into free
 > software.

Oh, so Canonical is a *charity*, or maybe a *government*.  I bet
that's not what it says in the papers of incorporation though.  C'mon,
Martin, like "community ownership", all of the above sound nice,
though vaguely socialist.

The question is, what are Canonical's immediate goals for Bazaar
development that might divert developer resources away from working on
"what the community wants"?

 > > Community-owned means
 > 
 > > 1.  Community members "feel ownership" of the project so that they
 > >    identify with it: they're proud of using the code, they're proud
 > >    of their contributions, they want to meet the core people, they
 > >    advocate the product fervently to acquaintances.
 > 
 > I would put this first too, it's highly important, both as something
 > Canonical would want and also just the kind of project I like to work
 > on.  Perhaps it deserves a thread of its own; at any rate you could
 > hypothesize many things to get there.  Probably high among them is the
 > project being technically exciting and having an open and respectful
 > forum.

False, IMO.  Those are attractive to adopters (early and later,
respectively) but have little to do with "ownership."

 > I note that people feel this about all kinds of projects and
 > products, even non-software or entirely proprietary products.

True.

 > I'm hoping that we can give Ubuntu a bit more attention

"A bit?"  Are you kidding?  Cf the "what is SCM" thread, I think this
is nothing less than Mark trying to revolutionize the distro business.
If so, it's a "you bet your company" effort, I'm guessing.  That
doesn't mean you'll drop everything else to work on this.  It does
mean it's going to be high priority, and demand slabs of developer
time as Ubuntu and Launchpad see ways that Bazaar could streamline
things for them and post RFEs.

It would be a very good idea to make sure their RFEs and bugs are
posted on Launchpad, same as everybody else.

 > while still also helping other users: in strict numeric terms it
 > may be less hours, but at this level I don't think a strict
 > calculation of hours is really the point.

True.  If the effort that's "perpendicular" to community service is
exciting, it will help compensate for mere hours.  As will the open
and respectful forum -- but to expand on something I said earlier,
here "open and respectful" means competent people are available to
help users on a regular basis, and Canonical has to take
responsibility for that or risk serious loss of face if people's
questions are basically getting ignored for a month.  The resources
can be non-Canonical volunteers as long as they are effective, and
Canonical is there as a backup if they go AWOL.

 > > 2.  No commercial entity controls the copyright of the whole product.
 > >    Thus, there will be no proprietary forks of the whole code base to
 > >    the detriment of the community.
 > 
 > Confidence that the project will remain open, and not have its energy
 > dissipated by a proprietary fork is crucial.
 > 
 > We (Canonical) won't take Bazaar proprietary.  Making it a GNU project
 > is part of giving confidence in that.  If there are more things we
 > could do, we should talk about it - we are looking at making the
 > language in the copyright agreement more clear in this regard.

Have you actually assigned Bazaar to the FSF, including future
contributions made on Canonical time?  If so, that's plenty IMO.  The
"leeway" in the standard assignment language doesn't give you anything
you can pass on to a successor that I know of.

 > I think the "thus" of the second sentence is a bit of a non-sequitur
 > though, and the first sentence is only weakly correlated.
 > To me the question is more: the community has trust that the
 > project will remain open.

Let's agree to disagree on the details since you're aware of and
working to address the issue.

 > Canonical released Launchpad's source, completely and ahead of
 > schedule.  I feel that shows some kind of good faith.

True.  Interestingly enough, though, some free software movement
people tend to be very much "what have you done for me today?" about
this.  They don't understand the concept of capital, AFAICT.

 > > 3.  No commercial entity controls whether any given patch will be
 > >    applied.
 > 
 > I don't think "commercial" matters,

To be blunt, it doesn't matter what you think.  What matters is that
there are various segments of the community where it does matter.
There are reasons not to trust commercial enterprises.  They can sell
the company or go bankrupt or sell the division.  Also, there is a
bias in technology for actually landing changes that favors employees
(eg, in any sane company they will be paid for time spent on tests,
whereas the volunteer is much less likely to enjoy testing to the
degree they enjoy hacking).  See the next point for anecdotal evidence
that bias exists, and the discussion of testing, below.

 > The question is whether the patch review process is seen to be fair
 > and not capricious.

Matt Fuller doesn't think it's fair in the sense of "unbiased" (my
reading is that he thinks it fair in the sense of "good intentions").
He specifically said you need a Canonical employee as champion to get
a patch through the process.  (Obviously just his opinion, some people
have managed without, blah blah blah.)

 > I can't think of cases where we've rejected patches for commercial
 > reasons, though we have sometimes prioritized patches for
 > commercial reasons,

Rejecting for commercial advantage is just stupid (you'll get forked),
but priorities are a problem.  Especially if there are not enough
contributors with the skills to noodle a patch[1] through the process
available to mentor newbies on their early contributions.

 > But then I've done personal projects in the past where I did an even
 > larger percentage of the development than Canonical funds on Bazaar,
 > and could have dropped them at my whim.  I don't think it was
 > unreasonable for people to use those products.

We're not talking about "use" here.  We're talking about the feeling
of ownership.  This is important because "owners" contribute
disproportionately compared to "just users":

 > > 5.  Community members feel a responsibility to "pay back" to the
 > >    developers, and "pay forward" to the project's future.
[6. and 7. omitted, more precise description of the same.

 > They do all of these.  More is always better.  Identifying things
 > that might block or discourage them will help.

Well, my opinion, and Ben's seems to be similar but somewhat stronger,
is that lack of "ownership" is a big issue.  More ownership would get
you more contribution.  (But no, ownership is not why I haven't worked
on the git-to-bzr survivors guide yet; I'm just a lazy sloth who
enjoys blowing hot air and strategic management theory more than
trying to imagine the problems of git users moving to bzr.)

 > > 9.  Community members see a reasonably clearcut path (that doesn't
 > >    involve an employment contract) to influence over the future of the
 > >    project ("commit bits", a voice in reviewing code, choice of
 > >    domain names!, etc.), even if at present they have little or no
 > >    interest in actually walking that path.
 > 
 > I think that's true.  We have non-Canonical reviewers and committers,
 > and we do listen to them in threads like this.

But how do they get there?  And who are they?  The anwers to such
questions are both unclear to me, and I've been following this list
for a couple of years now.  I'm often surprised when somebody I
thought was a third party turns out to be a Canonical employee or
contractor.

Do you help fund those folks attendance at bzr sprints and PyCon?  Not
necessary, but it might be a fairly cheap way to improve image.  How
about providing Google SoC mentors?

 > It would be interesting if there were more non-Canonical than
 > Canonical developers.  I would welcome it, though it would probably
 > cause some growing pains.  It's not immediately in prospect though,

No, and it's probably going to get worse since I gather you're looking
to increase the number of contractors.  So don't worry about it.

 > If the communication about these things is bad, let's fix it.

I don't think the communication is bad, particularly.  You've been
very open about what you're thinking, as have all the developers
(mostly Ian, this time around, but I have a long history with Aaron,
Robert, and John, at least, and trust them).

The main problem I have with your end of the conversation is that you
guys don't seem to "get" the radical free software movement attitude.
You don't have to adopt it or sympathize with it, but misunderstanding
hardcore GNU people or Debian people will cost you some resources.

 > Perhaps we should make some stronger/clearer commitment that Bazaar
 > will remain an open project

The GPL should be good enough for that.  The problem is that sudden
resource starvation can kill even a good and very open project:

 > and that it will be resourced at least for the forseeable future.

I'm not sure how you can do that.

 > It's pretty speculative that Canonical might drop patches for
 > nefarious purposes,

This is not a problem.  If it *really* happens, there will be a fork.

 > but it's sadly a historical fact that some people give up on their
 > patches after being asked to write tests, and that these patches
 > languish in the bug tracker or the mail archive.

This is important.  At least in my experience, GNU/Debian types are
behind the curve when it comes to test-driven development.  They're
generally willing to put in effort, but writing tests when you're not
used to the testing framework can easily turn a 5 line patch into a
2-day nightmare.  A couple of riffs on that theme:

1.  You know, JAM has been really visible on this list making sure
    that no technical-type posts fall through the cracks (and it may
    be just as important that he stays *out* of threads like this one,
    for the most part).  That's really good, and ISTR at least one
    other 3rd-party post mentioning it, as well as somebody (maybe JAM
    himself?) from the core.  It would help a lot, I think, if
    somebody could function as testing mentor, and somebody as patch
    noodler.  To the extent that you can *commit* such resources,
    advertise the fact.  If you can't, well, I guess the best you can
    do is "we try to mentor" kind of phrasing (but it has to be backed
    up with visible progress, on a general public channel such as this
    list -- if you can't do that, it doesn't help to increase trust or
    ownership).

2.  In the list of priorities, add "streamlining bureacracy" (phrase
    that however you like) and put in the recent efforts at making
    testing easier.  Maritza has been pretty obviously pleased in the
    last day or so, so you could take advantage of that.

3.  Not directly related but one thing I like on the Python Dev list
    is the weekly report from the tracker.  I suppose you can get
    something similar from Launchpad, but I just wouldn't bother going
    to Launchpad for this, while it's a nice extra when frequent but
    not too frequent.

 > There are some other problems like the relative ease of employees
 > phoning each other or seeing each other in person, and that this
 > might bypass the list.  But we try to balance this.

This doesn't bother me personally, in general.  In particular,
Canonical people have been good about being on IRC and moving
discussion to the list when particular tasks start to bear fruit and
landing them is starting to come up on the horizon.

Footnotes: 
[1]  The image is spaghetti trying to slip through a fork.