Okay, just one more I need to get out of my system. =)
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.