We’ve been publishing a series of tips on managing your use of open source to maximize benefits and minimize the risks. You can find earlier other posts in the series here and a summary of the entire set of tips here. In today’s post, we continue with a tip on establishing a service and support policy.
7. Establish a policy of service and support
When something breaks in an open source project, who do you call? Software being software, there will be bugs. Plan for it; it’s going to happen. And when it does, you’ll be glad you thought through your support plan in advance.
The complexity of the open source project, and the importance of your application along with your tolerance for risk will determine the type of support you’ll want. There are a few options to consider, including:
- Self-support. For simpler and less critical components you’ll likely just need good online resources so that someone on the team can become your internal expert. But this option contains hidden costs because when something breaks, you’ll need to spend time and attention resolving the issues.
- Community support. Active open source projects have vibrant communities willing to lend a hand when you have a problem. Projects typically have message boards and on-line defect tracking to facilitate this type of support. This is typically a good choice for more complex components used in less critical applications. Like self-support, you’ll still need to dedicate internal resources, but the community will have your back.
- Commercial support. For the most complex and/or critical applications, commercial support is the logical choice. Vendors like Sonatype have dedicated teams who can help you resolve problems quickly. They’ve seen all the common issues and have the expertise to solve more complex cases quickly. Often they have have direct access to key project committers or help run the open source project so that your feedback and bug fixes can be quickly addressed. When researching support options, you’ll want to think about a few key things, such as support hours, response times, and how you’ll interact with the vendor (web, email or phone). For your most critical projects, you’ll probably need a service level agreement that guarantees minimum response times.
Once you’ve thought through your support plan you’ll be ready to deal with issues when they arise. And arise they will – they always do.