What's Canonical thinking about Bazaar?

[Stephen J. Turnbull]

Ian Clatworthy writes:
 > Stephen J. Turnbull wrote:
 > 
 > > This implies that Bazaar developers don't know what Canonical wants
 > > and haven't been addressing it in the past.
 > 
 > Huh? That's simply wild speculation.

That was badly phrased, but it's not so far from the way I feel about
it.  To refine it a bit, I'm serious about Canonical not really
knowing what it wants: up until recently it knew it wanted to have a
hand in the VCS market, and was happy to support Bazaar on a
"motherhood and apple pie" basis.  But now it's starting to see
specific roles for Bazaar in supporting other Canonical activities.
And it's asking for those roles to be intensively developed now.

If it matters, I can explain why I believe that in terms of Martin's
post.

So, after citing Martin and giving the list of three "motherhood and
apple pie" goals that Canonical had for Bazaar, you continued:

 > These have expanded over time. Adding one doesn't make earlier ones
 > redundant,

C'mon, nobody said any such thing.  Just that less resources will be
available for them, and that will have a chilling effect on some users
or potential users.  Should you care about those users?  Ben thinks
so.  I think so.  I'm trying to explain why.  I'll let Ben speak for
himself.

 > though newer ones receive more short-term focus.

Which is BS, in view of the overall change of positioning.  This is a
long-term change of direction.  Specifically:

 > As Martin's email announced, Canonical is now adding a forth:
 > 
 > 4. Think about the bigger picture and the role of the VCS from code
 >    import/migration to packaging. Solve that for Ubuntu developers and
 >    you're a long way there to solving it for other teams as well.

That last sentence is vaporware at the moment, and I know enough about
variations in source tree structures and end-user packaging to believe
that a generic solution is likely to arise as integration and
refinement of fairly diverse best practices.  This is likely to be be
a big consumer of Bazaar resources for quite a while, IMHO.

I really don't see an alternative to decreasing the resources
allocated to the three motherhood and apple pie goals, and community
service in general.

 > Clarifying my earlier response, the "FUD" I struggle with is that
 > Bazaar is disadvantaged by it's association with Canonical.

I agree with that on average.  OTOH, a lot of the people who post
frequently on bazaar at canonical.com probably have warm fuzzies for
Canonical because of Bazaar not the other way around.  And my read is
that they trust the Bazaar devs, *not* Canonical, to make Bazaar a
great VCS.  While (like Matthew Fuller) I'm sure they understand the
business logic for this move, it makes them sad (for want of a better
word), and perhaps less likely to contribute.

And I know a lot of people who react like Ben says people of his
acquaintance do (and most of them hang out on emacs-devel :-).  In
open source, you may want to cater to the perceptions of those people
to *some* extent (ie, appropriate to the importance of that segment of
the market).  They are disproportionately frequent contributors of
code, advocacy, and even bug reports in my experience.

 > I also believe that "lock-in" fears are largely unfounded.

I don't know what you mean by "lock-in".  To me it means that
maintenance and upgrades are available only from the original vendor,
which can't be true for open source.  Concentration of development
activity, on the other hand, is high and seems likely to increase.

 > We actively encourage contributions from anyone and everyone. We're
 > not preventing anyone from making Bazaar better and would be happy
 > for other companies or organisation to get more involved.

Of course not.  Bazaar is, after all, open source.  More, Canonical
employees have no less "process bureaucracy" to deal with than anyone
else.  Nonetheless, my take on the dynamics of it is simply that it's
really hard to keep up with a team of paid developers who interact
every day by email, and several times a year at sprints and the like.
So you end up with development concentrated in the group of employees
of a single corporate vendor.

We've seen this in many other open source projects: Berkeley db, Qt,
MySQL are well-known.  This *does* have ramifications, even if I
hesitate to call it lock-in: it's more expensive to get support from
independents, and the priorities of the "in group" are going to
heavily (even heavy-handedly) influenced by the employment
relationship.  If it comes to a disagreement about direction between
the devs and the executives, you know who's going to win.  That's
going to change the direction of development in the project overall.

And if getting contributions from non-Canonical sources is a *goal*
(vs. merely "actively encouraged"), I think the already high
concentration of development activity in the Canonical group is going
to work against achieving that goal.