What's Canonical thinking about Bazaar?

[Martin Pool]

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.

Yes, if we can just create the impression of authentic openness we
don't need to understand it? :-)

> Yah, but Martin wants to know if there's a salary raise in it for
> him.  Just kidding about the personal interest (though in the end he
> is undoubtedly interest in the survival and eventual profitability of
> Canonical!)  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.

> Community-owned means (among other things, this list is neither
> complete nor necessarily 100% accurate in the details):

Thanks for sending it though, this is something we can get to grips with.

> 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.

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

I don't think this is necessarily harmed if some developers, either
from personal interest or because of their employment, decide to
preferentially work on features that are not what some users want.  If
they are still getting at least some attention perhaps those users
will stay.  I'm hoping that we can give Ubuntu a bit more attention
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.

> 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.

I think the "thus" of the second sentence is a bit of a non-sequitur
though, and the first sentence is only weakly correlated.  There have
been numerous examples of codebases without single corporate owners
going effectively proprietary, eg because they use a more permissive
licence, or because a natural person owned most of the copyright, or
because the non-owned parts were replaced, and you can think of
others.  To me the question is more: the community has trust that the
project will remain open.

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

> 3.  No commercial entity controls whether any given patch will be
>    applied.

I don't think "commercial" matters, unless you believe that commercial
entities are universally worse than individuals, which I don't.  (The
general question is off topic.)  The question is whether the patch
review process is seen to be fair and not capricious.  I can't think
of cases where we've rejected patches for commercial reasons, though
we have sometimes prioritized patches for commercial reasons, like for
customer support or to give  smoother Launchpad integration.  But we
have also happily taken Bugzilla and Trac integration patches.

> 4.  No commercial entity employs enough of the core developers to
>    cripple the project by withdrawing them if it loses interest in
>    supporting the project.

Sorry, that's probably true for us at the moment, or substantially
true.  I don't think there's anything we can do other than gradually
growing the non-Canonical-employee developer community.  (And
Canonical tends to hire people we meet through open source projects,
which is nice for them and nice for us but tends to make this look
worse.)

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.

> 5.  Community members feel a responsibility to "pay back" to the
>    developers, and "pay forward" to the project's future.  They want
>    to help write documents.  They blog about the product.  They
>    contribute FAQs and support other users for free on various
>    channels.  They harbor a secret ambition to contribute a whole
>    plugin someday, or maybe host a wiki.
> 6.  Community members report bugs, and follow up even if they've found
>    a workaround.
> 7.  Community members with the capability write code.  Others do
>    artwork, bug triage, host resources of various kinds, present at
>    conferences.

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

> 8.  Community members start consulting businesses based on the
>    product, and help each other out with recommendations and
>    references.

Slightly, though I think we've not yet reached the milestone of
someone starting a specifically Bazaar-based business.   People
certainly start Ubuntu-based businesses, and Ubuntu is steered by
Canonical roughly as much pound-for-pound as Bazaar is.

> 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.

> 10. Community members feel free to branch the codebase within the
>    community when it's necessary, and expect that other community
>    members will help them (as long as it's not a pure power play, but
>    rather a genuine irreconcilable technical difference that can't
>    really be combined in a single code base).

Has happened in the past, would rather reconcile the differences but
it's good to know it's there.

So,

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, so
I think the better thing is to work on what would incrementally
improve things for users and developers.

If the communication about these things is bad, let's fix it.  Perhaps
we should make some stronger/clearer commitment that Bazaar will
remain an open project and that it will be resourced at least for the
forseeable future.

Giving a clearer patch to get involved with development and making
sure there are no unnecessary snags or delays is to me both a more
pressing and a more tractable problem.  It's pretty speculative that
Canonical might drop patches for nefarious purposes, 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.

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.

-- 
Martin <http://launchpad.net/~mbp/>