Let's introduce a subject that I've rarely seen discussed on planets or forums: Canonical paid-for support. At Oxford Archaeology we have been paying customers for almost a year, and I think it is a good time to look back and see if it was worth it, what worked well, and what could be improved.
Why we chose to buy support
The IT insfrastructure has, over the years, become a critical element in a company like ours. Systems that handle the payslips, the websites, the databases, are very costly when they are not working as expected. You may hire the best sysadmin ever, there will always be the case where a problem/bug occurs that he is plainly unable to solve - and where getting help from the community just takes an unacceptable amount of time.
We purchased support from Canonical to ensure that our road will never be blocked by an unsurmountable bug - and to know that we have a company guaranteeing that the software we deploy will actually work as expected, and that commits itself to fixing it if it doesn't.
How we use Canonical support
I tend to use Canonical support as a very last resort when I really don't know how to solve my problem anymore, or when I have a critical bug that requires a quick fix. This happens fairly rarely, as the support from the community is pretty good - I opened five support cases in the last year.
The support portal for Canonical is http://landscape.canonical.com ; so landscape is not only a monitoring solution, it is also the whole support portal. It integrates salesforce.com for the management of support tickets. Here is what it looks like:
One good point in it is: you do not have to use landscape (the monitoring system) to be supported. We already have a monitoring solution (Munin + Nagios) - and frankly both externalizing our infrastructure and using proprietary services go completely against the very own reason we chose Ubuntu in a first place. Ubuntu gives us the ability to manage our infrastructure ourselves and with free software, and we are happy with it that way.
Quality and responsiveness of the support
The support quality is pretty good. I usually get an answer the next day - the people there are friendly and qualified. Not-so-basic questions on how to use the systems are answered quickly and in a professional manner.
More complex problems (ie: that require a patch / a new version of a package to be pushed) can take more time, but this is normal. I remember encountering a bug affecting apache; I had someone from the support browsing the apache mailing lists to find the correct patch, and making a patched package available to me on a PPA. This was definitely vey much appreciated - the bug was severe, and I wouldn't have been able to fix it myself.
Now what this actually means remains a mystery to me. What does it mean to run Ubuntu on a "certified server"? Is it a requirement for a server to be supported? Does it mean that Ubuntu will run on it? Does it mean that 100% of the hardware the server contains will work, with opensource drivers? Does it mean that 100% of the hardware will work, but eventually with proprietary drivers? And what about the servers that are configurable, and where you can chose from several RAID cards for example - does it mean all the configurations available will work?
The state of the art here is a lot uglier than what it could be. Take for example the Sun X4100 (from which we bought a few at the time because they were supported):
- The Sun X4100 is certified for use with Ubuntu Dapper 6.06
- but its raid card doesn't work with it - and that has never been fixed... although dapper is still supported.
I think we all remember too well the mess Microsoft got in with its "Vista ready" logo. We should learn from that and not do the same mistakes... If a server is certified, it means it has been tested - it would be really helpful to know what exactly has been tested, and to which extent Canonical is committed to getting Ubuntu to work on it .
It is also quite unclear to which extent Canonical will support supported packages. Imagine a software you use has a feature that is badly broken - and that is fixed only 3 or 4 versions of the software later... For example for kvm (yes, I already mentionned that in the past ) - what features of KVM is Canonical committed to support?
- Guest multi-processor support?
- Live migration?
- Paravirtualized network drivers?
All of this is in main, so officially supported. On the other hand I knew when I deployed that some of these features would not work... it is still unclear to me what I can reasonnably expect them to fix. I bet KVM isn't the only package with this issue?
It may sound painful but I think it would be a good idea to explicitly mention in all the packages in main (in the README, or any other text file in the package) which features of the package are *not* supported.
Level of commitment?
Although this never happened to me so far - what if Canonical encountered an issue it is unable to fix? Is Canonical at the very top level of the support chain, or would they eventually hire the services of a company that could fix it, if they reckon they are not able to fix it themselves? I doubt it - but it could be an interesting premium service (just a hint)
I am globally very satisfied with the level of support I am getting - I know I have a bunch of very capable people who would help me whenever I got a question, or who would spend time fixing a bug for me - which is something I may sometimes not be able to do myself. By paying these people to do that I also have the feeling that we contribute (in our own microscropic way) to making Ubuntu a better product, for us, and for all other Ubuntu users.
There are loads of companies out there who are using Ubuntu without paying for support - I hope they will understand that by paying for support, they will allow Canonical to hire more packagers and support staff, which will directly lead to a better product, saving them money in the end.