Beware of forked implementations of open-source software

CIOs must weigh the issue of technology lock-in whenever they make IT deployment decisions. Historically the issue has centered on companies buying many products from a single provider. That single-sourcing offers convenience and easier integration but also raises concern that the buyer is bartering away negotiating power going forward.

The advent of open source software offset many of those concerns. The beauty of open source is that the same software bits are available from several providers so if you end up disliking the support or documentation you get from Vendor A you can switch to Vendor B. No muss no fuss.

But there are some important caveats that smart tech buyers should consider.

Buyer beware of open-source coming from one vendor

For one thing, if an infrastructure provider offers its own implementation of, say Tool Set X but does not submit code tweaks it makes to run that open source tool on its own systems to the broader community, then those changes may not be replicated by other providers of Tool Set X.  This “forked code” phenomenon can be trouble for businesses trying to keep their options open.

One public cloud provider’s open source software may, in fact, get modified or tweaked by that vendor to run on its own cloud, for example. That’s all well and good. But, if that vendor does not share its tweaks with the broader community, as is the common practice in open source, the code base is fragmented and becomes less compatible across providers’ clouds. And that brings the dreaded prospect of “cloud lock-in.”

One of the great promises of open-source software is that its use will minimize friction in migrations. If your app runs here, it will also run over there. But if that promise disappears, the specter of vendor lock-in raises its head yet again. In short, an open source product owned and managed by a single provider in its walled garden is not as “open source” as one in which all code alterations are routed back into the community’s code.

Software developers at any given company have shown they will embrace tools that are easy to get, test and use. They tend to be less concerned with problems that might crop up down the road if open source toolset X is no longer really compatible with toolset X from every other vendor in the universe.

It is up to the CIOs of the world to make sure that developers working for them choose tools that offer options at the other end of deployment.

“Enterprise customers are now very aware of vendor lock-in, and being open plays well in this market,” says Michael Azoff, principal analyst with Ovum Research. That is one big reason that many traditional enterprise software suppliers with roots in the proprietary world are now very open-source oriented, he added.

CIOs need to assure smooth migrations down the road

Stephane Lamoureux, chief operating officer of Virtual Artifacts, notes that open systems are key to success for businesses – including his Montreal-based company, which offers an AI-based privacy engine for mobile apps.

“The days of locking in customers is gone, some cloud and technology providers are making the turn by making sure all their open source tools are made available to the entire community and this is having a great and positive impact on them and the industry,” Lamoureux said via email.

In his view, developers as well as CIOs need to make sure the open-source tools are shared with the community without any single vendor control. That way they can build products that can be used globally.

If a cloud provider builds “open source” tools but does not share them with the community and they are used only on that vendor’s cloud, they are no longer open source but proprietary, he noted.

Dead open-source is good for no one

Enlightened self-interest should motivate all parties profiting from open-source to do their bit. For those non-sharers out there, Azoff noted that if the open source project is no longer supported, it will die, and with it their own internal implementation.

“There’s a symbiotic relationship that makes sense to contribute back to the project, whether in terms of paying support or providing manpower,” he said.

“Nobody wants to take up technology that locks you in. It’s not good for the world of cloud-native computing,” Azoff added.

Lamoureux had his own cautionary coda for cloud providers who might be loath to contribute their code changes and documentation to the community:

“Share it and they will come. Fence it off and they will go to your neighbor.”