Open source maturity: Getting started and reaching higher levels

However, the more interesting question is: how can you actually move up the maturity ladder? What needs to be done, and in what part of the organization?

That is exactly why we are releasing another article on the introduction to industrial open source and ways to scale up your open source use. Industrial Open Source is the new wave of OSS driven by businesses developing with open Source as the heart of their business, leveraging the power of it in a commercial way.

We will not go into the whole full picture, but cover the minimal viable program a business should opt for when setting out to become better at open source!

Open Source Maturity Model

First, let’s introduce the Scaling Management Framework (derived by the EU research project Scalare to provide guidance on crafting a roadmap for software scaling approaches including open source). Embarking on this journey will analyse the current state of the things, the drivers and then with the use of identified patterns, we achieve the vision of how we want them to progress.

Achieving the desired level of open source maturity will be done with the help of the key patterns – recurrent activities, processes and changes observed in the company that need to be done in order to gain maturity. 

As highlighted in the previous article, you can split the model into two major stages – the engineering-driven scenario and the business-driven scenario. The first scenario corresponds more to base-forming steps when OSS is relatively new to the organisation, as that is when most of the adoption takes place.

The business-driven scenario corresponds to more abstract concepts in product management and business offerings, and reflects on exceptionally high open source maturity levels not yet harnessed by most companies.

We will primarily focus on the engineering-driven scenario as it is closely tied to OSS itself and offers actionable steps relevant to businesses aiming to improve the way they work with open source within their organization.

Engineering-driven Scenario

The engineering driven scenario introduces the foundational variety of patterns to achieve OSS governance. The left side of the canvas corresponds to the current issues and inabilities making the transformation challenging. Influenced by the drivers of the need to change, the wanted measurable abilities can be achieved!

The patterns are split into three categories – transformations within organisation, processes and product (or offering). Therefore, in this scenario we will present an overview of patterns needed to scale up maturity during the first three levels described in the maturity model.

Organization

The organization domain covers aspects ranging from organizational structure and leadership to culture and people management. So what is it all about? 

Many companies in the Scalare study had exhibited the necessity for a development program which represents a seed for OSS, for instance for when you would want to start a community. 

Moreover, implementing OSS culture into your development is another critical pattern as you have to adapt to the community culture since otherwise, you are not welcome. This is really a development model but it is classified as a culture since it conveys the main principles of OSS, such as transparency, meritocracy, collaboration, etc.

Further comes a program for growing your own industry experts – as development in an open source community can only be influenced by participation and contributions, developers have to be encouraged to take an active part in the community work. 

When thinking of the organizational domain, we need to remember that one of the most crucial aspects of introducing pen Ssource in a company, yet generally also one of the least understood, is the fact that open source will heavily affect product management.

In early stages companies normally find themselves quite comfortable with the thought that using open source is not very burdensome from a legal sense and letting them enjoy the relative absence of costs as open source comes free of a license fee.

However, that rather immature understanding will change over time as it starts to substantially affect product management. The businesses will increasingly discover that as vital parts of the product come from open source communities, those are no longer in the control of the software development department, hence will not necessarily fulfill the product requirements set by the product management.

The product management then has to make a choice, to order an adaptation of software development to fulfill the product requirements, which in turn leads to a costly and ever increasing maintenance burden in the long run.

Thus, the perceived low cost of open source will be lost. Or, product management will have to accept and adapt their approach to a Collaborative Product Strategy instead, where you let software development get actively engaged in open source communities. In that way product management may influence the development, thus the requirement fulfillment, indirectly.

Other essential foundational features in the organisational domain include the establishment of policies, roles and authorities around open source since responsibilities for OSS compliance should be outlined. Moreover, someone shall be driving the whole direction of OSS – an Open Source Officer, and you also need some formal board which may be in charge of vital decisions around OSS – such as code contributions and strategic collaborations.

You should also have some close cooperation with Legal and IPR entities, as OSS relies on copyright law that time and again raises the need for informed interpretations and legal decisions. 

So, the overall red thread in the organisational patterns covers taking a lead in OSS and designating responsibilities and leadership in order to guide the direction of the maturity journey.

To achieve high maturity levels, one should aspire to follow all the patterns presented in the canvas, however, we will note that the most crucial activity bridging all these ideas together is choosing the responsible figure to account for the OSS maturity, namely, the OSS Officer. 

Appointing an Open Source Officer

Most companies appoint someone to the open source Officer role to be a caretaker of OSS processes and activities. The open source Officer is in charge of evolving and driving the OSS maturity of the company forward.

Such a position requires software engineering competences and legal skills, as well as managerial and organizational leadership. Therefore, OSS officers are bridging the gaps between risk-averse company management, legally ignorant software development and reactive legal entities.

The Open Source Officer may also act as a business advisor training and teaching on open source-based business models. Therefore, tools of trade involve development and maintenance directives, policies, processes, guidelines and training programs regarding the OSS maturity.

Processes

Moving on to the patterns in processes, this domain covers all aspects on how the product or service is developed and tested. What do you have to keep in mind in this domain when undergoing the transformation for higher OSS maturity?

One of the key foundational elements is having a process for control intake – i.e. showing that you know the licenses, you have security aspects and estimate whether communities will survive (OSS health). Since this is one of the most essential patterns to achieve in the beginning of your maturity journey, we will present it in more detail. 

Control Intake

When dwelling on your control intake, your organisation should consider several checkpoints:

• Taking in open source, is it a conscious decision? There could be an inflow of OSS without knowing – for instance, coming from a supplier. Not knowing this you might have serious implications for compliance

• Is using OSS components a part of the make-buy-share strategy? (This will be elaborated further on as it is a pattern of itself)

• As we know, there’s a huge amount of available OSS – yet maybe what you need does not yet exist? Availability is another issue to take into account

Having found something you would like to adopt, there are several risks to take into consideration:

• understanding the open source license terms and conditions. If you don’t comply with those you have to either abstain from using the software or redesign, so that you do comply. The latter tends to be costly if done too late into the development.

• handling IP rights and patents. Even though code is available as open source it can still be patented! An example of that could be the RSA cryptographic algorithm – nowadays the patent has run out so you can use it freely, but a couple of years ago it was still under a valid patent and required a paid patent license fee to be used.

• awareness of possible security threats, such as known vulnerabilities.

• awareness of the health of the communities surrounding a project as well as the presence of so called “dead” code; code that is no longer maintained because the community has ceased to exist. You would then have to make a conscious decision about using it or not, since it would mean that you would have to maintain the code yourself.

Having established a process for control intake you, furthermore, need to have a process for compliance by making sure you follow the legal aspects as well as having a process for contributions. 

Control Compliance

The Control Compliance pattern is about implementing the correct level of routines and tools to maintain compliance to open source licenses. This essentially means ensuring that you live up to the terms and conditions for using the open source-licensed code, thus adhere to copyright laws. In short, these are mainly summarized as: 

• Include an attribution of the copyright holder as well as include the license text or a permission notice for any distributed code.
• Some licenses require you to make the source code publicly available as well when you distribute (binary) code.
• Some open source licenses have conflicting terms and conditions with other (open source) licenses, making different code components incompatible with each other, meaning they can not be mixed.

As there is an abundance of open source licenses, a solution for tracking OSS components and their corresponding licenses should also be implemented, called a Software Bill Of Materials. Providing a SBOM is essential in maintaining open source compliance in supply chains. 

If the company breaches the licensing it may face legal and business risks such as copyright infringements, injunctions (i.e. being prohibited to sell your product in a certain market), loss of control and IP, or maybe the worst, gain such a bad reputation that it will affect your business.

Licensing being the core ingredient of correct use of OSS implies the importance to recognise the effective ways of handling control compliance challenges. 

Furthermore, the organisation should be clear in its make-buy-share decisions — whether the code should be developed internally, bought or whether the organisation would want to share the code with the public, i.e as open source. Some other obvious aspects include code review and continuous releases, which is a major difference from traditional proprietary models.

These features are especially important for later stages when you plan to build your own community and start your own ecosystem, which will be touched upon in a future post.

Product

There are also some patterns regarding the product itself. The product domain unravels the software architecture of your product or service. This is more complex than just describing a software application as a monolith.

Product domain might even, in the future and business-driven scenario in more mature stages, refer to the whole ecosystem that defines configurations and interactions between sets of products and services. 

So, which transformational patterns can we highlight on this level? For instance, you need to have fundamental modules and components of software coherently decomposed.

Otherwise, it would be close to impossible to build a community around it and have actionable code. Historically it has been a big issue but it is becoming more common nowadays to keep the code highly modularized. 

Wanted abilities and values

This overview of the patterns helps us establish what we want to achieve since by addressing the characteristics of patterns we can signify the abilities we want to gain. What goals do we want to reach and what value are we looking for? To comprehend that we will try to address all the characteristics of the patterns and achieve the abilities they illustrate.

In the engineering-driven scenario (the first 3 stages of the open source maturity model) you mostly want to achieve reduced maintenance cost by having OSS at all. It is also a great way to increase innovation in your organisation since there is so much code out there, that it becomes impossible to accumulate it in a traditional way. Moreover, following these patterns leads also to gainings an ability to reduce time to enter the market. 

Most importantly, you can extract value from OSS communities to you products which is the core achievement of the engineer-driven scenario. The patterns described are foundational when achieving the first levels of OSS maturity.

There is no single way to group the patterns per 1-3 levels – there is no specific order on which patterns should be implemented first, as it depends on the individual state and goals of each organisation. However, we will attempt to introduce our readers to the most essential transformational patterns.

Business-driven Scenario

In the engineering-driven scenario the focus is mainly on extracting value to your product or offering. When you go beyond that and start exploring how to collaborate with other actors in the business such as partners, customers, and users, you enter the business-driven scenario.

Quite commonly this leads to building an OSS platform where services can be deployed, development tools, a marketplace and in the end to create a full-fledged ecosystem. Therefore the processes of the business-driven scenario are more focused on building industry collaborations.

In the engineering-driven scenario, the patterns were connected to extracting the value from communities into the product. Now it is all about and extracting value into new or alternative business.

As we see, such processes are a lot more resembling high-level abstract business patterns so we will not go into much detail, but just give a brief overview of a possible evolution of the business-driven scenario.

Patterns in business-driven scenario:

The ultimate goal is to extract the value from your own orchestrated ecosystem into your business, i.e to create new or alternative streams of revenue.

1. The seed of the ecosystem is often a developer program which has already been planted earlier on in the engineering-driven levels.

• The core of a developer program is often the release of selected components of free useful code that enables independent developers to explore your offering in novel ways.
• The intention is to catch and nurture the participatory culture of open source. It opens up the company for an environment of independent developers to inspire and influence – and to be itself inspired and influenced by innovation outside the company.

2. Extending the developer program so it becomes your own self run open source community

• Influences go both ways: it paves the way for crowd-based requirement management and fueling an open source driven product innovation

3. The developer program’s offering eventually assembles to a full open source software platform, allowing yourself and other business partners to explore and invent upon, adding services and solutions

• The platform becomes a carrier of new offerings, as well as providing support for open source-based extended, indirect and/or asymmetrical business models (to be visited in a future article).

• The platform acts as the foundation for establishing alternative revenue streams such as revenue sharing, e.g. as the Ad/Search and data collection business found in the tech giants such as Google and Facebook.

4. An ecosystem is established which might disrupt the market logic in such a profound way that it in practice forces all other market actors but the strongest to participate. This in turn leads to an open-source ecosystem not just being the support for a business, but it becomes THE business!

Final thoughts

Harnessing open source is a great challenge, impacting many dimensions of your business. Maintaining a well-rounded mindset and dynamic approach to the transformations will eventually bring you to uncovering the true power of this Holy Grail of the digitized world. 

We have presented the most important transformational patterns to keep in mind when enhancing the usage of open source ranging in the domains of organisation, process and product – appointing Open Source Officers, controlling the intake and compliance. Together with established policies and responsibilities, these steps can jumpstart a very successful journey towards full open source maturity.