In the wake of the Banshee/Canonical kerfuffle, many community members and watchers have been quick to point the finger of blame at Canonical for being too quick to grab the revenue believed to belong to Banshee or its upstream developers, GNOME.
My friend Joe Brockmeier summed the situation up nicely when he broke the story last month:
"...Banshee is a media/music player for Linux that has support for purchasing music via Amazon MP3. The revenues have always gone directly to the GNOME Foundation. Historically, the default music player in Ubuntu has been Rhythmbox, but that's changing in 11.04 to Banshee. The problem, at least as Canonical seems to see it? Amazon MP3 support in Banshee competes with Ubuntu's own offering, Ubuntu One--which also has support for purchasing music. The alternative? Canonical offered to leave the Amazon Store on by default, but take a 75% cut by changing the affiliate code and then passing a paltry 25% on to GNOME. The good news is that Canonical conferred with the Banshee team and gave them the option, so they elected to disable the store by default," Brockmeier wrote.
As the dust settled, we saw some mea culpas from Canonical, admitting that they could have handled this particular situation better. But we also saw a resurgence of the animosity between Canonical and the GNOME community, as each side tried to position the Banshee incident as another in a long line of such incidents that demonstrates how the other party (natch) is screwing things up.
Dave Neary took note of one of the recurring Canonical themes in their responses:
"I have repeatedly read Canonical [and] Ubuntu people say 'We offered our help to GNOME, and they didn't want it.'," Neary wrote in his blog Monday.
Whereupon Neary tried to explore some examples of where this might indeed be the case, and put forth the call for more examples to challenge or support Canonical's claims that GNOME was indeed hard for Canonical to work with.
This is an assertion I have heard myself over the years, usually in way off-the-record conversations with Ubuntu developers, whether they work for Canonical or not.
Neary's blog got a response from, of all people, KDE developer Aaron Seigo, who laid out examples of his own at how GNOME developers were not just hard for Canonical to work with, but also difficult for any outside project to collaborate.
"The decision by GNOME to not adopt what Canonical calls 'appindicators' and what we (and the specification that was brought to freedesktop.org) refers to as "status notifiers" is a perfect demonstration of the problem. Sadly, it isn't the only one, but since Dave brought it up, let's examine this particular case," Seigo prefaces.
[It should be noted for disclosure's sake that Seigo disagrees with my own blog entry's conclusions from last Monday on Nokia's decision to sell the Qt commercial licensing business to Digia, either. I hope to be getting together with Seigo to discuss his concerns about that article in the very near future.]
Seigo examines the issue of appindicators/status notifiers in fairly strong detail, and while he acknowledges that GNOME certainly has a right to choose what tech does and does not get used within GNOME, this issue is part of a pattern with GNOME that seems to indicate the GNOME community does not collaborate well.
This larger issue, at least in Seigo's perception, is cause for concern to all free software developers and users, since it affects integration of software.
"If you, as a Free software user and/or contributor, care about a coherent experience in which applications, regardless of the toolkit or team behind them, not only merely work but work well together to provide a powerful and seamless experience, then you may want to be selective in which projects you support with your time, effort and usage. Supporting teams that are open and collaborative will ensure that the future of Free software is open and collaborative; supporting teams that are more intent on going it on their own will ensure a future with more fragmentation and wasteful duplication of effort. If projects lose support when they are less collaborative, that will be a strong incentive for such communities to reassess their priorities," Seigo stated.
I am not sure if, given his position as a GNOME outsider, Seigo's messages won't simply be rejected out of hand. If that happens, that would be too bad. Even if GNOME is not a poor player in the open source development community, there is definitely a perception they are, and Seigo's comments are just more fuel for this perception.
Of course, the immediate thing to figure out is whether this perception actually has merit. And, if it does have merit, is it worth raising a stink about? Yes, interoperability is very important, but at what point can interoperability give way to individuality and creativity?
GNOME, it can be argued, is doing their own thing. (You could say the same for KDE, too.) Where does their responsibility to be a good citizen in the broader open source and free software community stop and the sovereignty of their own goals begin?
That is a very difficult question to answer, for any software project. But it bears asking as the entire software sector looks more and more to open source and free software as a solution:
What is the best model for a project to be a good community citizen?