Creating Open Source Projects in CMS Ecosystem
What is repo-scaffolder?
A suite of tools for creating new repositories that align with repository hygiene standards and best practices in US Federal open source development.
Maturity Models
A framework to evaluate and categorize open source repositories based on their composition and goals
Repository Templates
A foundation for building repositories that are well-documented, clean, and adhere to repository hygiene standards and best practices
Outbound Checklists
A review process to reduce risk and improve quality when releasing open source projects
Maturity Models
Our maturity model framework is designed to evaluate and categorize open source repositories based on their composition and goals. This framework consists of five tiers, each representing different stages of a project's development practices, collaboration scope, community engagement, and governance structure.






Learn More
Level | Name | Purpose | Description |
---|---|---|---|
Tier 0 | Private Repository | Experimental/Historical | Project is private, usually with a single developer. Typically working projects, example code, and early prototypes. |
Tier 1 | One-Time Release | Information/Historical | Project released publicly, but without planned future activity or maintenance from original author(s) |
Tier 2 | Close Collaboration | Collaborate with smaller, mostly internal teams | Project within a team or Operational Division (OpDiv), Internal Repo for Innersource-style work. |
Tier 3 | Working in Public | Collaborate in the Open with smaller, semi-open teams | Project developed Open Source by CMS or a CMS contractor, public website hosted on GitHub, tool or utility used in CMS official business by the public. Limited external contribution, CMS-led (by choice or by statute). |
Tier 4 | Community Governance | Collaborate broadly in public | Project donated to or stewarded by an external community, open standard that welcomes public input, mature open source project that purposefully develops an open governance structure. |
What is my project's maturity model tier?
Repository Templates
Each maturity model tier requires specific files and documentation such as: project information, security policies, licensing details, and contribution guidelines. This documentation creates transparency, enables collaboration, and supports sustainability.
Repository File Requirements by Tier
File | Description | Tier 0 | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
---|---|---|---|---|---|---|
LICENSE | Defines the licensing terms under which the project is distributed. | M | M | M | M | M |
code.json | Contains project metadata following legislative requirements. | M | M | M | M | M |
README.md | Provides a comprehensive overview of the project, including its purpose, how to install or use it, and any relevant information for users or developers. | M | M | M | M | M |
COMMUNITY.md | Lists project team members and points of contact with detailed roles and responsibilities. | M | M | M | M | M |
SECURITY.md | Outlines the agency's security policies, including how to report security issues or vulnerabilities in the code. | R | M | M | M | M |
CONTRIBUTING.md | Offers guidelines for contributing to the project, including code standards, how to submit issues, and creating pull requests. | R | R | M | M | M |
CODE_OF_CONDUCT.md | Establishes guidelines for acceptable behavior within the community, setting expectations for how contributors should interact in a respectful and collaborative manner. | N | N | M | M | M |
GOVERNANCE.md | Describes the governance model of the project, such as decision-making processes and rules for contributing. It ensures a transparent process for managing the project. | N | N | N | R | M |
Level | Description |
---|---|
M | Mandatory |
R | Recommended |
N | Not Recommended |
Get started!
Create a repository using our cookiecutter CLI by running the command below, replacing X with the tier number:
cookiecutter https://github.com/DSACMS/repo-scaffolder --directory=tierX
Managing your Repository
repo-scaffolder includes a suite of tools to help maintain and manage your repository throughout development.
Outbound Checklists
A review process to approve CMS-developed software to be released as open source.
Learn more about each step of our outbound checklists
1Pre-Requisites
Verify the project's tier and ensure the corresponding outbound checklist is being followed.
View section
2Benefits
Evaluate the cost savings, extensibility, innovation, and other development benefits of open sourcing the repository.
View section
3Risks
Evaluate the potential security, financial, and privacy risks of open sourcing the repository.
View section
4Code Review
Ensure code quality and security through an independent review of the codebase by agency developers.
View section
5Code Analysis
Ensure code quality and security through analysis and testing with open source tools.
View section
7Repository Hygiene
Include required files, sections, and documentation in the repository to meet hygiene standards.
View section
8Metadata
Store metadata on the project, as part of the Federal Source Code Policy and the agencyβs software inventory tracking initiatives.
View section
9Sign off
Review and acknowledge the risks and responsibilities associated with releasing the code to the public.
View section
10Flip the Switch!
After passing outbound review, the repository is officially ready to be public and shared with the greater community.
View sectioncms.gov
An official website of the Department of Health and Human Services and the Centers for Medicare and Medicaid Services