Open source has exploded. Many organisations run and are attracted to open source projects as part of their IT infrastructure. However, the effect of adopting any open project is not limited to just the project itself. You bring in the entire “open” ecosystem with associated costs and benefits.
While it is often emphasised that the bigger the community, the healthier it is, the incentives that contributors have to develop the project play an equally important role. If those incentives are not aligned with your mission, using open source can backfire.
Certain open source projects rely on private and organisational donations, while others have political goals behind them, and yet another group is supposed to generate leads for proprietary business.
Without understanding what drives the project and makes people want to contribute, you put yourself at risk, which may take a form of security bugs (if the project is so heavily underfunded that contributors do not have time do things properly) or business risks (getting support for abandoned projects may be expensive).
On the other hand, numerous strategic and operational benefits stemming from using open source are quite well understood. We just need to remember that some basic care is necessary.
The key to success when it comes to utilising an open source project in your infrastructure, or indeed opening up your own project to the community, is looking at the project drivers.
To make it possible, you need to learn what projects are you using and how important they are. Here is our take on how you should cover the key areas of using and contributing to open source projects.
Understand your dependencies
This is not a groundbreaking finding – there are multiple organisations (such as the TODO group) that can help you understand which projects you are dependent on and how important they are for you.
By understanding where the weaknesses are, you can at least contribute back where necessary and lower the chances of business mistakes and tangible financial damage from, for example, lost data or using unpatched versions of software.
This approach can surface the true costs of using open source and enable honest discussion about your organisational goals and whether they are achievable.
Do not trust the ‘think open first’ call
Enthusiasts strongly advocate open source, creating hype that can cloud your judgement. However, open approaches work only in certain situations and they can bring unexpected consequences, including destruction of your business model.
Careless project setup may create a situation where people want to use a particular project, but they do not want to contribute back to avoid supporting competition, and such a situations dooms a project.
Understand why you are using open
This goes far beyond knowing what open projects you are using and requires thinking about what the consequences of opening a project or using open source will be and whether those consequences are what you really want.
When IBM “opened” the PC standard, it had to quit that market because it could not compete with cheaper providers. It is almost ironic that PC architecture is recognised as a big achievement of IBM, yet the company failed to monetise it. It is strongly advised to build high situational awareness before using open source to change the market. The technique called Wardley Mapping can help with that.
Bind open and strategy
Open approaches can manipulate the market, change value chain structure and create sustainability problems, and therefore they fit into a much broader context of strategic direction.
Opening the right projects can increase the demand for your services, but this is a strategic move and investment that requires approval from the board. It is far beyond the usual IT responsibility and may involve giving some intellectual property for free. Make sure your leadership teams understand open source, or, at least, be ready to explain it with a couple of iconic open source stories.
User freedoms do not seem to be as important as some people say
This is mostly because freedom comes with responsibility and high costs of maintenance. Expert adopters can cope with maintenance, but a general audience lacking domain-specific knowledge can’t afford it. Non-experts often prefer managed, non-free solutions.
In the past, open approaches were used to propagate use of certain products. Today, mechanisms such as free tiers, customer forums, third-party tutorials and guides are often enough to drive the adoption of a product and act as a sensing engine. Some historical competitions – such as Firefox versus Chrome – indicate that openness and focusing on values may not be enough to win customers.
Open source is attractive to buyers
If you prefer an open source solution, you can be sure that, if your providers have margins that are too high, competition will emerge since the code is open and there will be very little that could prevent it.
For many organisations, and especially for government agencies, this can be a useful route to building competitive provider markets. Such open solutions are likely to survive when the original provider exits the business, as new providers may claim ownership of the source code even if they will be more expensive.
Communities, alliances and working groups are important
They not only can protect the market by adhering to a certain standard and defend the solution from legal threats, but are also an invaluable learning tool, as long as incentives are properly aligned.
Being an active participant, at least for projects that are important for you, enables you to not only meet other contributors, but also understand their situation and better assess the state of the project, and influence its direction.
Be wary of open washing
When an open source project has a dual licence, where one of the licences is commercial, the question should not be whether you fit into the open source use criteria, but whether you can afford legal dispute. It may be wiser to pay for the commercial licence from the beginning than to be forced to switch to it later.
Go in, eyes wide open
Ultimately, to go open means to relinquish control over a solution with the hope of getting returns elsewhere. Understanding where “elsewhere” is, makes it possible to anticipate how various actors will behave and makes your life a little bit easier.
The onus is on you to learn how are you exposed to open source, and how are incentives stacked in your environment. Only after you gather this knowledge, you can fully embrace open source and engage in “win-win” scenarios for all those involved.