When to upgrade to an enterprise version of the open source software you love

'Free' may get the job done in the short term, but the long term health of your code - and of your operational systems - must be taken into account

Open source software crossed into mainstream enterprise IT years back. One Red Hat survey found just how far open source had come in 20 years: ranked as strategically important by 95 per cent of users while IDC declared open source had made inroads in virtually every level of the software stack.

Developers were the king makers: open source provided them a ready set of well-built, secure and high-quality tools to get their jobs done. It did so, too, at low cost: Not simply the absence of licensing fees but the quality and availability of open source meant developers could work better, thereby cutting the costs and time associated with software's delivery.

That cost factor looks set to become important once again, as organisations are poised to accelerate their adoption of open source in response to Covid-19.

With CFO's cutting IT and staff budgets, open-source is seen as a way to deliver new and existing digitisation initiatives at reduced cost. Almost half, 44 per cent, of respondents in a 2020 Tidelift survey said their organisations would encourage further use of open source during the downturn.

Quality and reliability of code will again be factors helping developers move quickly, but one thing in particular stood out. "They [developers] benefit from the fact code is being used and maintained by a larger community beyond their own organisation," Tidelift said.

This is important because "maintained" has implications depending on its setting.

Traditionally open-source projects have been "maintained" through regular releases or fixes. In the enterprise world, however, that's table stakes. 'Maintained' in enterprise IT adds additional, operational expectations that take you into areas such as collaboration, compliance and regulation.

These business-oriented, operational aspects fall outside community maintained project work but do feature in paid, enterprise editions. Yet, IT buyers who wouldn't think twice at paying proprietary software makers for support struggle when it comes to cracking open the check book for open source: Deciding when to pay is a dilemma for a fifth according to Gartner.

Which is ironic: because running unsupported code in strategically important systems should worry anyone.

Tell me when

The enterprise software-adoption-cycle runs in three phases - development, stabilisation and standardisation; paying for maintenance during each doesn't make sense. So, when is the right time?

During that initial phase, developers experiment with the code. It will be evaluated and used by just a handful of individuals to deliver proof-of-concept and initial builds. Unsupported open source is often good enough at this stage.

When the code stabilises, as it moves into production, those enterprise extras start to matter. This is when teams in operations become involved in deployment and lifecycle so require tools to communicate and collaborate. As code encounters customers, security and privacy come into the picture with the need for compliance, auditing and tracking. Finally, performance and reliability become important, so tools are needed for real-time administration and monitoring.

General rollout means the whole organisation will have standardised on the software. It's therefore important the code is easy to deploy and capable of integrating with mainstream workflows and systems. Achieving this means following best practices and templates. Long-term health is critical so paid support should deliver security updates, fixes and upgrades.

Not very spontaneous

The strength of open source software comes from being rooted in the community. Historically, however, tools, templates, integrations and dashboards for collaboration, monitoring and compliance used outside the development phase have not emerged organically. Rather, they required the intervention of specialists with experience who understand enterprise customers and who partner. They will - and have - channelled these factors into their work on open source projects.

The presence of these experts brings another advantage. Transitioning to a digital infrastructure takes a fundamental re-architecting of systems and practices around distributed and elastic cloud computing and storage.

A paid partner can make the difference between success and failure: it means having somebody who can help you work on the technology and architectural changes and advise on design and management of large and distributed systems. They can advise on migration and deployment, share best practices and benchmarking, and train your team. When it comes to support, there's the added factor of speedy resolution to any problems. Slowdowns and outages are painful for the digital business: investing in support can help minimise the pain.

Conclusion

Open source has empowered developers and built organisations but while your CFO might like to lean on the cost-advantages of 'free' to get the job done in the immediate short term, the long term health of your code - and of your operational systems - must be taken into account.

That will mean investing in the tools and best practices that allow your open source software to work as part of a full-fledged system of enterprise operations and oversight.

Amith Nair is vice president product at HashiCorp