What is the number one factor that software developers consider when choosing which open source software packages to use? A recent survey conducted by Rogue Wave Software says support. What is the second most important factor? Who will carry the burden of providing that support.

Between developers, a dedicated internal open source software (OSS) support team, an internal IT department, and contractors (or an OSS support vendor) an unsurprising 67% of developers in the survey said they are expected to be responsible for support. We also analyzed 34,000 internal support requests to glean additional insights.

There are no stupid questions when it comes to OSS use, and these are their most common issues:

1. How do I set up or use a particular function within this package?
2. How does this security update affect me?
3. How do I isolate this bug between the proprietary and open source code in this stack?
4. Which package or version is the best choice for what I want to do?
5. What are the differences between these two versions that apply to me?

Additional support challenges arise when an organization elects to use OSS because they are new to open source, or the best practices for use aren’t defined:

• Lack of knowledge or experience for a specific package or version.
• Application performance issues and tuning.
• Mandated use of packages by the customer but little in-house expertise.
• Need for fast bug turnarounds in production to meet uptime requirements.
• Support redundancy; what happens when key expertise goes on vacation?
• Desire to combine OSS and proprietary code to deliver custom stacks.
• Need for workarounds for older versions that are no longer officially supported.
• Consolidating multiple different versions and OSS processes across the organization.

Though this isn’t surprising it can be troubling, and developers shouldn’t have to carry the entire support burden, especially for complex software stacks that encompass databases, build tools, operating systems, middleware, mixed proprietary and open source software, service-level agreements, and multiple, and often conflicting, software licenses.

When deciding who owns support in your organization, you want to choose a team that can provide support for your entire software ecosystem and is easy to get in touch with when you need help. They should provide the necessary expertise and tools, including:

• Tier 4 architects, not junior-level engineers
• Help along your development journey from build, to continuous integration (CI), to continuous deployment (CD), to monitoring production environments
• One number to call for all your questions

The open source software ecosystem is different from the proprietary software world, and organizations need to learn new ways of managing it. Some issues to consider are the openness and diffuse nature of OSS development, how well the proprietary software works with the open source software, and licensing.