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 analysis 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 basic questions need to be fully answered and 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 out 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, number of contributors or community health 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 profit. 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 in time 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 if 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 any organization, moving from being a good Open Source citizen to becoming an Open Source company should:
- 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 when selecting Open Source software projects to relay upon.
- A key part of your sustainability effort is to create feedback loops with your providers also at a business level, contributing not just to their sustainability as Open Source projects but also as organizations, 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.
- Put in place mitigation measures to reduce the risk of of disruptions for your key Open Source software providers/suppliers that might compromise the future of the product relying on such FOSS technology or even the company itself.
Conclusions
The fact that Open Source software 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 of those stakeholders supporting the selected project/technology.
As a company, you will not control any more the relation with your providers as you used to. Open Source has changed the nature of the supplier-consumer relation, that goes beyond the license or any other contract. To take advantage of this new reality that comes with Open Source, 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. You will need to write the code yourself, which means, become upstream.
And the smartest way to achieve sustainability writing code is through collaboration.
toscalix 