Business model as a variable to consider when choosing Open Source software.

A couple of weeks ago I gave a talk at an Open Source event for professionals. A senior developer asked me a question that got my attention. It was something like...

So do you recommend to consider the business model when choosing a particular piece of Open Source software, beyond the license?

My answered was something like...

In general yes, specially when that piece of software is core to your product/business and definitely in cases where you distribute/sell it to customers.

 

Thinking about it later and reviewing some of my talks and posts, I thought it would be interesting to develop that answer a little further.

Key questions

Any analytic report about who writes the code in open and collaborative environments will reflect how corporations involvement is increasing in Open Source software development at every level. More and more companies are transitioning from becoming FLOSS consumers to producers and almost every new software company out there has Open Source as a core strategy or even as part of their DNA.

But who is sustaining the development of that key piece of software that will be a core part of your future product? Who pays those developers? Why? How does the key stakeholders benefit from the outcome of the ecosystem and the software they produce? How much do they invest in the production of that software? For how long? How do they get their income? What is the relevance of the software produced by the ecosystem they feed in their business models?

These and similar basic questions need to be fully understood before a specific software becomes part of your key product or business. Knowing the answers to the above questions might not prevent you from surprises in the future but at least can prepare you for the potential consequences. What it is clear to me is that these answers are becoming more complicated to find and understand over time, specially for those companies who do not have a strong background on Open Source.

Choosing a specific piece of software based on purely technical variables or even present healthiness of the community around the project/organization, expectations of the number of contributors or impact in general might not be enough any more. A specific community or project will become "your provider" so the business model behind it is equally important.

Examples

You might base your new product on a technology produced by a company that is heavily investing on it but that has no clear associated business model. It might be for instance a service company and the software might not be core to their services since it has no significant impact in their income. This might not be your case so you can end up relaying on a provider that do not have "your use case" as a critical one, no matter how big you are and how profitable your business could be.

Think about the case when your product relies on a technology that is disruptive but sustained by a start-up or a company that is not profitable yet. Engineers might be extremely excited about this new technology for good reasons, the community around it might be on fire at the point when you are analyzing it, but the future of the business might be unclear due to, for example, the inexperience of the executives leading the project, the market they are playing on or the strategy of the investors supporting it.

A well established project has suffered a fork, attracting the core developers. Very soon a boost of energy is noticeable in the development front, which leads to an increase in the number of contributors. They gain customers rapidly but it is unclear if they have a solid business case to sustain the development effort with the current growth in the short term.

The above three cases and many others out there show that, although there is no question that published Open Source software development represent an advantage compared to proprietary when it comes to sustainability, that doesn't mean it is at no cost. This is specially true when safety critical and/or long term support are essential variables for you. 

Sometimes choosing a technology/project with a business model more aligned to yours could work better than choosing the leading or hot technology/project. In other cases, going for a more conservative but solid/veteran project might be the right choice. In some others, assuming risks can be the best choice.

Key considerations

I believe that for any organization, moving from being a good Open Source citizen to becoming an Open Source company also means that:

• You evaluate the business models around the organizations/projects that produce the software you contribute to and/or consume. This requires involvement of business related professionals in key decisions related with selecting Open Source software.
• A key part of your sustainability effort is to create feedback loops with your providers also at a business level, contributing to their sustainability as Open Source project but also as organization, specially when you are bigger/stronger than they are. Ideally, your business model should be compatible with those from your providers so your success has a positive impact on theirs.
• You put in place mitigation actions to reduce the risk of severe changes in your key Open Source software providers situation that in the worst scenario, might compromise the future of your product or even company.

Conclusions

The fact that Open Source is done in a collaborative way might reduce sustainability risks in most cases compared to proprietary business models. But the nature and complexity (dependencies) of many Open Source ecosystems introduces new risks that requires to consider variables beyond the technical or community aspects.

This is why it is so important to choose carefully which FLOSS software you will use, produce and contribute to, looking at the business models supporting the selected project/technology stakeholders.

As a company, you will not control any more the relation with your FOSS providers as you used to. Open Source has changed the nature of that relation, that goes beyond the license or any further contract. To take advantage of this new reality, you will need to adapt.

Final reminder

Open Source is also about providing more control to creators. If you want keep similar levels of control that you had in the proprietary world, contracts will not be enough anymore. You will need to write the code yourself, which means, become upstream.

And the smartest way to achieve sustainability writing code is through collaboration.