monsitj - stock.adobe.com
Commercialising open source
Most software developed today takes advantage of open source, but there are still gaps in understanding what open source means in business
Developing applications using open source components provides the architectural building blocks to accelerate digital transformation. But as it matures in the enterprise, IT leaders need to grasp the mindset shift that goes beyond the “open source is free” mantra and recognise the role it plays in modern enterprise architectures and the enterprise support and service-level agreements, which are very different from traditional commercial software contracts. This difference can jar with the procurement processes that organisations are accustomed to.
Andrew Davidson, senior vice-president, cloud products at MongoDB, believes that any piece of critical software needs to be built on open source components. “It gives people freedom, flexibility,” he said, “and open source tools are kind of more intuitive.”
However, raw open source code, pulled from public source code repositories such as GitHub, tends to come “as is”, with no warranty. From a support perspective, there are no obligations from either side, said Peter Zaitsev, CEO at Percona. “Things happen based on goodwill relationships and negotiations,” he added. “If you want any guarantees – help and support, bugs fixed, old versions maintained, and so on – this all comes with commercial agreements with companies or individual developers.”
The first misconception is the question of “free software”. For many software developers, their first experience of a new open source tool or component is when they take on board the code within a project and try it out. This “try before you buy” model enables enterprises to deploy proof-of-concept applications. Because there is no commercial licence fee, businesses can continue to run the free version in production and scale up the deployment.
But all the support for the open source used must be managed in-house, where developers reach out to the wider open source community to help them solve particular issues.
Shaun O’Meara, field CTO at Mirantis, said: “People sometimes get very religious about open source software. We’re in the game to make money.”
In his experience, organisations need to select a partner business in order to make the best use of open source software. From a Mirantis perspective, he said: “We provide indemnification, guarantees and handle integration. This is a balancing act between offering the choice that comes from using open source with a managed service and guide rails.
“Open source companies build businesses around providing these value-added services on top of the freely available code. Some, like MongoDB, have gone further, commercialising the product as SaaS [software as a service].”
Beyond offering an open source helpdesk, Davidson believes open source businesses have fundamentally different DNA compared with traditional software companies. “In a commercial software company, customers are responsible for getting the software going,” he said.
Read more about open source contracts
- Migrating core business applications requires a multi-pronged approach, so what remains on-prem, and where does SaaS fit?
- Critical problems in open source security require major increases in open source contributions from enterprises – and not just in code, according to Cisco’s head of open source.
When MongoDB started out, the company became the tier 3 support for customers, providing technical updates to the product, said Davidson. But with its Altas software as a service open source data platform, MongoDB is now the first line of support – tier 1.
Although there are a large number of companies commercialising open source with managed services for the enterprise, many widely used open source components are not maintained in this way. Components such as SSH are managed either through committees or a federation of major users, who pull together to fix problems quickly.
“We all need open source standard core building blocks, managed by the federation of users,” said Davidson. When something such as Heartbleed exploits a serious vulnerability, “the entire industry works non-stop to patch the critical component”, he said.
This is how OpenSSH was fixed following revelations of the Heartbleed exploit. Similarly, the community pulled together to patch the Meltdown and Spectre processor vulnerabilities.
Davidson described the way these critical components are developed, maintained and patched as analogous to riding a bike. “You have so many eyes on something,” he said. “But if no one is driving the development of the component forward, just like when someone stops pedalling a bike, the process that keeps open source going falls over.”
Driven by the digitisation trend, software development skills are in high demand, and developers increasingly turn to open source tools and components as their preferred method for building new applications. Amanda Brock, CEO at OpenUK, said that rather than trying to stop software developers using open source, “understand the market you are in and where it makes sense to use open source code”. She added: “Every company needs a policy on open source software. It is not a business model. There is a contract that goes with the software.”
When organisations stipulate open source as part of a request for proposals, Brock warned that the tender process may end up as “a tick-box exercise”. Here the winning tender may go to a firm that says it complies with the OSI model for open source, but it may lack the expertise to support a third-party open source component long-term.
The future for software is increasingly open source. Software developers draw on open source tools and components to help them deliver highly functional software with greater agility. Using open source means they do not have to reinvent the wheel and can instead focus on writing innovative software for the business.
As more open source components become embedded in enterprise IT, the IT leadership team will need to assess whether the free open source code is good enough or whether a managed service or open source SaaS product fits the business’s requirements. Whatever route is taken, support for the component – either through the open source community or a third party – needs to be in place to cover the lifespan of the software-based product that makes use of it.