Archive for May 13th, 2010
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.