├── .github └── ISSUE_TEMPLATE │ └── generic_issue.md ├── LICENSE ├── README.md ├── maturity-profiles-policies.md ├── maturity-profiles.md ├── project-continuation-policies.md └── projects └── _sample.md /.github/ISSUE_TEMPLATE/generic_issue.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: New issue 3 | about: Creates a public issue to track feedback on the Project Maturity Model. 4 | --- 5 | 6 | 19 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) .NET Foundation 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # A .NET Foundation project to grow the .NET ecosystem through shared models of Quality, Confidence, and Support 2 | 3 | This proposal describes new approaches that we can use to improve the quality and quantity of .NET open source projects, and the .NET ecosystem generally. The .NET ecosystem is strong, but could be stronger still, and there are general challenges in open source projects that we should address in our ecosystem. 4 | 5 | The .NET Foundation is a independent foundation created to support .NET Open Source Software. As an independent foundation it's in a unique position to support open source projects to target new clients and to help projects adopt best practices. 6 | 7 | > TL;DR: We are proposing three new programs: 8 | > * Maturity profiles that define project quality. 9 | > * A training and support program for maintainers 10 | > * A new project forge that creates new projects for the ecosystem. 11 | > The goals of these programs are to increase project quality for consumers, increase consumer confidence in and adoption of community libraries, and to fill gaps to make .NET development more efficient and more fun. 12 | 13 | The remainder of the document describes the proposed approaches, and references documents that define shared definitions and policies that are critical to making these approaches viable in our ecosystem. This proposal is open for public comment and amendment. 14 | 15 | Supporting documents: 16 | 17 | * [.NET Foundation Maturity Profiles](maturity-profiles.md) 18 | * [.NET Foundation Maturity Profiles Program](maturity-profiles-policies.md) 19 | * [.NET Foundation Project Continuation Policies](project-continuation-policies.md) 20 | 21 | Note: The term "projects" is used throughout as a broad catch-all term. While most open source projects are likely libraries, the proposal equally applies to tools, applications, services and other project varieties. 22 | 23 | ## Premise 24 | 25 | The proposed approaches (detailed below) are based on two ideas: 26 | 27 | * Forging new projects at ecosystem scope for ecosystem benefit based on identified gaps or new industry trends will raise the effectiveness of every .NET developer. 28 | * Improving user (person or organization) confidence in open source projects will increase and broaden usage. 29 | 30 | Which lead to the aspirational goal of the proposal : 31 | 32 | > .NET is a stronger choice for public sector and business software, due to safeguards that help protect open source consumers (and their users), a growing set of projects that lower development costs, and a self-organizing ecosystem that values predictability and quality. 33 | 34 | .NET open source projects (including .NET Core) are already used in critical public sector and business software. That's been the case for years. Looking forward, we have an opportunity to define higher value characteristics and build software that incorporates those. Over time (and this has already started), it is expected that maintainers of critical software will require that dependencies deliver higher guarantees around practices. Satisfying these requests will be hard to achieve on an ad-hoc basis, but instead requires a model that operates at ecosystem scale. 35 | 36 | We need shared mechanisms that can produce these and other important outcomes and that we all feel ownership and influence over. The [.NET Foundation](https://dotnetfoundation.org/), as a generally accepted, independent, and trusted intermediary, is uniquely suited to fulfill this role of enabling our ecosystem to self-organize for shared benefits. 37 | 38 | To that end, the Foundation will do the following: 39 | 40 | * Define and publish shared definitions and policies for comment, adoption, and long-term evolution. 41 | * Highlight and improve the free services that are offered to open source projects. 42 | * The .NET Foundation Project Support Action Group will establish a working group that cater to and document/backlog the needs of the primary roles in our ecosystem: maintainers, contributors and consumers. The working groups need to pay attention to the many experiences that overlap across roles. 43 | * The .NET Foundation Technical Review Action Group will establish a working group to implement a new Project Maturity Model as described below. 44 | 45 | ## Inspiration from other Foundations 46 | 47 | This proposal takes inspiration from other software foundations that have analogous programs in place, in particular: 48 | 49 | * [Apache Foundation](https://apache.org/) -- See: [Incubator](https://incubator.apache.org/); [Maturity Model](https://community.apache.org/apache-way/apache-project-maturity-model.html); [Projects](https://projects.apache.org/projects.html) 50 | * [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/) -- See: [Sandbox](https://www.cncf.io/sandbox-projects/); [Projects and Maturity Levels](https://www.cncf.io/projects/); [Graduation Criteria](https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc) 51 | 52 | Apache and CNCF have great structures in place to grow new projects from infancy into graduated projects that operate in reliable and predictable ways. When projects graduate and join the ranks of other mature projects, the foundations do an exceptional job of providing higher levels of visibility. This helps consumers understand "this project is great and has been vetted", making it easy to make good choices selecting projects to use without needing to a do a lot of up-front research. 53 | 54 | The proposed .NET Foundation programs are intended to operate in similar ways and deliver similar benefits as Apache and CNCF while being oriented the around the specifics of the .NET ecosystem. 55 | 56 | Note: Several ideas and some text came directly from other projects, including Apache and CNCF. We stand on the shoulders of giants, and greatly appreciate the work that has already been done in those communities for the public good. 57 | 58 | ## Inspiration from other Projects 59 | 60 | Community projects are taking on related challenges, such as [ClearlyDefined](https://clearlydefined.io/about), [Code Infrastructure Initiative](https://www.coreinfrastructure.org/programs/badge-program/) and [Software Package Data Exchange (SPDX)](https://spdx.org/). These are great initiatives that are intended to provide transparency related to project licensing, source location for binaries, vulnerabilities, and other concerns. We should define practices and provide tools that make it easy to produce the correct metadata such that consumers of those services can find relevant information about .NET packages. 61 | 62 | ## Historical Context 63 | 64 | > The [.NET Foundation](https://dotnetfoundation.org/) is an independent organization, started by Microsoft in 2014, and is now governed by a community elected board of directors. 65 | 66 | The .NET Foundation and .NET Core as an open source project were announced in November 2014. The initial goal was to fully realize .NET as an open source ecosystem, enabling .NET projects to be fully open from top to bottom, including their development stack. Achieving that goal has been a tremendous effort on the part of the community, the Foundation and Microsoft, and it has taken about five years (2014 until now) to make happen. 67 | 68 | One can think of that five year period for the Foundation as being narrowly focused on establishing services for heavily used community projects. Similarly, Microsoft has been focused on establishing .NET Core as an open platform. As we look at the next five years, we should aim to improve the .NET ecosystem much more broadly, in important ways. 69 | 70 | This proposal was developed by a .NET Foundation working group, based on observed challenges and missed opportunities in the ecosystem. The proposal was further refined with the Technical Steering Group and Advisory Council, with the goal of launching an initial pilot and to solicit feedback from the broader community. 71 | 72 | ## Proposal: Maturity profiles 73 | 74 | > Proposal: Define maturity profiles that projects can use for certification, to increase user confidence and adoption. 75 | 76 | Project quality is a tough nut to crack, and can be approached in many ways. For the purpose of this document, project quality is approached exclusively from the vantage point of improving user confidence. 77 | 78 | Note: We should use surveys over time to validate that confidence is improving based on this proposal. 79 | 80 | When you are building an application, every new dependency you add should *reduce* your confidence unless you have a well-justified reason to trust that dependency. The maturity profiles are intended to help provide project consumers (that take a dependency on a community project) with more information so that they can make more informed choices, and also develop a more accurate sense of safety for their code (which to a large degree is a function of its dependencies). 81 | 82 | The maturity profiles attempts to resolve the following real-world challenges: 83 | 84 | * What happens if a lone maintainer abandons the project (for example, due to death), and does not have a plan in place for continuation? 85 | * How does the maintainer manage vulnerabilities, both ingestion of fixes from dependencies of the project and disclosing its own vulnerabilities? 86 | * Does the binary describe the git SHA it was built from, and is that accurate, and public? 87 | * Can users have confidence that the project is safe to use, from the perspective of malware, or other dangerous code? 88 | 89 | The maturity profiles are fully defined in [.NET Foundation Maturity Profiles](maturity-profiles.md). It references additional policies defined in [.NET Foundation Maturity Profiles Program](maturity-profiles-policies.md) and [.NET Foundation Project Continuation Policy](project-continuation-policies.md). 90 | 91 | ## Proposal: Project Forge 92 | 93 | > Proposal: Forge new projects at ecosystem scope for ecosystem benefit based on identified gaps or new industry trends. 94 | 95 | New projects are the lifeblood of any ecosystem. This is particularly important for new industry trends, like microservices, AI, or pick-your-favorite-trendy-topic and equally new innovative ideas that don't yet even have a name. Most promising new projects will come to life in the same way they do today, by a developer that has a great idea, a company that shares a (formerly proprietary) project, or from a student working on a novel research project. 96 | 97 | Even with a vibrant ecosystem, some projects don't seem to happen or fail to reach escape velocity, even though everyone knows that the project is important. Maybe the project is hard, requires coordination among a large group of stake-holders or people think that a large corporation is going to lay claim to that space, so everyone stays away. None of those are good outcomes, yet they absolutely exist today. 98 | 99 | We need a curation mechanism for new projects -- the project forge -- that enables us, as a community, to lay claim to and start the projects we need. It is a kind of ecosystem self-design. 100 | 101 | Projects created through the forge will be encouraged to use the `dotnet` or `dotnet-foundation` GitHub orgs. While forge projects will be controlled by their maintainers, forge projects are intended to be amongst the most community oriented projects in our ecosystem. Hosting them in a neutral space helps to demonstrate and foster that. These projects can publish packages in the `dotnet.` NuGet prefix, as a way of increasing visibility, demonstrating a relationship between forge projects, and as a kind of cousin to `System.` packages. 102 | 103 | A new working group will be formed to do the following: 104 | 105 | * Identify gaps and industry trends. 106 | * Maintain a public project backlog/board on GitHub. 107 | * Accept new project proposals. 108 | * Encourage the community to vote and provide direct feedback on project proposals. 109 | * Recommend new projects to move forward with, to the community and Foundation board. 110 | * Match the most promising projects with maintainers that have interest in taking them on. 111 | 112 | ## Proposal: Maintainer "Bench" Program 113 | 114 | > Proposal: Grow and support a community of contributors that want to become maintainers. 115 | 116 | New maintainers are unlikely to materialize in significant numbers unless we intentionally encourage them as a community. In addition, the project forge concept has a strong dependency on a growing set of maintainers. 117 | 118 | The bench program will provide training, guidance and support, to help contributors feel comfortable taking on project maintenance. Mentors will be made available that can help contributors work through challenges, technical, interpersonal, and (critically important) motivational. 119 | 120 | Maintainers need vacations! The foundation will provide limited-service backup maintainers (if desired) to ensure a project moves forward while the maintainer is away, per their instructions. It may be as simple as merging Dependabot PRs. 121 | 122 | Maintainers may want to move on, and we want to enable new maintainers to take over to help with project continuity. 123 | 124 | A new working group will be formed to manage the maintainer bench program within the .NET Foundation. It will: 125 | 126 | * Provide docs, and guidance (for self-help). 127 | * Provide training for free Foundation services (for projects). 128 | * Run an ecosystem-wide "up-for-grabs" or "help-wanted" board for projects. 129 | * Match mentors to projects. 130 | * Identify gaps in maintainer/contributor tools that should be proposed as (high priority) projects to the Forge. 131 | 132 | ## Summary of Benefits 133 | 134 | These proposals are intended to provide solutions for challenges in the software industry, for the .NET ecosystem, with the following desired benefits: 135 | 136 | * **For maintainers:** increase adoption and contributors, by describing and improving project quality for users according to a shared quality definition (the maturity profiles). 137 | * **For contributors:** improves opportunities and mentorship available for personal growth and community engagement. 138 | * **For users:** improves the security and transparency of the open source software supply chain, by making it easier to select dependencies. 139 | * **For users:** increases the availability of libraries that satisfy important scenarios, by adopting a structured process for matching new projects with maintainers. 140 | 141 | As part of developing this proposal, the working group learned that there are an increasing set of industry programs that are addressing related challenges. Most of them include tools that enable looking up a package to learn about licensing, vulnerability and other package/project information. .NET packages don't work well with those tools today, because they do not expose the correct metadata. A major shared benefit of this proposal is that it can be used to better align .NET workflows and developer tools with those industry programs so that the correct metadata is always available, enabling consumers to successfully learn about .NET packages with these industry tools. 142 | 143 | ## Next Steps 144 | 145 | The .NET Foundation will start a pilot program based on this proposal. The pilot will include a small number of projects to validate the fundamentals of the proposal. It will also act as an initial demonstration of the ideas, essentially a proof of concept. While the pilot program will be kept small, any project can register to be included. 146 | 147 | While the pilot is running, it is important to get broad community feedback on the proposal. The working group will be seeking feedback from maintainers, contributors, and users. In terms of users, the working group will seek feedback from individuals, companies, public organizations and governments. 148 | 149 | Some of the ideas proposed will be controversial, and it isn't expected that everyone will want to participate. That's okay! This is entirely voluntary, and is intended for projects for which it's a good fit. 150 | 151 | The initial public feedback period will be open for 60 days. After the proposal has received broad feedback, and appropriately amended, it will be put to a vote with the .NET Foundation board. The board will be given access to community feedback before voting. If the board votes to move forward with the proposal, then the pilot will be expanded to encompass all aspects of the proposal and the .NET Foundation will encourage broad community participation. 152 | 153 | Please provide your feedback, via filing an issue in this repo, reaching out to working group by mail, or requesting a conversation or call. 154 | -------------------------------------------------------------------------------- /maturity-profiles-policies.md: -------------------------------------------------------------------------------- 1 | # .NET Foundation Maturity Profiles Program 2 | 3 | This document describes policies for the [.NET Foundation Maturity Profiles](maturity-profiles.md). 4 | 5 | Any .NET open source project is welcome to participate in the maturity profiles program. Registering for the maturity profiles is separate from applying to be member project of the .NET Foundation. This distinction is covered in more detail later. 6 | 7 | ## Just ask for help 8 | 9 | Some aspects of the maturity profiles might be complicated or hard. You can get direct 1 on 1 help to work through problems. You can reach out to the working group (link coming) to ask questions or find someone to work with you. 10 | 11 | ## Registration 12 | 13 | Projects can request to participate in the maturity profiles by pull request on this repository, following this pattern: 14 | 15 | * Describe your project using the pattern used in the [project template](projects/_sample.md). 16 | * Hyperlink all relevant text, including GitHub handles. Full names can also be included, potentially with links to other resources (like a blog). 17 | * Name your file according to your project (for example `banana.md` for the "Banana project"). 18 | * Add file to the [projects](https://github.com/dotnet/foundation/tree/master/projects) directory. 19 | * All maintainers and trusted successors must separately add their GitHub handle and/or a timestamp beside their handle by git commit. This process demonstrates their acceptance of their respective roles in the project and to participating in the maturity profiles. 20 | * Make a pull request on this repository. The pull request description should make it clear when the working group should start the review process. 21 | * If accepted, the PR will be merged with all commits intact (no squashing). 22 | 23 | There is a preference for keeping these project files relatively short and uniform. Supporting information (for example, links to CI) that demonstrate satisfying the profile requirements should be included in the PR description, or better yet, on a project-owned page (for example, on GitHub). A template can be created for that if there is a demand. 24 | 25 | Maintainers must have an active [.NET Foundation personal membership](https://dotnetfoundation.org/become-a-member) to register, which can be established at no cost. This requirement is intended as a light-weight mechanism to ensure that the interests of maintainers and the .NET Foundation are aligned. For example, there may be Foundation membership votes that are of interest to maintainers. 26 | 27 | Trusted successors do not need an active .NET Foundation personal membership, although they are invited to create one. 28 | 29 | Trusted successors are requested to update the timestamp beside their handle ([example](projects/_sample.md#trusted-successors)) every 90-180 days to validate that they remain available, both generally, and for this particular role. 30 | 31 | Project users cannot register on the behalf of a maintainer. They are free to request maintainers to register (just like they might file a feature request). 32 | 33 | ## .NET Foundation Project Membership 34 | 35 | .NET Foundation Project Membership is separate from the maturity profiles, but integrated in the following way: 36 | 37 | * Projects do not need to formally join the Foundation to participate in the maturity profiles. 38 | * Projects are given the option to join the Foundation at [Basic security practices](maturity-profiles.md#Basic-security-practices). 39 | * Projects must [join the Foundation](https://github.com/dotnet/foundation/blob/master/guidance/new-projects.md) at maturity profile 3 or above. Exemptions may be granted by the working group by specific request. 40 | 41 | Why link the maturity profiles with Foundation membership? In short, this is how other foundations work, and it is considered a good model for growing projects from incubation to graduation for broad ecosystem benefit. However, the working group sees significant value in making the maturity profiles a more generally applicable definition of quality for the ecosystem to use. That's why Foundation membership is part of the maturity profiles but doesn't start with it. Maturity profile 3 is considered a good point to include Foundation membership as a required characteristic. 42 | 43 | There are also more practical considerations. Maturity profiles 3 and 4 include requirements that require paying for things (like signing certificates). Maturity profile 4 includes a requirement to use trusted infrastructure. It is much easier to avoid maintainers having out-of-pocket expenses and to satisfy trust requirements if maturity profiles 3 and 4 are limited to .NET Foundation projects. It is also easier to add potentially costly ($) requirements later on, due to the changing requirements of the industry, if the Foundation simply pays those costs for Foundation projects. For example, the Foundation may upgrade to a higher cost version of static analysis tools and publish that as a new benefit of all maturity profile 3 and 4 projects. 44 | 45 | ## Existing .NET Foundation Projects 46 | 47 | Existing .NET Foundation projects are encouraged but not required to participate in the maturity profiles program. A working group member will be made available for projects that need help. 48 | 49 | ## Forge projects 50 | 51 | New projects created in the [project forge](README.md#proposal-project-forge) will be established as .NET Foundation projects. They will be given initial support such that they can satisfy maturity profile 2 relatively easily. 52 | 53 | ## Working group process 54 | 55 | The working group will process maturity profiles registration requests regularly. The same model will be used for new projects as well as changes between maturity profiles for existing projects. One of the following approaches will be used: 56 | 57 | * The working group accepts the registration, possibly with requested improvements. 58 | * The working group rejects the registration, with feedback. 59 | * The working group puts the registration up for a membership vote, and makes a public decision based on the result of the vote. This is more likely for maturity profiles 3 and 4 candidates. 60 | 61 | Maturity profile changes need to be championed by a working group member who agrees to mentor the library, or identifies a community member who can provide mentorship. 62 | 63 | ## Leaving the program policy 64 | 65 | Projects can remove themselves from the [maturity profiles](maturity-profiles.md) program at any time. Project removal needs to be done in a staged way (over 60 days) to give consumers an opportunity to react to changes in policy. Project removals will be announced ahead of time. 66 | 67 | The [project forking policy](project-continuation-policies.md#project-forking-policy) may be used for projects that are removed from the program. 68 | 69 | ## Projects no longer meeting maturity profiles requirements 70 | 71 | The working group will from time to time will assess existing projects to make sure that the currently assigned maturity profile matches the processes used by the project. In some cases, projects may need to have their currently assigned maturity profile reassessed. When this occurs, a mentor will be assigned to help the project. If the project maintainers are unable to re-adopt practices with the currently assigned maturity profile, the project may be assigned a new maturity profile, or the project will be removed from the program if it fails to meet any maturity profile. Projects removed from the program will be invited to re-apply at a later time. It's important to note that moving between maturity profiles is perfectly normal. 72 | 73 | The [project forking policy](project-continuation-policies.md#project-forking-policy) may be used for projects that are removed from the program. 74 | 75 | ## Maintainer changes license or deletes (goes closed) source 76 | 77 | A maintainer may change plans in a way that is incompatible with the program at any time, and not offer the .NET Foundation an opportunity for a graceful exit from the program. When this happens, the project will be removed from the program. 78 | 79 | The [project forking policy](project-continuation-policies.md#project-forking-policy) may be used for projects that are removed from the program. 80 | 81 | ## Maintainer code of conduct violations 82 | 83 | It is unlikely but possible that a maintainer might start to violate the code of conduct of their own project. All code of conduct violations are taken seriously by the Foundation. 84 | 85 | * Maintainers will be given one code of conduct violation warning, which is considered to last one year. 86 | * Upon a second violation, the project will be removed from .NET Foundation programs, including the maturity profiles. 87 | * Severe violations, such as hate speech, or threats of violence will result in immediate removal. 88 | * Intentional inclusion of malicious code in source or project distributions will result in immediate removal. 89 | * If a project with multiple maintainers wants to prevent project removal, then they can choose to remove the maintainer(s) who violated the policy. 90 | 91 | The [project forking policy](project-continuation-policies.md#project-forking-policy) may be used for projects that are removed from the program. 92 | -------------------------------------------------------------------------------- /maturity-profiles.md: -------------------------------------------------------------------------------- 1 | # .NET Foundation Project Maturity Profiles 2 | 3 | This document describes the .NET Foundation project maturity profiles. It is intended as a shared definition of quality for the .NET ecosystem, for use by producers and consumers. It can be used by consumers to increase confidence in their dependencies and by maintainers to make it more straightforward to satisfy consumer needs. 4 | 5 | Any project can adopt the maturity profiles. The registration process for the profile is described in [.NET Foundation Maturity Profiles Policies](maturity-profiles-policies.md#register). Participating in the profiles is the best way to join the Foundation if that's a goal for a project. 6 | 7 | The .NET Foundation will run a badge server so that projects can officially display their participation in the profiles, including on GitHub and NuGet.org. 8 | 9 | ## Overview 10 | 11 | Project maturity profile is a signal by the .NET Foundation for project users (including corporations and governments) to use for adopting community projects. Projects increase their maturity by demonstrating their quality and sustainability to the .NET Foundation working group: that they have adoption, a healthy rate of changes, and follow recommended security practices. 12 | 13 | The .NET Foundation maturity profiles is analogous to the [Apache Foundation Maturity Model](https://community.apache.org/apache-way/apache-project-maturity-model.html). The primary difference is that the maturity profile defines a specific progression of characteristics (hence the difference in names). The maturity profile does not describe all the details of how projects might or should operate, but aims to capture the most important aspects that are expected to be important to project consumers. 14 | 15 | There are four maturity profiles. Each profiles adds meaningful and observable value for the project, and can be an acceptable stopping point. The maturity profiles are thematic (for example, security practices), with the intention that the project provides most or all of what a consumer would want for that theme. This is as opposed to progressive improvement across multiple themes, but not sufficiently complete for any of them. Projects movement between maturity profiles is normal and changing between profiles just reflects the current projects status. 16 | 17 | ## Profile requirements 18 | 19 | The maturity profiles are described in terms of three categories: health, practices, and benefits. 20 | 21 | * **Health** -- Qualities that are observable through interacting with a project on GitHub. 22 | * **Practices** -- Qualities that are observable through using the project (like a NuGet library), or mitigate potential risks of using it. 23 | * **Benefits** -- Specific assistance and opportunities that maintainers have available to make their project easier to maintain or somehow improve it. 24 | 25 | The health and practices listed for each maturity profile are intended as valuable and important, however, projects may be considered to achieve a maturity profile without satisfying every single line item. Some of the qualities are critical and others are more supporting (they are listed in order of importance, per category). Assessment of projects is intended to hit the sweet spot between rewarding maintainers for an honest effort to meet the requirements of a maturity profile and deliver on a confidence promise to users. 26 | 27 | ### 1. Incubator 28 | 29 | This profile describes a project that is healthy, enabling easy and pleasant interaction and use for consumers. It is intended to be within reach of any project. 30 | 31 | * **Health** 32 | * Uses [MIT](https://opensource.org/licenses/MIT) or other compatible license, and third party contributions are documented in a notice file. 33 | * Uses the [.NET Foundation CLA bot](https://cla.dotnetfoundation.org/) (or acceptable alternative) to manage contributor copyright. 34 | * Uses [.NET Foundation code of conduct](https://dotnetfoundation.org/code-of-conduct) (or acceptable alternative). 35 | * Maintainer(s) respond to and fix issues and encourage community contribution. 36 | * CI/nightly builds are active, usable and their status is visible (by a badge). The build server must be patched and otherwise be considered secure. 37 | * Publishes new stable versions regularly (possibly just patch updates), at least once/year, but ideally at least once/quarter. 38 | * Most code changes are performed via PRs, and open to community feedback and transparent viewing. The specific review and merge process used is a project choice. 39 | * Versioning and breaking change policy is documented. 40 | * Roadmap is documented, via formal document and/or an issue query. 41 | * Build scripts are documented and can be readily used by consumers. 42 | * **Practices** 43 | * No additional requirements. 44 | * **Benefits** 45 | * Access to [.NET Foundation CLA bot](https://cla.dotnetfoundation.org/) . 46 | * Access to the .NET Foundation maturity profiles badge server. 47 | * Increased project visibility, by being listed on the .NET Foundation projects page (for the specific maturity profile). 48 | 49 | ### 2. Basic security practices 50 | 51 | This profile describes a project that has a basic layer of security practices in place, which establishes an important, although narrow, level of trust between producer and consumer. 52 | 53 | * **Health** 54 | * No additional requirements. 55 | * **Practices** 56 | * 2FA in place for all accounts (GH, DevOps, NuGet, …). 57 | * Builds are [reproducible](https://github.com/dotnet/sourcelink/tree/master/docs#continuousintegrationbuild), use [sourcelink](https://github.com/dotnet/sourcelink) and publish symbols (portable PDBs) (in-package or as a [symbol package](https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages-snupkg)). 58 | * **Benefits** 59 | * Access to .NET Foundation build infrastructure for automated/continuous project builds, testing and publishing. 60 | 61 | ### 3. Continuity practices 62 | 63 | This profile is intended to provide a consumer with a project that has proven to be generally useful (via crowd voting), and that employs a higher-level of practices that demonstrate a strong commitment to continuous improvement and secure software. 64 | 65 | * **Health** 66 | * The ecosystem has adopted this project at a significant scale, demonstrated by one or more key metrics, such as package downloads, number of dependent projects on GitHub, or community activity on or related to the project repo(s). 67 | * Project documentation is available for users. 68 | * Documents security vulnerability publishing policy. 69 | * \>1 project maintainer. 70 | * [Member project](https://dotnetfoundation.org/projects) of the .NET Foundation. 71 | * **Practices** 72 | * Complies with [.NET Foundation continuation policies](project-continuation-policies.md). 73 | * Stable packages depend on libraries that are at maturity profile #2 or higher. 74 | * [Signs packages](https://docs.microsoft.com/en-us/nuget/reference/signed-packages-reference) (Note: this refers to digitally signing NuGet packages, not strong naming). 75 | * Uses static analysis tools to validate pedigree and safety. 76 | * Applies [.NET API design guidelines](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/framework-design-guidelines-digest.md). 77 | * Seeks and applies guidance from .NET Foundation design and architecture group. 78 | * Updates package references regularly to accommodate servicing updates in dependencies. 79 | * **Benefits** 80 | * Access to .NET Foundation build infrastructure for static analysis and [code signing (extended validation)](https://en.wikipedia.org/wiki/Extended_Validation_Certificate) using the [.NET Foundation Signing Service](https://github.com/dotnet/SignService/blob/master/README.md). 81 | * Access to a higher level of technical guidance and mentorship. 82 | * Access to .NET Foundation Enterprise LastPass subscription for storing secrets. 83 | * Access to the .NET Foundation trademark service. 84 | * Can use the `dotnet` or `dotnet-foundation` GitHub orgs for project repos. 85 | 86 | The recommended set of static analysis tools is TBD. One option is [Security Code Scan](https://security-code-scan.github.io/). 87 | 88 | [Dependabot](https://dependabot.com/dotnet/) can be used for automatically updating package references. 89 | 90 | ### 4. Full security practices 91 | 92 | This profile is intended to provide a consumer with packages that use infrastructure and dependencies that they can trust, primarily due to the build and publishing workflow. These projects are likely the most trustworthy open source dependencies available. 93 | 94 | * **Health** 95 | * No additional requirements. 96 | * **Practices** 97 | * Stable packages depends on libraries that are also at the same maturity profile. 98 | * Uses .NET Foundation certified infrastructure to build, sign and publish official public packages (ensures package is based on public git commit). 99 | * Pre-disclose .NET Foundation project vulnerabilities that may need coordination from other project maintainers. 100 | * **Benefits** 101 | * Considered trustworthy project by the ecosystem, and can be used and recommended by organizations that require this maturity profile. 102 | 103 | .NET Core, .NET Framework or .NET Standard references are considered to be at this maturity profile. No other projects have a pre-defined status at this maturity profile or others. 104 | 105 | Corporate-backed projects can use .NET Foundation infrastructure (as described above) or can choose to self-certify their own infrastructure to build and push packages. If such a project chooses to self-certify their infrastructure, consumer trust should shift from placing value on .NET Foundation-provided infrastructure to the trustworthiness of the specific corporation that backs the project. Corporate-backed project may be given a different color of badge to indicate this difference. 106 | 107 | ## Caveat emptor 108 | 109 | > [Buyer be-aware](https://en.wikipedia.org/wiki/Caveat_emptor) of your dependencies and make informed choices. 110 | 111 | The maturity profiles are intended to define and provide major improvements in quality and confidence improvements for project consumers. However, it provides no absolute guarantees. Even when viewed through the lens of "best effort and best intentions" on the part of maintainers, bad things can still happen that cause harm. 112 | 113 | Maturity profiles [Continuity practices](#3-continuity-practices) and [Full security practices](#4-full-security-practices) put stronger safeguards in place to mitigate a variety of undesired scenarios. They define a model for building confidence using open source community projects. 114 | 115 | Some projects may display badges that do not use the badge server, and therefore are based on self-assessment and may even be intentionally deceptive. This is not expected to be common and will be discouraged. The community may actively discourage maintainers from this practice. On GitHub, it is easy to tell the source of a badge. 116 | -------------------------------------------------------------------------------- /project-continuation-policies.md: -------------------------------------------------------------------------------- 1 | # .NET Foundation Project Continuation Policies 2 | 3 | Project continuation is one of the most important, but least obvious, concerns for a project. As a consumer of a project, you should want to know what will happen to a project given a set of circumstances that challenge continued predictable functioning. There are high profile industry cases where project continuation did not follow a desired path, resulting in significant harm to consumers. These policies are in place to encourage project continuation in the best interests of consumers, and to make project continuation more straightforward to achieve for maintainers. 4 | 5 | ## Trusted Successor 6 | 7 | Level 3 projects must register a trusted successor in the case that the maintainer becomes unavailable. The successor can be a specific person or an organization. In the case that the project maintainer becomes unavailable, the trusted successor will be given access to project source, packages and any other critical assets, so that the project can continue functioning. 8 | 9 | The [project application process](maturity-profiles-policies.md#application) includes listing trusted successors. 10 | 11 | The (yet unproven) assumption is that services like NuGet.org and GitHub will respect these maintainer-defined policies and enable adding the trusted successor(s) as an admin to an org, repo or package. Alternatively, projects can add a .NET Foundation account to act as a mechanical mediator between the maintainer and their successor, as required, using the same "unavailable" policy. 12 | 13 | A maintainer is considered unavailable if they cannot be contacted or are otherwise unresponsive for a period of 90 days. If the maintainer is fundamentally unavailable (for example, due to death or incarceration), then they are immediately considered unavailable. These examples may seem extreme, but they are actual challenges that have occurred and that caused significant continuity challenges that were resolved in ad-hoc and time consuming ways. 14 | 15 | Corporate-backed projects are considered to self-manage the need for a trusted successor. It is recommended that such projects use a corporate account on source and packages, such that possible breaks in continuity can be managed by corporate staff. In the case that the corporate-backer has a risk of or has gone out of business, it is recommended for maintainers to reach out to the .NET Foundation to select a successor. 16 | 17 | Both source and packages are key artifacts in the .NET ecosystem (and many others). In terms of actual mechanics, packages are the most important resource given that a specific package may be referred to (by name and version) in thousands, even millions, of project files. If a trusted successor is able to get owner access to a package, and has a copy of the source (but maybe not admin access to the GitHub repo(s)), then they should be able to reasonably maintain project continuity. The Foundation may maintain private forks of projects in order to preserve source. 18 | 19 | ## Project forking policy 20 | 21 | There are multiple scenarios where a project may leave the maturity ladder program. It may be a dependency of other projects, such that removing it from the program causes an undesired and viral effect on other projects. The .NET Foundation may fork the project, and publish the library under a new name, with the goal maintaining the requirements of higher-level projects that have a dependency. This down-stream fork may be temporary or enduring, as required, on a case-by-case basis. 22 | 23 | After forking, existing GitHub repo(s) and NuGet packages would remain as-is and under maintainer control. The Foundation would need to select an appropriately differentiated package name (proposal: "dotnetfoundation.foo" in place of "foo"). The repo name could be the same, in a different org (that's how GitHub forks work). 24 | 25 | Forking a community project is a last resort and is a messy option. It should be avoided if at all possible. Other options, like the trusted successor system is a much better solution to some of the situations where forking might be used (as a last resort). 26 | -------------------------------------------------------------------------------- /projects/_sample.md: -------------------------------------------------------------------------------- 1 | # Tardis Project 2 | 3 | The [Tardis project](https://en.wikipedia.org/wiki/TARDIS) provides a set of tools and libraries that enable the user to travel through space and time. This capability is particularly useful for cases where people have made mistakes in the past (or the future) and want to fix them. 4 | 5 | Tardis software components are only effective if they are properly installed in some form of British-made computer in a big blue police box. It is also very helpful if the user is wearing colorful stripes, on some part of their clothing (for example, scarf or shirt). 6 | 7 | ## Project Info 8 | 9 | * Info: URL 10 | * GitHub: tardis/tardis 11 | * NuGet: packages owned by tardis 12 | * License: MIT 13 | * Main contact: @TheDoctor 14 | 15 | ## Maturity Ladder 16 | 17 | Tardis is a level 2 project. 18 | 19 | See [.NET Foundation Maturity Ladder](../maturity-ladder.md). 20 | 21 | ## Governance 22 | 23 | The project has three maintainers: @JodieWhittaker, @MattSmith and @DavidTennant. 24 | 25 | The maintainers are often away on trips. They have a group of contributors to perform various maintenance tasks when needed. They are also the trusted successors of the project, and are listed in that section. 26 | 27 | ## Trusted Successors 28 | 29 | The following contributors are [trusted successors](../project-continuation-policies.md#trusted-successor) of this project. 30 | 31 | * @AmyPond (2019.09.22) 32 | * @Rory (2019.09.23) 33 | * @RiverSong (2019.09.24) 34 | 35 | Successors are requested to periodically update the timestamp beside their handle to demonstrate that they remain available for the role. An old timestamp might suggest that the successor is no longer available. 36 | 37 | ## Quick Links 38 | 39 | * Link1 40 | * Link2 41 | * Link3 42 | --------------------------------------------------------------------------------