We are looking for high-quality projects that improve all aspects of the general practice of "Continuous Delivery" for all software development, such as CI, QA, deployment, and SRE. We want to drive the modernization of Continuous Delivery, but make this available to everyone.
Copied from the charter document as the starting point:
- believes in the power of Continuous Delivery to empower developers and teams and to produce high quality software more rapidly; believes in the open source solutions collectively addressing the whole software delivery lifecycle;
- fosters and sustains the ecosystem of open-source, vendor neutral projects through collaborations and interoperability; and
- advocates this idea and encourages collaborations among practitioners to share and improve their practices.
Software has eaten the world, and the appetite for better software is so bottomless that some engineers feel like something needs to be sacrificed to keep up with the demand. At the CDF, we refuse to do that. Security, reliability, velocity: Pick Three! The TOC “believes in the power of Continuous Delivery to empower developers and teams and to produce high quality software more rapidly,” because Continuous Delivery practices should result in strict improvements across all three dimensions for developers. They should not have to choose between moving fast and not breaking things.
Security: Vulnerabilities everywhere can have outsized impact on end users. Delivery is one of the first and most important places to inject and enforce best practices around security. We need to respect this opportunity and drive the industry forward to provide better, more secure software for everyone.
Velocity: Continuous Delivery practices have been known to improve the velocity of software development for a long time. Helping people adopt these practices, and helping projects further increase velocity will help the industry deliver more value to users faster.
Reliability: Continuous Delivery is about accepting that bugs will slip through cracks, and controlling the risk and the damage of changes. It prefers smaller frequent incremental changes to control the risk, then building a defense in depth that contains the damage.
To help “practitioners to share and improve their practices,” the TOC upholds these values, and we seek projects that share them:
Pragmatic: The most important attribute of a project is how useful it is to actual practitioners. Purity in design and implementation comes second to solving real-world problems for them.
Maintainable: The software we write today needs to grow and change over time. We prefer solutions that save us time in the long run vs tactical savings that build technical debt.
Portable: The choices we make for Continuous Delivery today may not make sense tomorrow. Users should be empowered to change their decisions with minimal friction.
Platform/stack agnostic: Continuous Delivery applies to all software development, not just practitioners on a particular platform or stack. We have an overall goal to help them modernize, but adopting Continuous Delivery even on "legacy" stacks will help this modernization process go even faster.
Overall ecosystem fit: Continuous Delivery is a broad space and no "one tool" can solve everything for everyone. Projects should fit into the broader ecosystem - whether through plugin-style extensibility, explicit interface exposure/usage, or something else.
In order to “foster and sustain the ecosystem of open-source, vendor neutral projects through collaborations and interoperability,” the TOC values these characteristics in the communities that produce the projects, and we seek communities that share these values:
Governance: Transparent governance with a clear path for new contributors to become maintainers, and for maintainers to become project leaders.
Collaboration: A community that is willing to interact with and listen to other projects and people with different thoughts, skill sets, specialities, senorities, and backgrounds, and let those influence the direction.
Openness: A community that is open, transparent, accessible, and operates independently of specific partisan interests. A community that accepts all contributors based on the merit of their contributions. A community whose decisions are transparent.
Fairness: A community that seeks to avoid undue influence, bad behaviours, and/or “pay-to-play” decision-making.
The whole should be greater than the sum of all parts. A successful CDF should provide be a single place to look for best practices, guidance and documentation as well as tooling and projects. Practitioners looking to improve their delivery practices should have to look no further than the resources provided by the CDF, regardless of their software stack, platform or industry.
Benefits: The CDF should not be a "grab-bag" of projects, and projects do not need to be hosted in the CDF to interoperate with projects that are in the CDF. Projects in the CDF should either provide a unique benefit to the CDF or uniquely benefit from being in it.
- Version 1.0: 2019-03-29
- Approved by TOC on 2019-04-23