Open source maturity model: Understanding and harvesting the benefits of OSS
2020-12-17
5 min
Open Source Software (OSS) is everywhere. Living in the OSS era, it might seem challenging to keep up with its exponential paces. The open source movement has entered the global arena over the course of the last few years, opening the doors to the collaborative world of software.
OSS pools the talents which in turn leads to greater innovation capabilities. Therefore, new development opportunities are continuously developed and symbiotically benefitted from the network. The great majority of software nowadays is OSS and companies should keep up with that!
From Carl-Eric Mols’ experience, former Head of Open Source at Sony, “Sony Mobile would probably have fallen by the wayside in today’s mobile market. Without Android, we simply would not have existed after 2011 – a fate that many of our then competitors faced. You have to realise that more than 90 % of a handset’s software today is based on Open Source.”
Why Should You Measure Open Source Maturity?
However, how can you transform the company in such a way that it comprehends how Open Source impacts the business? After a long history of closed and proprietary mentality in development, such big yet highly needed shifts cannot simply happen overnight.
Therefore, some kind of descriptive framework on the steps towards OSS comprehension should become common practice. That in turn will communicate the current Open Source maturity of the organisation and what it can improve and aspire for. So, what can be done?
Remixing the Established Models – Welcome the Open Source Maturity Model
Inspired by two influential maturity models, enter the Open Source Maturity Model! Remixing the famous 90s Capability Maturity Model and the Eclipse OSS Maturity model, a convenient tool is developed from the Sony Mobile journey origins and insights from Carl-Eric Mols. So let’s dive into it!
How to Measure Maturity – The Open Source Maturity Model
1. Accidental
Coincidental use of the OSS
Oftentimes, when Open Source culture is not yet established at the organisational level, OSS may be used by coincidence. For example, by buying devices from suppliers which may come with some Open Source code (such as device drivers).
Another example could be the situation when engineers are trying to cut some corners and simplify their work by bringing in some useful Open Source code found in GitHub.
Ignorance and legal doubts
Discovering that the company is using OSS might come as a surprise to the management who, due to the lack of a deeper awareness on Open Source, may be concerned with the legal issues which may come with Open Source licenses.
Therefore, at this stage, it is crucial to collaborate with the legal department to establish policies and processes for handling Open Source correctly.
→ Hence, gradual awareness and set up for legal grounds leads to open source enlightenment!
2. Repetitive
Approving the policies
So, under the previous stage, the general policies and licenses for OSS have been established and approved. The licences are normally approved if they follow the Open Source Initiative’s definition on what Open Source is – OSI is the very organisation that created the term “Open Source”.
Develop open source practices
Developed processes have to be set up for how to work with OSS, and compliance has to be established.
Training, training, training!
What comes next? Continuous training and raising awareness throughout the organisation on the new collaborative approach!
→ However, some components in the product are truly vital, if those components are based on open source, how can you influence them? How can we affect the community? The solution is to contribute and influence the community by your direct participation!
3. Directed
Participation is the key to taking on the fate of your vital components
If your organisation takes on participation, then you will start influencing the Open Source community.
In fact, the only way to influence an OSS community is by participation through contributions. Therefore, to take on the fate of your components, you need to be actively involved.
Progressing towards better management insights
We are travelling from ignorance to alleviated management direction, yet we are still basing our perception of the engineering needs.
However, often at this stage the product management starts to comprehend that the most important decisions are governed by the Open Source community and not by the own development organisation itself.
Hence, product management realizes that in order to achieve the business goals it has to take into consideration the achievements and performance of an external party – the Open Source communities!
Product management has no say in this unless development gets involved by participation in the communities, so that leaves us with few choices.
Shifting from engineering-driven to business-driven
The business now comprehends that OSS is of vital importance for the organisation to stay competitive, therefore the focus is shifting towards the wider focus from the management.
OSS is affecting the business model, the way of handling business, but also opens for novel ways of conducting the business.
→ Yet, how can we disrupt and craft new business models and market opportunities?
4. Collaborate
Layered view on OSS
At this stage the focus shifts from the code itself to the way of creating the community – inviting partners and crafting business value. Having a layered view on Open Source means looking at it not just as code, a license, a way of culture, or a business tool – yet all of it together!
Enter the Ecosystem and its core
At this stage businesses are mature enough to drive the collaboration work and, eventually, start crafting whole OSS ecosystems. The process often starts with a developer outreach program running your own communities.
The release of useful OSS components, eventually leading to the creation of an Open Source platform (e.g. Android is the platform for the Android ecosystem), and with the additional offerings of services, apps, plugins, tools and possibly a marketplace too, will constitute an ecosystem.
Influence on Business Models
Novel services and an Open Source ecosystem opens up for additional and alternative ways of collecting revenue. That may influence the core business model to deliver a more elevated and comprehensive offering.
→ Having created an ecosystem, you are becoming a powerful force of the market, and this power will be able to disrupt the market logic!
5. Prevail
The Strength of your OSS offering is so high that you may shift market offerings or even turn the market upside down
Companies mature enough to be at this stage are quite powerful since they are able to disrupt and change the logic of the whole market. For instance, take Google with Android. The market of commercially available mobile operating systems software was promptly destroyed just two years after the release and introduction of Android and its Open Source-based business model.
The last major commercially available mobile operating system, the Microsoft Windows Phone OS, was shut down in 2017, leaving Android with some 87% market share in the mobile handset market today. As Apple’s iOS is also partly based on Open Source, you could argue that more than 99% of today’s market for mobile operating systems is based on OSS.
→ The full power of being an Open Source master comes when the company is so mature at using Open Source as a business tool, that it is even able to disrupt the current market for its own goals.
Conclusion – How Can You Use the Open Source Maturity Model?
The Open Source Maturity model is foremost a tool for communication within a company and a tool for exploring what capabilities in OSS, engineering- as well as business-wise, can be achieved. It also serves well in training an organization for what may come in a journey of raising the Open Source maturity of your company.
As with most models, the way to start that journey would be to first conduct an honest estimation of your company’s current maturity, followed by a realistic setting of the desired level of maturity to be achieved. When supplemented with a strategy for driving the required changes, the model would then chart your full journey to higher maturity.
Using this model in your communications within the company should spark a good discussion with management on which level the company should aim for in the long run.
Moreover, which goals should be set for the use of OSS in relevance to the overall company objectives? Would it be enough just to extract product value from Open Source, or could the presence of OSS in the company’s offering set off new business opportunities as well?
Knowing where you are and what your destination would be helps in outlining and communicating the journey to achieve a higher maturity in Open Source. However, here comes the limitation of the Open Source Maturity model.
As good as it may be at defining what is possible to achieve on the different levels of maturity, it lacks detailed descriptions on which specific actions should be carried out to drive maturity from one level to another.
These actions and activities in the organization, on the processes to introduce, and on what additions of the offering to make, are vital parts of a strategy, commonly driven in the form of an Open Source Program. What that is will be covered in the next article!
For further reading we recommend checking out the following:
