Open Source Project Maturity Model
Preface
This document aids open-source software project owner in creating their backlog prioritization and assessing their project in the following ways:
Engineering practices: The nitty gritty of code in a project. This dimension focuses on making sure the code that is being added to the project is consistent, secure, and tested such as style guidelines, test suites, and build systems.
Collaboration: How you work with people to get code into a project. Establishing best practices for communication such as documented channels, codes of conduct, contributor license agreements, and code review.
Contributor on-boarding: How a new contributor gets started working on a project–from getting the source code, to building/testing the project in their environment, to finding their first issue to work on.
Governance: How the project is managed and changed over time. Concerns about licensing, leadership, roadmap development, and community feedback.
Awareness: How people discover a project. Best practices for blogging, speaking, social media, and web presence in the community.
Adoption: Getting people to use a project. Making it easy for a consumer of the project's code, library, or project including documentation, quick-start guides, scaffolding and generator tooling.
The following is also a helpful maturity model for inner-sourcing–that is open sourcing a project to a limited set of people within the same organization.
Public
Level 1 - Congrats! Your project is public. The world is your oyster. The possibilities are endless. Here's to you for working in a glass-walled house.
Quality metrics
If you are managing the project as part of your employement, complete any internal open sourcing paperwork
Set up a Contributor License Agreement (CLA) for contributions.
Document the contributing process.
Awareness metrics
Decide whether the project is only public code or community-oriented open-source.
Define a project owner and a technical lead.
Define the purpose, scope, support level, and transparency of the project roadmap:
What can be added to the library?
Do project maintainers roadmap internal or external feature requests?
Is the roadmap public?
Published on GitHub.
Well-maintained
Level 2 - Managing complexity while maintaining quality and trust becomes crucial. You are starting to have a voice. The project is no longer a side project and your management chain takes notice.
Quality metrics
Follows Semantic Versioning.
Has a written “Getting Started” process. The uninitiated can set up the project without help. Basic installation and configuration details are tested and completed.
Define the project's functionality, usefulness, and purpose.
Create automated code-quality standards such as linting and unit tests. Validate with continuous integration. Build status is present.
Documentation can be found in the source code or versioned.
Project commands such as installing and testing are surfaced and easily accessible.
Average response time to issues and/or pull requests by project maintainers is documented.
Write scripts to standardize the release process.
Awareness metrics
Define and communicate communication channels (internally and externally) for feedback.
Related work items are tagged with the "open source” theme in your project management software.
Project owners regularly raise project awareness with internal message board posts, chat channels, and appropriate internal communication.
Write a blog post about the launch of your project.
External consumers engage and create issues.
Project communication is mostly conducted in the public.
Create an engineering-focused presentation for sharing the value of the project and promote adoption.
Join your company's conference speaking group to see how other people are promoting their projects.
Scalable
Level 3 - You start seeing yourself as a bottleneck. Tasks are starting to be delegated. You feel somewhat more like a people manager, but you are still a technical lead. Your co-workers across multiple teams associate the project with you.
Quality metrics
Deploy a publicly available documentation website.
Define a governance/contribution model.
Working examples are available on the documentation website or a sample working repository is available to explain use cases.
Detailed architectural documentation and style guidelines such as a codebase overview are documented.
Processes related to getting started are documented.
Write detailed user installation, configuration, running instructions, and information about common errors and how to resolve them. These are tested and current.
Write detailed information about the project's purpose, functionality and special features/attributes, so that the reader can immediately understand the usefulness and impact of its features and attributes.
Builds and releases occur on remote, public servers.
Dependencies have automated security auditing.
Documentation is always aligned with the latest release and is generated from the source code
Awareness metrics
External consumers regularly create pull requests.
Community sites such as StackOverflow are monitored with tag alerts.
A detailed vision statement, project roadmap, or prioritized backlog for on-boarding new contributors exists publicly.
The project has been adopted by multiple company teams.
Multiple teams have key performance indicators (KPI) methods related to the project.
Create an internal product-focused summary slide deck that concisely explains the project's business value to executives in less than 5 slides.
Host a booth at an internal, customer-facing conference.
Submit a talk to an open-source conference.
Project lead writes two or more blog posts per year about what they are learning from leading the project.
Platform
Level 4 - You wonder how you got here. Developing thought leadership has become more important than management, because management has become a smooth, defined process. Quality is high enough that others trust the project and begin building code libraries on top of it. People associate the project with you externally.
Quality metrics
The project is high quality and stable. All stakeholders trust the project leadership and know the project roadmap.
Other projects build upon the project.
Awareness metrics
Establish a significant external community.
Carry out agile ceremonies and processes publicly.
Maintain a list of internal and external consumers.
Regularly speak about the project at public conferences.
Special Thanks
Special thanks to the Open Source Core Team at Salesforce