Open source is a risk, but not in the way you might think. We’re long past the days of handwringing that open source will “infect” proprietary code, and it’s also increasingly clear that open source doesn’t pose particular security risks.

Instead, perhaps the biggest risk for open source is that we keep getting confused about it being “free.”

Not as free as you might think

When asked about the biggest challenge in open source, Univention CEO Peter Ganten offered:

A danger is that in complex projects people think: ‘Oh, OSS is free, I just put it all together by myself’. But normally you do not have the know-how to successfully implement complex software solutions. You would never proceed like this with Closed Source. There people think: ‘Oh, the software costs $3 million, so it’s okay if I have to spend another $300,000 on consultants.’

Catch that? With a proprietary product, it’s a given that you’ll have to cough up cash to customize and tune the code to your enterprise needs. With open source, however, too many try to go it alone. Most companies, for example, will do better with a Kubernetes service from Amazon, Google, or Red Hat (OpenShift), yet Cloud Native Computing Foundation survey data suggests many companies still try to forge ahead on their own.

SEE: Quick glossary: Hybrid cloud (Tech Pro Research)

It’s not that they can’t be successful plowing their lonely open source furrow, but whether or not they should. It might not be the best investment of resources.

The Red Hat way

Of course, the key to revenue for open source vendors like Red Hat is that enough companies will understand the risk of going it alone with open source and turn to a vendor for help. As Red Hat director of product strategy Brian Gracely pointed out, innovation happens at a blistering pace in open source, a pace that doesn’t necessarily translate into enterprise readiness:

Open source has never been known for being the people that sit and finish up projects. They’ve always sort of gotten it to a good solid point that does 80% of what you want it to do, or it works well enough but there’s not great interfaces and things on it.

What tends to happen is, either commercial companies like Red Hat…end[] up making it usable for them afterwards. We obviously also see the public cloud beginning take those open source projects and turn them into managed services as well.

Such companies–including system integrators–do the “last mile” work necessary to get open source projects ready for enterprise consumption. Red Hat makes billions on this model, yet it still remains more of an anomaly than it should. We have MongoDB, Elastic, the combined Cloudera and Hortonworks, and other open source companies, but not nearly as many as we should, given how dominant open source has become in the area of enterprise infrastructure.

SEE: GitHub: A cheat sheet (TechRepublic)

Partly this stems from the rise of public cloud providers, as Anaconda’s Mathew Lodge has highlighted, but it also derives from far too many companies thinking that they’re just a GitHub download away from running Kubernetes like Google does. This is wishful thinking, and is likely to end in tears.

Of course, none of this should be read as “open source is risky.” Rather, the idea is that for any given open source project, there’s likely a company well-suited to making it hum for you. Whether that’s a cloud vendor like Microsoft or an open source vendor like Red Hat, the smart money will bet big on open source, but likely mediated by an expert in a particular project.