The future is coming ready-or-not

Commercial bug-fixes for Ubuntu

with 3 comments

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.


Written by Steve George

May 13, 2010 at 17:47

Posted in Canonical, Canonical-voices, Linux, Ubuntu

Tagged with ,

3 Responses

Subscribe to comments with RSS.

  1. “Additionally, bugs are generally resolved in the version of Ubuntu under development rather than the one that the problem is reported against.”
    This has always been an awful policy which has hurt Ubuntu development greatly. Simple bugs (“papercuts”) that have trivial fixes or only require substitution of some text are allowed to remain until the product is EOLed, simply because everyone has moved on to the next version already (by definition, since there’s a release every six months).

    Daeng Bo

    May 13, 2010 at 21:07

    • Daeng – thanks for the comment.
      Generally Ubuntu does not fix minor issues within a released version. This is because the law of unintended consequences seems to be that fixing a minor issue for one user seems to break the same software for lots of others. So security and critical fixes are generally reserved for issues where a large number of users are being effected. It’s a balancing act! If you’d like to be more aggressive in using new versions after release then don’t forget to turn on the backports repository.

      Steve George

      May 14, 2010 at 09:19

  2. Steve,
    I’ve been a Linux user since 1997, so I understand that there can be unintended consequences with patches. That’s not the kind of bug I’m talking about (backports are not a solution). Imagine the help system tells you to choose a menu item that has been moved or renamed because the help system is outdated and refers to an older software version. Fixing the bug is simple and has no consequences, yet Ubuntu will routinely mark this kind of bug as invalid because fixing it would break translations (though, in many senses, the translations are already broken even if they’re consistent). The only other response I’ve seen is to properly triage the bug, request and receive information, then sit on it until the version is no longer supported. There was a non-functional package in Universe that didn’t get fixed or purged for _five Ubuntu releases_. That was an easy fix.

    I get these choices from a developer’s perspective. What is says to consumers of the product is that you don’t care about them and the version that they’re on. Ubuntu gets a lot of bad press because of this feeling.

    A huge problem is that there is too much software for the Ubuntu community to properly test before each six-month release. Bugs for the Beta can’t even be triaged before the release, and as pointed out earlier, triaging them after release is pointless. Ubuntu needs to divorce itself from 90% of Universe and Multiverse, move the MOTUs to PPAs, make searching for and adding PPAs through the Software Center easy, and focus on getting releases right since they won’t be fixed once they’re released.

    Also consider more forthcoming advertising: non-LTS versions are supported _only_ for security patches and only for nine months — enough time for users to get on the next version. Be honest. Bugs in this version aren’t going to be fixed unless they involve security. Stop triaging bugs that are never going to be fixed anyway — it wastes people’s time, both volunteers and users.

    LTS version should get functional problems fixed.

    Daeng Bo

    May 14, 2010 at 14:38

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: