5 exercises — Practice key open source governance terms: BDFL, steering committees, contributor ladders, CLA vs DCO, RFC process, LTS policy, and foundation models.
Core Open Source Governance vocabulary clusters
Leadership models: BDFL (Benevolent Dictator For Life), steering committee, working group, technical oversight committee (TOC), maintainer, committer
Contribution: contributor ladder, CLA (Contributor License Agreement), DCO (Developer Certificate of Origin), project charter, CoC (Code of Conduct) enforcement
Foundations: Apache Software Foundation, CNCF (Cloud Native Computing Foundation), Linux Foundation — each with distinct governance models
0 / 5 completed
1 / 5
A new contributor reads the governance document and asks a senior engineer: "The Python project used to list Guido van Rossum as BDFL. Now it has a Steering Council of five elected members. What changed, and why?"
What does BDFL mean, and what model replaced it in Python?
BDFL (Benevolent Dictator For Life): a governance model where a single founder holds final decision-making authority over a project. The term was coined for Python's Guido van Rossum. In 2018 he stepped down, and Python adopted a Steering Council of five elected members.
Key governance models: BDFL — fast, consistent decisions; single point of failure / burnout risk. Steering committee / council — elected group with defined term limits; broader representation. TOC (Technical Oversight Committee) — used by CNCF to oversee project maturity and policy. Working group — a sub-group formed to address a specific domain (e.g., security, documentation).
In conversation: "We're moving from a BDFL model to a steering committee — it distributes load and makes succession planning easier."
2 / 5
At a community meeting a maintainer explains: "We're replacing our CLA with a DCO. With the CLA, contributors had to sign a legal agreement — some employers blocked it. With the DCO, you just add a Signed-off-by line to your commit message — it certifies you have the right to submit the code."
What is the key difference between a CLA and a DCO?
CLA (Contributor License Agreement): a legal contract signed by contributors granting the project specific rights to use their contributions — often including the ability to relicense. Can be individual or corporate. Tools: CLA Assistant, Google CLA bot.
DCO (Developer Certificate of Origin): a lightweight alternative introduced by the Linux kernel. Each commit includes Signed-off-by: Name <email> certifying the contributor agrees to the project's DCO text — essentially "I wrote this and I have the right to submit it." No separate legal signature needed.
Trade-offs: CLA gives stronger IP protection and relicensing flexibility, but adds friction. DCO reduces friction and is employer-friendly, but offers less legal control. Many large projects (Kubernetes, GitLab) moved from CLA to DCO. Apache still requires a CLA (iCLA / cCLA).
In conversation: "Our DCO bot checks every PR — if there's no Signed-off-by, the CI check fails."
3 / 5
A project's GOVERNANCE.md reads: "Roles: Contributor (merged at least one PR) → Reviewer (can approve PRs in their area) → Committer (write access to the repository; can merge PRs) → Maintainer (sets project direction; votes on releases and governance). Each promotion requires a nomination and a lazy-consensus vote by the current maintainers."
What concept does this document describe?
Contributor ladder: a formalised document describing the roles available in an open source project, the criteria for each, and the process for advancement. It makes the path to maintainership transparent and merit-based.
Common roles: Contributor — anyone who has submitted an accepted contribution (code, docs, design). Reviewer — trusted to give meaningful code review in a specific area; can approve but usually cannot merge. Committer — has write (merge) access to the repository; recognised sustained contributor. Maintainer — sets technical direction, participates in governance votes, is responsible for releases and security response.
Lazy consensus: a vote where silence implies agreement — a proposal passes after a defined waiting period unless someone explicitly objects. Used widely in Apache and CNCF projects.
In conversation: "The contributor ladder is published in GOVERNANCE.md — it removes the 'how do I become a maintainer?' mystery."
4 / 5
During planning, a lead engineer says: "Before we change the plugin API, we need to open an RFC. Write up the motivation, the proposed design, alternatives considered, and the drawbacks. The community has three weeks to comment. If the steering committee approves, it becomes the official design spec and we can start implementation."
What is the purpose of an RFC process in an open source project?
RFC (Request for Comments): a structured proposal document used to design and socialise significant changes before writing code. Borrowed from the IETF internet standards process.
Typical RFC sections: Motivation — why is this change needed? Proposed design — the technical approach. Alternatives considered — what else was evaluated and why it was rejected. Drawbacks — honest trade-offs. Unresolved questions — open issues left for implementation.
Projects using RFCs: Rust (RFCs in a separate GitHub repo), Ember.js, React, Kubernetes (KEPs — Kubernetes Enhancement Proposals), Python (PEPs — Python Enhancement Proposals).
Working group: a sub-group formed to own a specific domain (e.g., the CNCF Security TAG, the Kubernetes SIG-Network). Working groups often drive their own RFC/proposal process.
In conversation: "We don't merge breaking changes without an approved RFC — it keeps the changelog traceable and the community informed."
5 / 5
A release manager announces: "Version 4.0 is our next LTS release — it will receive security patches and critical bug fixes for 36 months. Non-LTS releases are supported for 6 months only. We're also publishing our deprecation policy: any API marked deprecated in 4.x will not be removed until 5.0, giving users at least one full LTS cycle to migrate."
What is an LTS release, and how does it relate to a deprecation policy?
LTS (Long-Term Support): a designated release that receives maintenance updates (security patches, critical bug fixes) for a longer period than the standard release cadence. Gives enterprises and cautious users a stable, low-churn target.
Examples: Node.js LTS (even-numbered majors, 30-month support); Ubuntu LTS (every 2 years, 5-year support); Kubernetes (each minor release supported for ~14 months; no formal LTS, but extended support via commercial vendors).
Release cadence: the schedule at which new versions are published — e.g., "a new minor release every 6 months, a new LTS every 2 years."
Deprecation policy: a formal commitment about how long deprecated APIs, features, or behaviours will be retained before removal. Reduces surprise breakage for downstream users. A good policy ties removal to a future major version and aligns the timeline with at least one LTS cycle.
Trademark: foundations (Apache, CNCF, Linux Foundation) hold project trademarks to prevent unauthorised use of project names — e.g., you cannot ship a modified Kubernetes fork called "Kubernetes" without permission.
In conversation: "We pin to the LTS branch in production — we only upgrade to the next LTS after the deprecation window has passed and we've validated our integrations."