Open source support can be a lucrative business for software vendors. It’s kind of necessary for large organizations that cannot implement any software without support. But not all support is the same. Some companies offer support that they have difficulty really fulfilling. I have tried to come up with a checklist to help you decide which vendor you should choose.
1. Do they have full committers on the project?
In his book “Producing Open Source Software”, Karl Fogel discusses the critical role of committers on an open source project: “The project cannot rely on people’s own judgment; it must impose standards and grant commit access only to those who meet them.” Take the inverse; suppose your support provider does not have committers. Do they really understand the code? Can they recognize a bug? Can they even propose a code change to the community?
2. Do they have global scale?
Let’s say you have developers in N. America, Europe, India and China. You will more than likely need 24×7 global, follow-the-sun support. Easier said than done. Some people solve this with low-cost support centers. But how much do they know about your open source product and do you know that your confidential data is safe?
3. What support systems do they have?
Can you dial a number and get someone on the line in your time-zone? Can you have multiple internal people see and manage support tickets? Is there a knowledge base? I even heard one story where a Subversion support organization wanted to use Skype to transfer a customers confidential Subversion files for analysis – now that’s a big red flag!
4. Do they care? Are they passionate about this stuff?
It goes without saying; but to provide great service then you really have to care. Part of the goal of open source support is to provide direct feedback to make the open source product better. Support providers that care are more than just an insurance policy they are doing it because they care about the future of the open source product they are supporting.
5. Don’t buy just an insurance policy.
Open source support providers love selling insurance only. Why? It’s easy. You’re paying for something that you might use once in a blue moon and the margins on that are huge. Really ask yourself if the provider could fix a corrupted repository or provide impartial advice on tuning your Subversion implementation for maximum performance?
6. Don’t be fooled into using their modified version of the OSS.
One of the big reasons to use open source software is to avoid vendor lock-in. You should be careful to read what it says on the tin. Subversion, for example, is licensed under the Apache License, which pretty much allows free use of the software for any purpose (distribute, modify, etc). Other, modified versions of Subversion may be licensed under more stringent license terms as either a proprietary license or even GPLv3 which Steve Ballmer referred to as “”a cancer that attaches itself in an intellectual property sense to everything it touches”.
7. Does their business model conflict?
Why is the provider offering open source support? To make money? To create demand for other products or services? Because the market needs them to? Whatever the reason it should be a good one. I hope it’s not just to make money J
8. Check out references?
In our space, Subversion Support, there are so many horror stories. Support tickets unanswered for months (and even years), inadequate support systems, lack of knowledgeable staff, using partners to fulfill contracts who have not received adequate training, lack of integration with open source committers. Just like any enterprise purchase check out a couple of references.
9. Ask a few questions upfront, test them!
Some of our support customers have done this and I think it’s pretty clever. They say, “Well if you’re better than company X then you should be able to answer this, because they couldn’t”. And they provide a list of say 3,4 or 5 questions. Maybe they could even be items that your current provider failed to answer adequately. However you do it. I would do it upfront.
10: Pick WANdisco for Subversion support
Look finding ten very different things is tough OK and let’s face it I am biased. But the advice above is good. Before we had full time core developers on the Subversion project we could not offer Subversion support. If you just paid $100K for a new Ferrari would you get it serviced by a one-man-and-his-dog outfit operating out of their home? Would you trust a company that only used the cheapest of the cheapest resources thousands of miles away with inadequate systems and untrained staff? Would you trust a company that couldn’t answer a few softball questions you threw at them?