I joined Canonical in April, as my loyal blog readers (best looking people on the planet!) know, and immediately, I was drowning in the deep end. I left the relatively safe and sane sandbox of the kernel and tried to choke down two huge pills at once, one called “userspace” and the other called “packaging”.
The medicine was worth it. In fact, it was a large reason why I wanted to join Canonical in the first place: to gain breadth across the entire software stack and learn — really learn — how an entire computer works.
The other large reason I joined Canonical was because I wanted to contribute more to free software, not less.
And that’s why it hurts to see my company constantly getting sniped at for not contributing back to the greater good of the free software ecosystem. The most commonly voiced complaint is that the amount of Canonical’s code contributed back to the ecosystem is very small percentage-wise1.
One of Colin’s salient points:
Because Canonical has a good relationship with many desktop hardware vendors, I have access to the BIOS engineers who are actually writing this code. I can directly report my findings and suggested fixes to them, and then they re-work the BIOS. The end result is a PC that is sold with a BIOS that works correctly with Linux, and not just Ubuntu – all distributions benefit from this work.
You may not see my fixes appear as commits in the Linux kernel because much of my work is silent and behind the scenes – fixing firmware that make Linux work better.
It’s hard to explain how important the above paragraphs are. In the bad old days, the companies who made your laptop and your desktop designed them for Windows only, and didn’t care at all about Linux. This meant that Linux was always going to be a second-class citizen, having to guess at how Windows did something3, and then trying its best to re-implement it, getting it mostly right, but often, subtly wrong in ways that lead to frustration.
In our brave new world, there’s a growing consumer demand for an alternative to Windows. And most of the time, that alternative is the Ubuntu flavor of Linux. The consumer hardware vendors want Ubuntu because their customers — real human beings — want computers with Ubuntu. And those human beings want Ubuntu because Ubuntu focuses on something that the other large distributions don’t care about as much as we do4: namely, the fit, finish, polish, and usability of Linux on the desktop5.
Of course, if a hardware vendor is actually going to sell a machine with Ubuntu, they’re going to want to make sure it is a high quality product, which means lots of testing. And so, major consumer hardware vendors are starting6 to test with Linux before they ship a product, and not leaving Linux users unsupported in the cold, after the fact, having to guess on how to get their machines working with their operating system of choice.
The fact that hardware vendors are choosing to partner with Canonical is a) a direct payoff of focusing on the Linux desktop and b) puts Canonical in a unique position to make huge contributions on behalf of the free software ecosystem that never appear in a git repository7.
Enough about Colin’s work. In my own short time with Canonical, I’ve become the lead engineer on an embedded Ubuntu project, with responsibilities ranging from customizing the entire software stack from debian-installer up through Chromium as well as providing technical consulting for our customer on a wide variety of topics.
One little adventure we shared recently was the selection of a USB wifi part for their product. They asked us which chip they should use and we were delighted that they should ask our opinion. Naturally, we recommended a solution that was easiest for us to support which meant a chip that had good, open drivers with an active upstream kernel development activity.
Luckily, our customer also understood the value of embracing upstream and was willing to pay for a slightly more expensive, but much better supported chip rather than the cheapest, but poorly supported chip from a company that has an adversarial relationship with the upstream kernel community.
I’m not going to lie; helping to influence this purchasing decision, directly financially supporting a chip company that has embraced the “upstream first” model of kernel development is probably one of the best things I’ve done for Linux, moreso than the 192 kernel patches I’ve written.
Of course, I want to make upstream code contributions too. I’m a software developer, after all. And that’s why being a part of Canonical’s OEM team is so exciting. We get lots of exposure to what consumer hardware vendors care about, which is a direct measures of what actual consumers care about, which means we get the chance to scratch big, community itches. By and large the vendors’ requirements share common themes: boot faster, run cooler, save battery life, use less disk space. These are generic problems with generalizable solutions, and it’s my intention to push as many as possible upstream in order to benefit the entire free software ecosystem.
1: The complaints tend to focus on two major chunks of the ecosystem: the kernel and the GNOME core. If I may be permitted to torture a car analogy, the kernel might be the engine, and GNOME would be the body. (return)
2: There’s a lovely bit self-referentiality here that mirrors our actual work relationship: Colin provides a foundation for my software project; why not also leverage my blog entries off his? ;-) (return)
5: Going back to the car analogy, Ubuntu focuses on the trim level. It’s like a Camry vs. a Corolla. Who knows, maybe we’ll even be Lexus one day, but taking the crown from Apple will be hard. (return)
6: We’re certainly not the only Linux distro that does this. Novell has an OEM team as well, getting openSUSE preloaded on machines. But I’m pretty sure Canonical has more partners, and thus influence. Just a guess, no insider knowledge here… (return)