What I Do in OEM Services

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.

One thought on “What I Do in OEM Services

  1. I love hearing about bug fixes on planets.

    That last bug, the one that crashed X — surely there’s two bugs there, a misbehaving client shouldn’t be able to crash the server. Did you investigate the server bug as well?

    (Your blog’s openid sign-in appears to be broken.)

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>