What's Canonical thinking about Bazaar?

Martin Pool mbp at canonical.com
Tue Nov 3 12:52:58 GMT 2009


I want to answer this point by point, but also say a few things up front:

 * Canonical management is not giving employee developers more
direction than in the past, we're just doing it more publicly
 * Things that will help Ubuntu are largely things that will help
other users too, and at least in part aligned with the previously
discussed UI improvements
 * A direction to "please spend some time on X" doesn't exclude people
spending other parts of their work time on Y, or on us taking patches
from other people for Z.  As a manager I think it's very important and
beneficial to give developers substantial discretionary time to do
what they think best for the project, and at Canonical they get to do
this.

I'm the manager of the Bazaar team at Canonical so these directions go
through me to our engineers, and plenty of feedback goes back.

2009/11/3 Stephen J. Turnbull <stephen at xemacs.org>:
> 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.

I acknowledge there really is some fear, uncertainty and doubt here,
and it's not being intentionally maliciously propagated.  I want to
provide enough information that at least the UD will dissipate.

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

cite?

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

We have always had good communication between the Bazaar team and
other parts of Canonical about how we're going and what to do next,
and the focus of our work has taken that into account.

What we haven't done very much in the past, and what I was trying to
do in this thread, is to make those priorities more public to our
other stakeholders.  In the past, Canonical employees just ended up
working on particular things without saying why.

What looks to you like a change from zero direction to dictatorial
central direction is in fact a change from fairly moderate direction
done in private to about the same amount of direction, discussed
publicly.

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

If this is coming from me expressing doubt of whether my phrasing was
precisely correct -- it is, by the way -- then it's vastly overblown.

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

To me 'thrashing' would mean we're doing lots of work and then
discarding it and moving to something else.  We are not.  We said we'd
finish 2.0, and then probably look at ui improvements.  After doing
2.0, we changed our mind to emphasize Ubuntu use cases more, but not
to the exclusion of other things.  Unless you expect software projects
to have cast-iron multi-year plans, this is totally normal.

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

"Community relations" is what I'm trying to do in this thread, but
apparently with limited success.  I want to be up front about the
process of determining what we do next.

Depending on what particular features people care about, they may be
more, less, or equally pleased with 2.1 than 2.0.  I don't expect
anyone will be dramatically disappointed - the vast majority of our
effort will still go into building a good general purpose dvcs tool.
This may become more clear as we talk about what specifically is
wanted, but I wanted to explain why we'd be talking about that.

> You need to get the actual agenda on the table as quickly and clearly
> as possible.

I think we can definitely communicate better about this.  This thread
makes that obvious if it wasn't already.

What information would you like to see in that agenda?

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

There is no question of people not being allowed to be responsive to
user demands, in fact I said the opposite in the first post.

Prior to 2.0 I agreed with other Canonical managers that we would
focus on getting 2.0 and 2a finished, performing well, and out the
door, and I told our employee developers to concentrate their time on
that.  This wasn't what every user wanted us to do next, but it did
help many of them, and it certainly didn't mean we stopped fixing
other bugs, helping people, or adding other features.  Anyhow I still
think it was a good choice.

In any open source project, whether the developers are funded by any
means or not at all, they always choose to work on some things rather
than others, and this tends to change over time.  Can you promise me
what features will go into Python 4.0 or emacs 25?  The balance
between new features and reactive development changes over time too,
and is not always what every user wants.

I don't think people do, or should, put a lot of weight on future
roadmaps, but rather more on looking at whether what's actually
shipped aligns with what they want.

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

Tom might expect companies to put years of effort into a project
without wanting even a shade of influence over what's done next, but I
think most other people will understand. ;-)

I do think it is possible for open source projects to have, at some
times in their lives, the majority of developer time funded by a
company with particular feature wishes and for the project to still
appeal to and be open to a broader community.  Sometimes it's a
passing phase.  I think other gnu projects have gone through this in
the past.

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

I don't know if this is an intentional irony, but the mails on "what
would help Ubuntu" suggest that getting loom/pipeline type things
working really well is in fact something Ubuntu would want us to
prioritize.

Overall I'm quite concerned that Canonical is seen as the bad guy for
Bazaar here, pushing the project around.  I've been here for a while
and there's always been a commitment that Bazaar should be a good
project in its own right, and that it should respond to its community.
 I think it's actually really good that Ubuntu developers are happy
using Bazaar and that they're building interesting tools on top and I
really relish the chance to do more to help them and am happy this is
the focus.

Obviously there are going to be tough choices as to where we spend our
time, and there are going to be issues where Canonical's assessment of
the risks & benefits is different to that of other people.

I would at least like our communication to be good enough, and there
to be enough trust, that I can say "Canonical would like its employees
to do X" and it does not cause FUD.  I'm certainly very open to people
asking "what on earth is X" or "is X really useful" or "why don't you
do Y?"

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



More information about the bazaar mailing list