Skip to main content

The Open Source Maturity Model

The Open Source Maturity Model (OSMM) is a framework that helps organizations assess and improve their use of open source software. The primary purpose of the OSMM is to provide a structured way for organizations to evaluate their open source practices and identify areas for improvement. The model consists of a set of maturity levels, each with a defined set of characteristics and activities that an organization must achieve to move to the next level.

Why Have an Open Source Maturity Model?​

  • The OSMM framework can help organizations to better understand the benefits and risks of using open source software and to establish policies and procedures to manage these effectively.
  • The model can also be used as a tool for benchmarking an organization's open source maturity against that of other organizations in the same industry or sector.
  • The OSMM can provide guidance to organizations on how to improve their open source practices and to align these with their overall business objectives.
  • The ultimate goal of an OSMM is to enable organizations to maximize the benefits of open source software while managing the associated risks and costs effectively.
  • Since there are lots of Activities in this body of knowledge, the maturity levels provide some guidance about the order to tackle activities. Organisations beginning their open source journey are advised to start with activities categorized as Level 1 and proceed from there.

Existing Maturity Models​

There are two pre-existing published open source maturity models at the time of writing which are both fairly similar. Here we attempt to synthesize these into a single whole:

Fortunately, there is common agreement between these two models about what practices are expected at each level. Here, we adopt a 1-5 numbering scheme as this is more consistent with the original and most well-known maturity model, CMMI.

The Five Levels​

Level 1: Ad-Hoc Usage

At this level, an organization has ad hoc or informal practices for managing open source software. There is no formal policy or process in place for managing open source software, and its use is left up to individual developers. The organization has limited visibility into open source use and does not keep track of the software used.

Level 2: Compliant Usage

At this level, an organization has established some practices for managing open source software. The organization has some visibility into open source use and there are limited controls in place to manage open source software and to ensure compliance with licenses.

Level 3: Contribution

At this level, an organization has established proactive practices for managing open source software. The organization has a comprehensive policy in place for managing open source software, and it is consistently applied across the organization. The organization has a comprehensive inventory of open source software in use and manages it effectively. The organisation will begin to contribute to existing open source projects that it finds strategically useful. That is, becoming part of the open source community.

Level 4: Engagement & Hosting

At this level, an organization has a well-managed process for open source software. Open source is culturally embedded in the organisation and its value is understood. At this level the organisation itself is hosting and maintaining software projects that they have open-sourced.

Level 5: Leadership & Strategic Advantage

At this level, an organization has an optimized process for managing open source software. The organization has a continuous improvement process in place for open source software management, and it is well integrated with the overall software development process. The organization also has a strategy for consuming open source, contributing to open source software projects and engaging with the open source community.

Measuring Levels​

Each level of the Open Source Maturity Model corresponds to a different set of activities. And, each activity is associated with a single maturity level.

This means it is possible for an organization to be making progress on multiple levels at the same time: they might be performing all of the activities at Level 1 and Level 2 and some of the activities of each of levels 3 to 5.

The OSR SIG are working on a Maturity Checklist which asks you to measure progress on each activity.

For each activity you can assign one of the following values (taken from the CMMI Model):

0. Unaware​

This is the default. Leave this value as-is if you are not aware of how your organisation performs this activity.

1. Initial​

At this level:

  • Processes are typically ad hoc and chaotic.
  • The organization does not provide a stable environment.
  • Success in these organizations is likely to depend on the competence and heroics of the people in the organization and not on the use of proven processes.

2. Managed​

  • Projects have ensured that processes are planned and executed in accordance with policy;
  • the projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions. Outcome: The key aspect of this level is the establishment of project management disciplines covering planning, performance monitoring, and control.

3. Defined​

  • The organization has a set of standard processes, which is the basis for Level 2, is further developed to take into account the tailored needs of different projects and is used consistently across the organization.
  • These standard processes are supported by the organization and are improved over time.

4. Quantitative​

  • The organization and projects establish quantitative objectives for quality and process performance.
  • This level focuses on the use of measurement and statistical techniques to understand and control processes.

5. Optimised​

  • The organization’s performance is optimised through incremental and innovative process and technological improvements.
  • The quantitative process-improvement objectives are established and continually revised to reflect changing business objectives, and the effects of deployed process improvements are measured.