Canonical’s Ubuntu support scope

What software will Canonical provide support for? That’s probably one of the questions you were asking if you read my previous post about commercial service subscriptions and bug resolution. Or perhaps not, but it’s a rhetorical device that suits me for this post!

Generally speaking for an application to be supported as part of a service subscription it has to be within the Main repository. This is because applications within the Main repository receive public maintenance (bug fixes and security updates) for the life-cycle of the release.

In order for an application to move into Main it goes through a stringent security and quality assurance assessment. As part of this review Canonical’s engineers inspect the code and ensure that they are able to maintain it. Consequently, those engineers also provide bug-fixes and maintenance for Canonical customers.

I find it interesting that generally the ability to maintain and fix code is one type of developer skill-set, while writing new features is a different one. Colin Watson recently told me that an early manager had told him that there are two types of developers in the world, those that create things and those that finish them off. Intuitively that feels right to me and by definition a distribution is focused on the latter where integration, polish and quality assurance rule.

The second issue is how do you know which software is covered within the Ubuntu service that you subscribed to? Some Linux distributions deal with this by covering all the software that they physically ship to customers. However, in Ubuntu’s case most users receive the software electronically so this doesn’t work. Second, the Main archive and seeds are relatively fixed and don’t map well to a subscription service for a particular target market. Essentially this means it’s hard to reflect the services within the technology.

Consequently, when a customer purchases a particular service subscription they receive a Service Description. This describes the scope of support, the bug-fixing coverage, the legal indemnification, the software components covered and the response levels. For example, a consumer desktop service wouldn’t cover complex integration problems with a Microsoft Windows network, while this would be critical for a corporate subscription designed for customers with legacy networks. Effectively, the description tries to describe the types of use-cases and categories that are covered.

I hope this has given a bit of insight into how Canonical does support and bug-fixes for our customers.

Commercial bug-fixes for Ubuntu

If you have a commercial subscription service for Ubuntu how do we prioritise fixing bugs? This was at the heart of a conversation I had with a customer recently.

For business users Ubuntu’s advantage is often flexibility. Adding another system to the data centre is simply a matter of starting it up. This contrasts with proprietary UNIX and the other commercial Linux vendors where license management creates deployment friction.

Nonetheless, it’s hardly “free” if you can’t use the software. And Ubuntu, like all software, has bugs and issues – particularly when you’re using it in a complex environment. To resolve these issues professional users need access to expertise when there’s an issue.

In the proprietary world the license agreement commonly includes support so the customer presents the bug and they should get a resolution.

Ubuntu’s free nature presents a more nuanced picture. Every Ubuntu user is able (and encouraged) to put bugs into Launchpad. Many of these bugs will be resolved by Ubuntu community developers or Canonical’s developers as we work on the next release of Ubuntu.

Nonetheless, any individual bug is a needle in a haystack. Ubuntu receives vast numbers of bugs from our user-base so there’s no guarantee that any individual bug will get a response or a resolution. There’s inherently no prioritisation of one user over another as all members of the Open Source community are equal. Additionally, bugs are generally resolved in the version of Ubuntu under development rather than the one that the problem is reported against. The need for certainty of response and resolution is the value of a formal relationship with Canonical.

A service agreement means that the customers bugs are guaranteed a response, that the issue will be dealt with by an Ubuntu expert and that the issue will be prioritised. For Canonical engineers customer bugs are prioritised over general development work and are split into categories by urgency.

Initially when the customer presents the case the GSS (Global Support & Services) team triage it and where possible come up with an immediate workaround. If the bug requires code development then it is escalated to the appropriate engineering group. This is where a resolution for the version of Ubuntu that the customer is using is created. This is generally delivered to the customer as a custom package for them to use immediately. The resolution is then integrated into the version of Ubuntu under development so that there won’t be a regression when the customer upgrades to the next release.

So flexibility is the Ubuntu advantage, and the advantage of working with Canonical is there’s a canonical resource for Ubuntu expertise.