Open Source in the Enterprise: To Pay or Not to Pay?
The more mission-critical the open source software, the more necessary it is to acquire paid support, suggested Suse's Gerald Pfeifer. "Individual users will often tough out solving problems through community help forums, but SMB owners and enterprise users more likely will opt for paid support rather than devoting internal resources to support open source software," he added.
This story was originally published on Nov. 5, 2013, and is brought to you today as part of our Best of ECT News series.
One of the big attractions behind the growing popularity of open source software is the ability to get it and use it for free. In a world of ever-rising costs in pretty much every other aspect of business and life, "free" is an offer that's increasingly difficult to refuse.
Support is one area, however, where "free" may not be all it seems -- particularly for enterprises.
Users of free software typically rely on the generally sizable community of users and developers for help if questions arise. That support can be excellent, and many users swear by it. At the enterprise level, however, it's worth considering more closely -- particularly when many users are involved and the software is mission-critical.
In addition to offering their software for free, most of the big enterprise Linux operating systems and numerous popular applications give users a choice of paying for support from the developers themselves. In some cases, a software developer may even sell a more feature-rich commercial version.
So when does it make sense to spend the extra money? There's no one formula to provide an answer to that common question, but numerous key factors can help you decide.
'Box of Chocolates'
One potential variable in relying on free community support is the character of the community. Just as open source version options are different, so are open source communities.
"Open source communities can be like a box of chocolates in that the flavors are not always what you expect them to be," Gerald Pfeifer, senior director for product management and operations at Suse, told LinuxInsider.
An enterprise's own in-house staff, of course, will also play a key role.
"Even with your own very good software engineers in-house, it is often a better deal to pay for support from the developer rather than have your own staff learn the product from scratch," Pfeifer added. "In addition to this cost issue, time is also a factor."
Building an Ecosystem
One factor that can sway a company toward the paid version and paid support is the fear of a mission-critical failure.
Open source software often comes with a range of options between free download and user-paid editions. One of those options might be a different license or use conditions with the paid version, Mac McConnell, vice president of Bonitasoft, told LinuxInsider.
"When the free users start getting into production-critical issues, that is when we start getting calls for paid support," McConnell said.
McConnell has no hard numbers on conversion rates for paid support or commercial versions of open source software, but he suspects they depend on the maker's marketing efforts and the software category.
"We understand that not everyone will progress to the paid versions," he said. "We are trying to create an ecosystem so free users are not isolated."
Nevertheless, the more mission-critical the open source software, the more necessary it is to acquire paid support, noted Pfeifer.
"Individual users will often tough out solving problems through community help forums, but SMB owners and enterprise users more likely will opt for paid support rather than devoting internal resources to support open source software," he added.
The need to meet regulatory or corporate standards can be another determining factor that may force an enterprise to move toward paid support.
This might occur when companies have rules about not using community-supported software or security certifications require a vendor's maintenance, explained Pfeifer. Paying for the enterprise version can also fill a need to ensure hardware comparability.
Another factor is the edict some enterprise software vendors impose whereby they'll only support users who run vendor-supported components below the vendor's product on the stack.
Such vendors are not violating the sense of open standards or open source principles, noted Pfeifer. Rather, they want to make sure that the environment in which a customer runs their product is one that the support staff has seen before. This ensures that the environment is on a platform they can support, he explained.
Critical Safety Net
A business will sometimes choose to pay for a commercial open source software license rather than use the completely free, open source license, noted Brian Gentile, CEO of Jaspersoft. Businesses face three primary points of value in deciding this licensing issue.
- Support: One is a formal services and support agreement that provides the customer with a critical safety net. This protects the users if they need to extend or customize the software, address a bug or defect, or have questions about the proper functioning of the software.
- Compliance: Two, a commercial license reduces or eliminates open source license compliance risk and any obligations the business customer may incur when using the open source licensed software version.
- Extra features: Three, in most cases commercial open source software also includes enterprise-ready features that are not available otherwise.
"If any of these three factors outweighs the added subscription license fees, then it makes sense for the business customer to spend the money on the commercial software version rather than just using the free, open source version," Gentile told LinuxInsider.
Defining 'Support'Of course, when to pay for support will generally depend on how "support" is defined.
For example, subscribing to training in order to learn how to configure and run open source platforms and software is very different from paying for ongoing support, offered McConnell.
Even with that distinction included, though, he sees a long list of clients as paying customers from large enterprise companies with their own IT staffs.
'Cheaper to Pay'
Even when paying the license fees for commercial open source software, typically that cost is a small fraction of the fees a business customer would pay to own and use a purely proprietary software competitor, Gentile pointed out.
Then, too, there's the cost a company would incur by supporting the software in-house. Skill levels vary, for instance, so deciding on whether to opt for paid support depends on the company's needs, suggested Kerry Kim, director of corporate marketing at Suse.
Companies may have specific needs and want the full paid support targeted to what they want to accomplish, Kim explained. They also want to pay for guarantees that the hardware and software certifications for that server product are maintained for the hardware and software they use.
"We find that most business view time as a precious commodity," he told LinuxInsider. "While they may have their own resources on hand to support a server distro in house, they find it is cheaper for them to pay for support from somebody else rather than spend their own time and effort trying to support it and maintain it."
Indeed, sometimes an enterprise will start out supporting a piece of software within the company but then switch to paid support when the cost or the problems become excessive, Pfeifer suggested.
Under the Gun
McConnell's company rarely sells a supported version of a software product without the user first having exposure to the free version first.
The tipping point in deciding to pay for open source support often comes when somebody is under the gun, McConnell said.
For example, one large telecom company that became a paying customer for Bonitasoft had five mission-critical projects using the free version. The in-house staff could not figure out how to solve the usage problems through the usual community help channels.
"It becomes a question of risk," McConnell explained. "If you pay for support, you can blame the developer."