Edit: forgot to include the normal disclaimer: as usual, this is all my personal opinion and in no way representative of Red Hat (or anyone else, for that matter).

Second edit: I’ve had a few Canonical contributions pointed out to me which to some extent cover the areas I’ve identified. I’ll update the post more extensively soon, but for now, just bear in mind that Canonical is actually active in a few more areas than I identified, and that is certainly awesome.

Reading the comments on my previous post, Greg’s posts, and some of the replies to both, it seems clear that quite a few readers aren’t exactly sure what it is I (and some others in the debate) are suggesting. The top layer of the debate is fairly simple – Canonical is/is not contributing to $FOO – but I guess it might help to spend a bit more time spelling out the implications.

One thing a lot of people seem to assume is that this is some form of jealousy or sour grapes – we’re just hatin’ on Canonical because they are, in some way, beating us (where ‘us’ is Red Hat or Fedora or whatever). But really, that’s not it at all. Red Hat and Fedora don’t really compete with Canonical at all in their main wheelhouse – the end-user desktop; Fedora’s target user (and overall raison d’etre) is rather different from Ubuntu’s, and they can coexist perfectly happily. Yes, Canonical is making initial moves towards the enterprise market, but they’re pretty early. Novell is a far more significant enterprise competitor to Red Hat, yet no-one ever seems to suggest that RH staff are jealous of Novell (or vice versa), and the relations between RH and Novell are pretty fine.

So, no, I’m not just bitching because I hate Canonical and want to score points off them, or something. The point is that Canonical has established itself as a big player in the F/OSS world, and to make the F/OSS world better for everyone in it – including Canonical – it’s important that everyone contributes; not just to marketing or UX design or whatever, but to the fundamental engineering. The argument isn’t ‘Canonical doesn’t contribute to $FOO so they’re a bunch of losers, nee ner nee ner!’, it’s ‘Canonical doesn’t contribute to $FOO and it would really be better for everyone if they did’.

Look at it this way. (Again, this is my personal reading of the situation, not Official Red Hat Gospel). When Red Hat identifies something lacking in the F/OSS world that goes into the distribution that it sell services around, broadly speaking, it works to make sure it gets resolved. Usually, that boils down to ‘hire someone to write the thing’. Take virtualization. It was obvious that this was going to be a major need for the companies that actually use Red Hat products and buy Red Hat services, so RH backed Xen. When it became clear that Xen wasn’t working out so great, especially in terms of kernel integration, RH bought out Qumranet and bankroll the development of KVM. It’s important to note that the basic theme here is self-interest. There is idealism in how RH operates, definitely – there are all sorts of ways RH could perfectly legally make it much trickier for others to leverage our work, make it much harder for Unbreakable Linux or CentOS or Scientific Linux or whatever to exist – but doesn’t. But in so far as actually writing the code goes, in a way, RH would be dumb not to do it. *Not* working on a good virt layer, and sitting back and hoping someone else will write it so RH can use their work, just wouldn’t fly very well. There’s pages and pages of examples of this, but the shape of the story is simple: figure out what it is that needs to be in RHEL, then write the code, and contribute it properly.

This is what Canonical needs to do – for the benefit of the overall F/OSS world, yes, but also for the benefit of Canonical. And there *are* some ways in which they seem to get this. The cardinal example of a significant Canonical code contribution is upstart, and that’s a legitimate one to be sure. It’s a properly organized open project which is funded by Canonical but accepts contributions from others and genuinely works to be integrated into other projects, and it’s been a pretty broad success, with other distros taking it up (though Fedora is currently planning to move to systemd with F14, but that kinda thing happens, it doesn’t invalidate the value of upstart). Their usability work (including work on next-gen desktop concepts like Unity) is indeed an example of the same right way of thinking, though in some ways they’ve been doing it wrong (ignoring XDG standards in their new notification system, for instance, so that it only works with apps that Canonical custom patches in Ubuntu, and they have to ship the standard system anyway to handle apps they haven’t got around to patching yet; it doesn’t work out well from any angle). But the overall idea is right – they’ve identified usability as an area where improvement would be a significant benefit to the product they want to make a living selling services around, so they’re trying to do that work, and – even if not optimally – they are trying to share that work. So, again, that’s an area where broadly they’ve been getting it right.

That’s about all the examples I can think of, though. EDIT: David Treumann correctly points out Simple Scan as another good Canonical project. I’d love for SS to get into the GNOME suite in future. Clicking around from there, I see the SS developer is also involved in a display manager (we sure need another of those…) and something called Omsk that’s listed as proprietary. Huh. Never heard of that. Has anyone else? I looked around. Nothing on the Google. You can find this mysterious page in Launchpad: https://launchpad.net/omsk . It’s a Canonical OEM Project. Lots of people seem to be involved with it. There’s no code you can see. Judging by the couple of bugs marked as affecting it, it seems to be some sort of secret OEM customized Ubuntu variant. Curious…) So here’s some simple suggestions: these are the things it would be best for everyone, including Canonical themselves, to step up and contribute to.

1. Audio. Thanks to Lennart Poettering for pointing this out. Sound is one of the fundamental bits of just about any consumer desktop. Most desktop users aren’t going to use a computer that can’t play sound, or has problems with it. Yet Linux audio is *massively* understaffed. Lennart says there are three people in the world who are paid to work on Linux audio – there may be others Lennart and I don’t know about or are forgetting, but there sure aren’t a lot. Red Hat employs Lennart to write PulseAudio (though he does other stuff too) and Jaroslav Kysela to work on ALSA. Novell pays Takashi Iwai to work, in part, on ALSA (though this isn’t his full time job). Canonical doesn’t pay anybody to do any work on this area. It’s almost ironic – Novell and Red Hat would cope far better in a world where Linux audio was completely neglected than would Canonical. I don’t sell RHEL so I’m not the most informed, but I rather suspect that the vast majority of Red Hat’s and Novell’s significant customers couldn’t really give a toss whether their servers can play Lady Gaga or not. But Canonical’s users are far far more likely to be worried about audio functionality. So why are RH and Novell supporting this vital area of infrastructure – even if not really to the extent it needs – and Canonical isn’t doing it at all? It would help everyone, but Canonical as much as or more than anyone else, for Canonical to find two or three people who can grok kernel hacking and signal processing and pay them to work full time on ALSA and PulseAudio and desktop sound integration. Hell, I can suggest one person for starters (though I’m not sure if he’s free to take a job with Canonical) – Colin Guthrie, who’s been a contributor to PulseAudio for a while.

Edit: Colin and also Daniel Chen pointed out to me that there actually are a couple of Canonical developers working on audio, something that I managed to miss while looking stuff up for this post. 🙂 I’m looking into this more closely to rewrite the section above, but for now, please note that Canonical does indeed seem to be making some efforts in this area, which is great.

2. Graphics. Same story as audio, pretty much. Red Hat and Novell both employ major upstream X.org contributors. Intel pays people to work on the intel drivers. AMD has a few people on staff who contribute to the ATI driver work. Heck, Mandriva has/had pcpa on staff (not sure if he’s still around) and tried to make sure he had some spare time for upstream work. Canonical has one X developer on staff (Bryce Harrington), and he has no time for upstream contributions; he simply works full time on packaging X for Ubuntu and managing bug reports. Yet again, same story as audio: Canonical stands to lose the most if graphics development is neglected. Again, many of Red Hat’s and Novell’s customers could probably get by with vesa without really losing that much; Canonical’s users are the ones who need proper accelerated drivers with 3D and video playback acceleration support. So why is Canonical contributing nothing to this development? Why would they trust a vital component of their product to people who work for other companies, or volunteers, and not take a stake in X development at all? How is that good for them in the long term? There’s a ton of qualified people Canonical could hire here.

3. Networking. Starting to sound like a broken record, but yet again this is an area which is more vital to Canonical than other companies, yet Canonical contributes less. Infamously, Canonical has no-one making significant contributions to the kernel, where network drivers live; Red Hat and Novell both employ kernel developers (not sure whether Novell has network driver developers, off hand, Red Hat has at least David Miller, who’s in overall charge of the networking stack, and John Linville, who is in charge of the wireless stack). Red Hat pays Dan Williams to run, and write most of the code for, the NetworkManager project (which Ubuntu uses). Canonical…well, all I can find is one set of commits to NetworkManager back in October 2008 from a guy called Alexander Sack. Yet again, this is an area that’s arguably more important to Canonical than anyone else, at least in parts. Probably most big Red Hat and Novell customers are mostly using ethernet, which is a fairly static area and doesn’t require a lot of coding work; a new driver every now and again for a new chipset, but there’s far fewer new ethernet chipsets than wifi chipsets, and the manufacturers often provide the drivers themselves these days. The areas of networking which really need development are, yet again, consumer focussed ones: wifi and mobile broadband. This is stuff Ubuntu users really really want to work; wireless networking is one of the classic knocks against desktop Linux, mobile broadband is up and coming. Yet, again, it’s not Canonical staff doing the work here. Dan Williams has done almost all the work on implementing mobile broadband support into NetworkManager; the kernel level stuff for mobile broadband and wifi is done by a range of people from a range of companies, but no Canonical involvement. Yet again, why isn’t Canonical contributing to this area that’s so vital to its interests? Why can’t they hire three or four engineers to contribute to writing drivers for new networking hardware and help out with improving NetworkManager? Yet again, it would help them as much as or more than anyone else.

4. Desktop applications. This one’s a little different, since everyone could stand to improve a lot here. The other big vendors don’t do a huge amount of work on typical, non-infrastructure apps; the big ones like Firefox and OpenOffice.org are mostly supported by non-Linux vendors, small apps tend to be written by small companies, independent developers, or even Linux vendor staff working mostly on their own time. There are significant exceptions – Novell pays people to work on Banshee, OpenOffice, and Evolution (actually Novell probably does more than anyone else in this area), Red Hat supports the development of Totem and Rhythmbox to a degree, and has one or two others working in this area (RH has an Evolution developer on staff, I think, probably a few others I’m forgetting). But really, the story of major vendor support for Linux desktop app development is pretty crappy, and yet again, it’s Canonical that’s losing out the most. Yet again, RH and Novell’s customers can get by without this stuff; Canonical’s users really can’t. Again, you’ll notice I’m focussing on the classic big knocks against the Linux desktop here, and this is one of the biggies. All down the years, we’ve heard that big apps are missing. These days, the classics that get pulled out all the time are graphics editing and video editing, and there’s a lot of truth in that. GIMP is good but it’s missing stuff that Photoshop users rely on; our video editing story is terrible.

Perhaps the best contrast here isn’t one of the other Linux vendors, but Apple. Apple realized back at the start of the OS X era that providing desktop apps that people really want to use is a great way to sell your desktop. Apple develops and supports the development of a lot of the best OS X apps, and bundles them in with OS X – the best example being Garage Band – or sells them relatively cheap. So, why isn’t Canonical doing this? Canonical needs the Linux desktop to be an attractive choice for its business model of selling services to Linux desktop users to work; sure, it won’t make any money directly by funding the development of a kick-ass open source video editor, but it _needs there to be_ a kick-ass open source video editor for its plan to make money to actually work. This is the conceptual leap Canonical needs to make more often, in a nutshell. Red Hat doesn’t make any money directly from funding the development of bits of the Linux kernel, but it needs that development to happen for its business plan to work. Canonical needs to go out there, find the people working in scraps of spare time on promising but fundamentally incomplete or broken desktop apps, hire them, and polish those things till they gleam. Go out and find the best attempt at a Linux video editor, hire the top five developers, give them an office and let them develop the project – not in secret in Launchpad, but right out on its existing project page. In the end, as long as Ubuntu is the leading desktop Linux distro, it’s still ultimately going to be Ubuntu that sees the benefit more than anyone else, even if everyone else gets to use it too. Find the top five contributors to GIMP, hire them, go do a survey of Photoshop users and find out what it is they need in an open source photo editor, and damn well give it to them. Hire the top contributors to Audacity, Jack, Hydrogen, Rosegarden and all the other jumble of disconnected Linux audio creation apps and frameworks, stick them together in an office, and build a kickass integrated audio creation suite. Just go out and read those articles about the key desktop applications Linux is missing, and hire some people to write them. It ain’t rocket science, and ultimately, it’s self-interest as much as anything else. But it’s the right thing for Canonical and the right thing for the rest of the F/OSS world.

The President of the U.S. famously said something about lipstick and pigs. Yes, Canonical’s steps towards usability and interface work are important, but the prettiest interface in the world to a desktop operating system isn’t enough if the underlying hardware support isn’t there, or the applications that people to need to run aren’t available. It’s Canonical that needs these things to exist, more than anyone else; so why wouldn’t Canonical want to be the ones to get them done? Hoping that other companies or volunteers will write them for you is not the best plan, it really isn’t.

45 Responses

Best post about Canonical I’ve read, and I agree 100%. Canonical employees, and especially Ubuntu fanbois… er, end-users, are all talk and no action. Oh excuse me, they prefer to use the term “marketing and promotion” instead of “all talk and no action”. But when what you’re “marketing and promoting” is almost all someone else’s work, be it from Redhat, Novell, and since we’re talking about Canonical/Ubuntu, we surely have to mention Debian, then your “marketing and promoting” is nothing more than “all talk and no action”. That’s what Canonical and the Ubuntu fanbois don’t realize (probably because most of the Ubuntu users are ex-Windows users who are accustomed to other people doing all the heavy lifting for them, and the Ubuntu user just wants a free OS, doesn’t care who really does the heavy lifting, and is more than happy to sing the praises of the guy giving him a free CD of an operating system, i.e. Canonical).

I’m not a Redhat/Fedora user. I use, and really like, Debian. But I support you Redhat and Novell guys telling it like it really is, and pointing out that Emperor Canonical is wearing no clothes.

“I’m not a Redhat/Fedora user. I use, and really like, Debian. But I support you Redhat and Novell guys telling it like it really is, and pointing out that Emperor Canonical is wearing no clothes.”

Thanks, but that’s not the intention. Like I said, the point of what we’re saying is not ‘nee ner nee ner Canonical sucks’. The point of the post is exactly what the post says: this is simply a suggestion to Canonical. I’m entirely sincere in suggesting that they should do exactly the things I mention in the post, I don’t see any reason they can’t do them (well, okay, they may not be able to afford quite as many people as I suggest, but they can surely afford *some*), and if they do, that will be completely awesome for everyone and I will be among the first to give them kudos for it.

What Canonical isn’t promoting isn’t entirely other people’s work, that’s not a fair way to put it. Integration is hard work, I know this as much as anyone having worked at Mandriva, and so is user support and polish. These are good things that Canonical does. By pointing out some things that I think it’s essential for Canonical to do I don’t mean to imply that ‘because they’re not doing these things they are not doing anything’, I simply mean that these are things it would be a good idea for them to do *in addition* to what they do already.

Well said! I look forward to read Canonical’s feedback and even more to any financial and resource commitments on their part. It’s time they put their money where their mouth is. Thanks for a great read.

High end video, audio or image manipulation software would be nice but I don’t see Ubuntu in this market yet.
But they are doing somewhat more basic work like making scanning functionality available in a simple way. This is valuable to me because I do not care to much about the insanely many ways xsane is offering me to fine tune and enables e.g. my mum to use the scanning functionality at all without being put off of thousands of different settings that normally would just “scare” her away.http://lwn.net/Articles/377063/
I know that there is gscan2pdf but a really easy and simple way to do a basic task and having one solution for documents and photos/pictures is nice to have.

Good point, I had forgotten Simple Scan, that is indeed a good one. I think Fedora got it in F13 or is getting it in F14, so again, it’s getting out from the Ubuntuverse too, which is a good thing.

However, I don’t agree with the idea that Ubuntu ‘isn’t in [the market]’ for video, audio and image manipulation. These are the things that real desktop users do – some of the few things for which you actually *need* a proper high-powered computer any more, in fact. Increasingly so, too, now that many cellphones and consumer digital cameras take high quality pictures and video.

For several semesters, I have purchased Ubuntu CDs and have distributed them to faculty and students at our college. They have been well received. I believe that those CDs are an valuable tool for introducing Desktop Linux to the college community.

And it appears that simple scan has moved on to being a gnome project…tarballs available on gnome ftp site…numbering has changed to sync with the gnome release numbering. So its a clearly identifiable contribution _to_ gnome not just something built on top of gnome.

aram: sure. as I said in an earlier comment, I’m not trying to say Canonical isn’t doing anything. I’m pointing out some essential areas where it would benefit them and everyone else if they did something as well.

They are in the market but not on the high end. Hope that makes sense. Like selling cars but only small ones normal people use and not sports cars.

I would consider myself and my family pretty normal. I don’t want to edit audio, video or photos in professional ways. Of course, it would be very nice to have these abilities but they are not important to me. I want a simple way to get this stuff done. Therefore I believe the resources of Canonical would be better spent on e.g. PiTiVi for video editing or creating a more basic interface for GIMP.

Although if there is some complicated and well thought out ‘high end’ solution and corresponding infrastructure, it is easier to create a basic version from it.
Simple Scan without all the work put into the SANE backend would be nothing.

david: ah, I see what you mean. Really, I meant much the same thing. People who use Photoshop on Windows aren’t all ‘high end’ professionals – a lot of them are amateurs who pirate it or use the cheap consumer versions (even these have some features GIMP lacks). Ditto with video editing; if it’s not clear from the article, I was certainly thinking down your lines of something that’s good for editing little Alice’s soccer game, not putting together the next low-budget blockbuster.

Ok, didn’t know you meant this category of the market. But I’m not a native speaker so maybe I misunderstood.

In general I believe your analysis is spot on but I think there is one thing you haven’t taken into account: There is almost no money in providing a simple solution to edit ‘little Alice’s soccer game’, whereas providing software to run servers for businesses is involving customers that pay because they depend on these servers to make money. No-one depends on editing a soccer game. Businesses are buying support contracts but are consumers?
Consumers do spend money if it is convenient. Cue Apple’s App Store but what if all the software is legally available for free from some other repository due to it being open source?
So maybe that is a reason why Canonical isn’t investing as much as Red Hat?

david: it’s possible, sure, but Canonical are on record as saying their business model involves selling services to their – mainly consumer – user base. If that’s what they’re trying to do, they need a good product for the users to consume the services on top of. Few people exactly *depend* on their usage of computing, admittedly, but many people would be extremely unwilling to be without it, and people certainly seem willing to pay for computing services if you sell ’em right.

It’s not your job to develop a business model for Canonical but what services could they be offering exactly? There is selling music and coupled with that some cloud storage. But what else?
They can’t sell the open source software and support is nothing a usual consumer wants to pay for. I like how they conveniently provide upgrades every six months and security fixes but they can’t discriminate between paying and non-paying users in these regards. Maybe they could offer some ‘elite’ user status for a monthly payment that enables the ‘elite’ user to stress the importance of some bugs or feature requests? Or they have to offer proprietary software conveniently through some kind of app store? I’m coming back to ‘convenience’. That is maybe something but I don’t know if it is enough to support the development of all the missing desktop software or the development of the infrastructure like X11.
Apple is mainly selling Hardware. Canonical isn’t. Maybe they should offer a tablet on their own?
And by the way: By revenue Red Hat is 25 times bigger than Canonical. Canonical can’t be contributing as much as Red Hat.

david: As you say, it’s not my job, which is a good thing, because I really don’t know. =) My big idea when I was at Mandriva, which one or two people in management were enthusiastic about but not enough to really make it fly, was to make my.mandriva a full-service hub like Apple’s mac.com stuff. But that’s a pretty sketchy and unproven idea and I would be surprised if the combined mental might of Canonical can’t come up with something better. The thing is, though, I’m going off what Canonical has said: when asked what their business model is, they’ve said it’s to sell services. They haven’t provided much more detail than that, so I haven’t got anything else to go on…

“And by the way: By revenue Red Hat is 25 times bigger than Canonical. Canonical can’t be contributing as much as Red Hat.”

Well, it’s hard to give a specific figure because Canonical is a private company and doesn’t have to report revenue. But yes, Red Hat is clearly a bigger company, and I doubt Canonical can afford to have as much engineering talent on staff as RH or Novell can, yet, indeed. I honestly reckon that it could find the cash for at least some of the things discussed in my post, though, if it considers them a high priority (which it should) and tries hard enough. Canonical doesn’t exactly present as being short on cash – they’re keen enough to support conferences (which is great), run their own conferences, send out merchandise and do press and so on. They certainly don’t present the same signs of being cash-strapped as, say, Mandriva.

Fantastic article, IMO. I really appreciate the constructive tone of your piece, and it makes me see how the F/OSS world really could operate as a team rather than competitors.

One question: Do you happen to know whether or not Canonical or any other Linux distributor would make money off of OEM installs. For example, the Dell Ubuntu computers — is there something in that for Canonical? Because if not, it’s hard to see where a company like Canonical would expect to make money off of desktop development, directly or indirectly.

In short, is there really room for a F/OSS party to make money off of a perfect desktop, or is bettering the desktop only a way to make your brand more popular so that you can sell server support?

I’m no expert, but from what I know, the short answer is that there’s money in OEM deals, but not a whole lot. This is mostly experience from Mandriva, note. What tends to happen if you get an OEM deal of any significant size in the works is that the manufacturer in question starts getting phone calls from Microsoft offering Highly Competitive Prices. (Mandriva’s then-CEO once, fairly infamously, documented a case of this). Basically when you’re doing OEM deals of any significant size you have to keep your price extremely low to avoid Microsoft undercutting you. Things may be somewhat different in jurisdictions with tougher anti-dumping laws – as I said, I’m no expert – but let’s say Microsoft is always an extremely enthusiastic competitor…

I have no specific knowledge of how much money, if any, Canonical makes from Dell’s Ubuntu preloads.

What Canonical’s said in the past is that their business model is to sell services around their software products, just as Red Hat and Novell do. You can see them making moves in this direction recently, particularly with Ubuntu One; this is the kind of ‘service’ they’re talking about. (They have a plan in 10.10 to introduce a service that will sync a list of installed applications to Ubuntu One so when you install a new system and sign in to Ubuntu One you can install all the same apps, that’s the kind of direction they appear to be going in). In this scenario, they don’t make money directly from the operating system itself, but from services it allows (and encourages) access to. The model isn’t exactly about selling *server* support, though that certainly seems to be an avenue Canonical’s developing an increasing interest in. They also seem to be making cloud-y moves lately, which may turn out to be an astute decision.

There is something I do not understand. If the business model of Canonical is to sell services, why do they still do a operating system ?

For syncing file, there is dropbox, for bookmarks syncing, there is delicious, syncing music, there is itunes. Everything that can earn some money with services could be done without a whole operating system ( and a complete separate bugtracker, a complete dvcs and the tools that canonical developped ).

My own supposition is that the business model changed since the beginning, as Canonical seems to go where the wind push them. Arm become a hot topic, they push Linaro ( or the compatibility with Android that was presented some years ago ). Cloud become hot, they start a cloud based distribution.

The only thing that requires your own OS is the appstore clone. And I doubt free software has changed since Mandrakesoft tried to do the same some years ago, so the whole free software ecosystem is still hostile by design to closed source software. Only linux based system like android could be viable for this business plan to work, since Google control every part of the OS, unlike Canonical that still depend on external coders.

I definitely see what you mean about selling the services. I think, in regards to the question of whether an OS is necessary for selling services, the answer is this: If Ubuntu can attract enough end-users, and can be so linked to Canonical services that Canonical is drawing a lot of subscribers from Ubuntu users, then an OS is a better way to find paying users than simply building a program. It’s almost like a complex advertising platform, perhaps much like ChromeOS will stand to draw a huge number of people into Google online services that provide them with revenue.

I suppose it’s a hard balance, then, for Canonical. As a long-term vision, it would make sense to pour a lot of money and time into creating an amazing desktop, which will then translate into the sale of your services. But the more time and money you put into an application, the less time you’re investing in cutting-edge services that will make you money. But that’s where the F/OSS model seems different than many business models; you’re part of a community, and you have to find a balance between contributing to the community and making your product distinct. Miss out on the former, and you’re biting the hand that feeds you; miss out on the latter and you’re simply not eating.

all right but remember that Canonical is a company with $ 30 million, RH is 20 times as much, Novell as well.

With the limited opportunity which has now canonical do what we can, certainly if Mark Shuttleworth wants to break the piggy bank and add 100mln things would change but you know how to think about his retirement (I’m joking of course).

The contribution of canonical however is growing over time (and not just gnome) with many small steps.

barrab: sure, someone above made the same point. It’s a valid one – Mandriva had the same problem, it tried as much as it could to hire upstream contributors but simply couldn’t afford to do much of it – but at the same time, I’m pretty sure Canonical does have the money to make some moves at least.

Colin must have fall off his chair by reading you suggest him to work for Canonical 🙂 But you’re right that his work and involvment in pulseaudio project would definitely deserve some bucks and that Canonical should hire someone to work on this part.

I think you are right on the money and pretty much agree with *everything* you said here, I have only a *small* nitpick:

“go do a survey of Photoshop users and find out what it is they need in an open source photo editor”. Please, don’t do that as the result predictably will be: a clone of the Photoshop UI. Better fully implement the findings of the last usability study made for GIMP, or do a new study (made by professional usability people) and implement that. And/or work on the internals, which are pretty well known (migration to gegl) but go at the pace dictated by the contributors number.

I’m also dismayed at the emphasis of Ubuntu only user groups especially in countries where its hard enough to get a Lug going. The Ubuntu LOCO idea would work so much better if it promoted all FOSS equally. Currently it turns me off and I find it divisive and alienating, which clearly is not their intent.

I have finally given up on Ubuntu purely because they spend more time writing little python-gtk frontends and utils instead of using and improving the upstream config tools which could benefit from their usability expertise.

What excites me is the possibility of all those enthusiastic and willing contributers to the Ubuntu community being lead into more upstream participation.

The factual size of Canonical as a company does of course limit its ability to contribute. On the other hand Canonical doesn’t have to bother about a whole lot that makes a Linux distribution work.

I think the examples are good. I’m pretty certain that if Canonical chooses to support even just one, audio, and for example hammer out flaws in pulse-audio and realize the plan of a jack switch for high-end sound production, I’m sure Canonical would gain a lot of goodwill and appreciation. Since Mark constantly points at Apple, this is an area where they could fill one gap and make a lot of users happy.

You list is long Adam, and I doubt Canonical has resources to work on all. It would however be wonderful if they picked one task and put all effort in fulfilling it.

Beside the point:

The funny thing about a Linux interface is that it doesn’t last very long, not even for Ubuntu users, because after a short while of use they realize they can change and make it look however they like. I seldom see

I think you raise a lot of important points. I think it’s quite a harsh assessment overall, but I do agree with the general points you make.

The area where I am obviously most versed is with Audio. While, as you know, I am not an Ubuntu user (or for that matter a huge fan in many areas), but I will defend them a little here.

Yes, Ubuntu totally cocked up their initial PulseAudio deployment. The user base (and vocal/reactionary nature of many in that user base) meant that that did real damage to PAs reputation (which it was able to do perfectly well on it’s own in those days!). As an aside, poor integration in KDE also contributed to the same kind of poor publicity, and it’s one area that just needed someone to do something about it which is when I cracked and did it all! But with regards to PA and Audio, Canonical did advertise a job (or perhaps it was more than one?) in that area and they do have about four people (that I know of) who are generally responsible for audio stuff. Luke Yelavich and Daniel Chen have both posted several patches to the ALSA list (not sure quite how many in total) and are both usually around on #pulseaudio too. David Henningsson is also a very active member of the ALSA community (and PA too) with several patches there also. Then there is Conor Curran who is working on more high level stuff (the indicator and volume things). His work is a little separate at present for the same reason the whole notifications/indicator stuff is a little separate but I reckon that’ll settle down eventually.

I was approached by the agency used by Canonical with regards to working on PA and Audio, so I think they definitely are trying to make headway in this area (although doing more would always be appreciated and doing PA integration stuff more-publicly would certainly be a better approach too – the whole indicator and notification stuff does have some small overlap with some git branches I have for example – tho’ I’ve not really had time to focus on them for a while).

Now the bit where I have waxed lyrical before and I fully subscribe to your comments, is the notification system they developed based on the XDG specs. In fairness to Canonical, and unlike what you posted above I think they did adhere and help extend the XSG notification specs. The specs were always clear that the action callbacks were optional. Where I completely and utterly disagree with the Canonical approach (despite Macslow’s awesome eyecandy!) is the fact that their main system does not use action callbacks. The notification system was one area where both Gnome and KDE are now agreeing. KDE implements the spec in their knotify and things are finally starting to come together, but the Canonical approach of not supporting action callbacks has basically taken a step backwards. Their guidelines actually stated that application authors should roll their own GUIs for when they need user interaction and the notification system does not support action callbacks. While this is the only approach possible, it also leads to design fragmentation and a lack of HIG in this area means that Gnome and KDE apps will look very different and interact with the user in different ways.

Now I’ve probably not described it well above, but I’m sure many Ubuntu users (and some contributors) will feel the same. But the problem with the design stuff is that it’s been largely dictated from above without wider consultation. I’m sure with wider participation from other people would have knocked the “don’t implement action callbacks” thing on the head very early on as a bad idea, but then again, maybe the arguments and interfaces would have been better presented and ultimately looked more attractive and more people would have gotten involved with the effort, leading to better upstream acceptance.

two commits, one is to add a parameter to help an Ubuntu bug collection tool, and one is listed as ‘alsa-info.sh: use distros package manager to retrieve alsa library version’, but actually only does Debian-derived distros, and has a specific stanza for Ubuntu. Which seems, well, y’know, fine, but why not go the extra inch and throw in stuff for other distros too? David Henningsson has one commit, which fixes process detection in alsa-info.sh and adds JACK detection:

that’s fine too, but it’s pretty small beans. So, the question becomes, I guess, if Canonical has these guys, why aren’t there more commits with their names on them? Are they just not doing the work? Are they doing it but it’s not being accepted? Is it being committed under someone else’s name? Where’s the process breaking down?

Adam, it’s worthwhile noting that Canonical actually employs two people to work on audio full-time: Luke Y and now David H (who is working more on the kernel side). I have never been employed by Canonical; all of my contributions to FOSS have been in spare time (as many people’s contributions tend toward).

Checking Takashi’s sound-2.6 git tree on kernel.org seems “more” definitive here. I don’t think there’s any need to point out commits for metrics’ sake, but there are smatterings of patches from me.

Thanks, Daniel. That’s definitely good news and I’ll update the main post to give appropriate kudos soon, I just want to plumb out what they’re doing :). I’ve always understood that the alsa-project tree is definitive for ALSA and stuff gets moved to the kernel.org trees from there; is that no longer the case?

Looking through my alsa-devel archives I see three patches for Mac audio from Luke, which is cool, and several from David, also cool. I notice David’s mails suddenly start showing up with an @canonical.com address in mid-July – prior to that, they came from a personal address. Is that just a superficial change, or was he only hired (or asked to use his paid time on ALSA) recently? If so, I’d almost suggest Canonical use its marketing muscle here: to promote the fact that they’re flexing engineering muscles in the right places 🙂 Because that’s definitely a positive development.

I’ll try and sort out in my own head where’s the best tree to look at to track submissions, have a look at what’s coming from those folks, and update the main post ASAP. Thanks for the heads up.

A few notes: my comment about only 3 folks being employed to work on audio was actually about “general purpose audio infrastructure”. If you look at the entirety of audio then there are actually more people. For example, there’s are at least two folks who work on audio drivers for embedded devices and one person working on drivers for pro audio hw, and who are being paid for that. But neither is relevant for Ubuntu’s audience (nor Fedora’s) really and matters only to a tiny fraction of people.

I had a phone call with Jono Bacon the other day, because I was royally annoyed by the fact that they are now starting a project to put together a sound theme for ubuntu and are unwilling to do cooperate upstream in sound-theme-freedesktop with that, although we made clear a couple of times we were actively looking for folks to maintain the theme, and give it the love necessary, because we as upstream didn’t really have the time (nor design expertise) to do it. It’s a pity that Ubuntu now spends time on this but refuses to contribute this back. Something similar applies to the audio menu and the volume OSD stuff they have been working on outside of GNOME but for GNOME.

During the call it came clear to me that what Ubuntu is doing is mostly about control. “Ayatana” is a project founded to develop GNOMEish software without contributing to GNOME itself, and thus losing control of the code. “Control” here means that they are ones who determine what goes in, that they get the copyright assignment and they control the infrastructure the stuff is maintained in (launchpad). Because control is key for them they create their own projects where they can be king. Which is of course completely legitimate. And there’s no doubt this is all Free Software. However, it is just incredibly bad Free Software citizenship, and shows how they misunderstand how good Free Software works.

To me it appears that if the continue like this they’ll sooner or later end up like OOo with their projects: the inability of Sun to loosen control and create a community which is not dominated by a single contributor who owns everything and controls everything is slowly destroying OOo. Canonical is very much behaving like Sun here with all their copyright assignment and focus on control. I guess they’ll have to learn the hard way that this is not good for projects. In contrast to OOo where the interest of other companies is big and which hence are willing to deal with the control madness of Sun, Ayatana matters little to other distributors, which is why I think Ayatana will have much less of a chance to survive.

I guess every free software company must make its own mistakes before getting everything right. So they may too. It’s a pity though, and kinda weird that the open source community poster child that Jono Bacon is probably considered to be actually doesn’t get the basics right how to organize a good community for developers. What a shame.

And what does this all mean to us? Don’t expect any non-trivial contributions to existing non-Canonical projects from them any time soon. They made pretty clear that that is not going to happen. At least not unless people are willing given up their own control and for example move things into Launchpad, yadda yadda, to make it easier for Canonical to contribute without losing control. Of course, I personally believe that would be a bad choice for every project.

So yepp, what they do is Free Software, but bad Free Software citizenship. They do write Free Software and make it available, but they are unwilling to contribute it to existing projects they are not in control of. And that’s sad.

If I may pitch in my two cents, in terms of image editing, I think Canonical should put their weight behind Pinta. GIMP’s for people who do serious image editing. Pinta is basically Paint.NET on GTK#. I think it would fit Canonical’s demographic better. I removed GIMP in favor of Pinta as soon as I found out it existed. Needs polish and bugfixing, but it’ll become a great program, for sure.

[…] Finishing up controversial crap week: What Canonical ought to do The point is that Canonical has established itself as a big player in the F/OSS world, and to make the F/OSS world better for everyone in it – including Canonical – it’s important that everyone contributes; not just to marketing or UX design or whatever, but to the fundamental engineering. The argument isn’t ‘Canonical doesn’t contribute to $FOO so they’re a bunch of losers, nee ner nee ner!’, it’s ‘Canonical doesn’t contribute to $FOO and it would really be better for everyone if they did’. […]

I don’t make anything of the sort ‘clear in the comments’. As I explained, I missed the contributions to ALSA because I watch the alsa-project.org tree, where there are only a handful of commits listed as coming from Canonical. Even looking at alsa-dev, the number of commits coming from those staff doesn’t look anywhere near what you’d expect from a full-time engineer, so there’s obviously something more to it, which I’m trying to figure out.

Adam, git.alsa-project.org is definitive, but the sound-2.6 git tree on kernel.org is generally accepted as the “master” tree on which to base patches. Clemens L and Jaroslav K both sync the alsa-kernel git tree(s) on alsa-project.org against sound-2.6. So, roughly, for all user-space components (-lib, -utils, -tools, -plugins, etc.) the alsa-project.org git tree is the one to watch, and for kernel-space (-kernel or -driver, which differ in additional development drivers and function wrappers being in the latter) the sound-2.6 git tree is the primary one.

David H was hired by Canonical within the last couple months (though he started very recently) to work on audio enablement (kernel infrastructure), so his Canonical-sponsored work will appear with the company e-mail address. (My patches are submitted with gmail.com or ubuntu.com signs-off.)

Due to RL priorities I’ve stepped back from nearly all of the Ubuntu audio (team) maintainership, but there are fine folks involved who will get things done.

Joining in a bit late, I would add package management to the list.
I switched from Ubuntu to Fedora recently, and I’m finding PackageKit a very smart, ace of spades application, although it could do with some more userfriendliness in terms of looks and usability. On the other hand I find KPackageKit a very cluttered app, that needs a lot of cosmetics.
So this is something where Canonical could and maybe should help in cooperation with the backend core developers: providing a Software Center for the newcomers and giving a more detailed package manager (similar to Synaptic maybe) for the geeks, both built on top of PackageKit, and even integrating Jockey (the proprietary hardware driver installer) into the PackageKit-DeviceKit-udev tandem would be awesome. Maybe an aptitude backend for PackageKit instead of apt-get could show some extra love.

But it seems they are not interested in this. They are developing the software center for their own use, ditching aptitude, and dropping KPackageKit at all in favor of a plainly apt based package manager.
Because it’s sure great they are creating stuff, but it would be more awesome if they cooperated with the uptream where it could really mean useful innovation. That would mean good FLOSS citizenship.