Open source presents a great opportunity – and also a conundrum for CIOs figuring out a software strategy for their organisations. Getting open source right presents a great opportunity to lower costs and reduce friction. A mistake here can lead to headaches and dead-end investments.
There are two aspects to successfully using open source software: understanding what phase the open source software you’re considering using is in currently, and assessing the importance of your business problem.
Different Phases of Open Source
Open source software offers different value in different phases of the technology adoption lifecycle:
Early Adoption or Incubation Phase
In this phase, open source software can help define a platform by using input from a set of customers with common needs. Typically, an important use case for a large company will spur the development of a solution. Then part of that solution is recognised to be applicable beyond the company, solving similar problems in other organisations.
Sharing parts of the solution across organisations allows a platform to emerge. This platform matures as multiple organisations refine it based on their needs. The ability of each company to see the code and integrate it into their use cases, with multiple engineers across companies collaborating without much friction, can bring new platforms into market far more effectively than any mechanism seen before.
Standardisation and Commoditisation Phase
When a platform is well known and established, open source software can act as a strong force for standardisation. By providing a reference implementation that everyone can easily access and depend on, it can be a much more effective means of standardisation than committees and documentation.
An open source implementation also makes a strong push toward commoditisation of the technology behind the standard. There is no longer a premium to be paid by customers adopting the standard API because they have a “free implementation” available to them. This means that other vendors providing alternative implementations of the standard have to differentiate themselves in other ways to charge more than the bare minimum.
Assessing your problem’s importance
The second step toward building an open source strategy is to assess the importance of a problem you need to solve.
Open source projects are a great fit for problems that are not critical to the business. Incubation ideas and nice-to-have tools can easily use a variety of open source projects and cut down significantly on cost and development time.
But even if a project is business-critical and there are no off-the-shelf solutions that meet the requirements, an early-stage open source project might be a great choice. The company has to be willing to invest in-house talent to staff an engineering team to contribute and support the open source project. This is not a cost-reduction plan, and you have to be prepared to take over the project if all other contributors abandon it and move on. There is serious commitment required to be part of the community developing the solution. It’s best to have some committers in your organisation who can help influence the project to meet your requirements.
For all other projects, early-stage open source platforms are not a good choice. The choice for these projects is among solutions provided by a set of vendors, some of which may be late-stage open source projects. The criteria for vendor selection are very similar to closed-source-only solutions, though with a few twists:
Total cost of ownership: Though the license cost of software for an open source platform is zero, that may be a very small part of the total cost given hardware, support, implementation cost, and more. The entire cost must be compared across all the vendors.
Vendor lock-in and cost of migration: This is one of the areas where open source projects shine. The fact that multiple vendors are selling the same open source projects should reduce the cost of migration from one vendor to another. But this is only true if the platform is entirely open source and not “open core,” where some part of the platform is open source but other parts are not. It is also not as much of an advantage where the platform is an implementation of a well-defined standard API. It is easy to overestimate the value of this: the main value here is as a leverage in negotiation of price with the vendor and should be factored accordingly.
Long-term sustainability of the vendor: For open source vendors, this is a big area of concern. It is important that the vendor has a business model that can be sustained over a period of time and is not just being subsidised in the short term by venture funding. Also, the business model can put the vendor’s interests out of alignment with your organisation’s interests.
Long-term vision: It is important that any vendor has a long-term vision to deliver on your needs in the future. In the case of open source platforms, this is complicated by the fact that the vendor may only have partial influence on the future roadmap of the project. The vendor needs to have enough control on the future technical direction of the project to be able to maintain control and deliver on future needs. If the vendor has to fork the project, this devolves into a closed source solution and you lose most of the advantages above.
The basis for an open source strategy boils down to understanding your business need and the dynamics of the open source project. For all the hype surrounding adoption of open source, the strategy involves many of the same considerations as closed source solutions.
About Sameet
As vice president of engineering for Snowflake Computing, Sameet Agarwal has over 20 years of database technology expertise and over 15 years of management and leadership experience. He previously led the data infrastructure team at Facebook and was general manager of Microsoft’s SQL Server Relational Database – one of the leading relational databases.
The opinions expressed in this blog are those of Sameet Agarwal and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.
