I know I just recently posted about how awesome working in the OEM Services department was, but in the eternal quest for new challenges, I’ve moved over to the Desktop team at Canonical.

But before I get to that, one quick bonus story about a patch that I wrote in OEM Services that I really like. You know how when you plug in headphones with a standard audio jack that the audio immediately switches to headphones only? Nice feature right? Now plug in your USB headset. You’ll notice that it didn’t play through the headset: you have to go to the sound preferences tab and choose it as your output device, which is not intuitive. Same deal with bluetooth headsets.

From the user’s perspective, they should all work the same. They’re all just headsets. So for an OEM project, I wrote a pulseaudio module that tried to do just that: whenever a new pulseaudio sink or source became connected, it would switch to using it. It may need some polish (I’m no pulseaudio maintainer), but it works fine. I’d love to see it applied upstream.

Anyway, so I’m switching to the Desktop team to help work on Quickly and other application developer goodness. Speaking of which if you’re a developer, I have a session tomorrow all about release management as part of the App Developer Week: What’s the deal with time based vs feature based releases? How do I best use these Series and Milestone things in Launchpad? Find out tomorrow in #ubuntu-classroom at 14:00 UTC!

I realize that I’ve never really blogged about my work at Canonical. Largely because I work in the OEM Services department, and we tend to be hush-hush. OEM means Original Equipment Manufacturer and just means a company that makes and sells computers with their own brand (like HP, Dell, Lenovo). OEM Services is the group that works with OEMs that are interested in preloading Ubuntu. Anyway, with everyone else on the planet talking about their work, it is a good time to share what I actually do and why.

I feel that making it easy to buy a machine with Linux preloaded is the most important task facing the wider FOSS community. This is how we grow the community, how we break into the mainstream.

But working with OEMs also brings more immediate benefits. When working on a specific project, both the OEM and Canonical will have QA resources dedicated to finding bad bugs or usability issues.

OEMs tend to approach QA with a subtly different eye than I do as an independent developer. They tend to try to avoid any situation where a customer will request support, as that costs money. Which means trying to avoid loss of functionality or letting the user shoot themselves in the foot.

But another thing that comes out of such attention is a focus on usability bugs. It feels really good to be able to spend time making a patch for such nits and send it upstream.

For example, here is a random sampling of stuff that I remember working on:

• Back during the beginnings of a netbook version of Ubuntu, I helped write lots of little patches for applications to make them fit on smaller screens. OEMs would understandably hate it when a program wouldn’t fit on the screen because users wouldn’t be able to click on the dialog buttons and it just looked awful.
• The dialog prompt for PolicyKit used to always display names like “Michael Terry,,,” which always struck me as an eyesore. It showed that way because it didn’t strip the commas from the information that getpwnam() returned.
• When the user sets an unusual “how long to idle before blanking the screen” value, that value just didn’t show up at all in the GNOME Power Preferences dialog. This usually doesn’t come up in practice, but arose because an OEM wanted a 15 min delay, which is not a value already in the list.
• The first time you opened rhythmbox and tried to import a folder, you got a scary “operation not supported” error message. Trying again worked fine. It was a simple fix, but one of those things that you rarely run into and if you do, just kind of shrug off and try again. But it’s nice to be able to fix such first-impressions papercuts.
• A crash in pidgin if you used a zephyr account, enabled tzc, and didn’t have tzc installed. Not only did it crash pidgin, but X itself! This is one of my favorites because it shows just how useful an OEM’s QA approach to testing is. They really “test to break,” and exercise parts of the systems that don’t get much use. This crash was not triggered by a common use case, but had a really bad effect.

So none of these are earth-shattering fixes or cool new features. Mostly because by the time the software gets to me, it’s already as part of an Ubuntu release and thus mostly functional. I just tend to nibble around the edges. There’s a large untapped market of FOSS users that will never install an OS, and I get warm fuzzies by helping to reach them.