# The Checklist That Keeps Open Source Projects Alive > [!question] Lingering Questions > - Where's the actual readiness line between "ego in check" and "not ready for feedback" — is it self-assessable at all, or does it need an outside evaluator too? > - Does the no-CLA stance generalize past AlmaLinux's specific build model? > [!tip] Article Ideas > - Turn the checklist (goals → outside eval → ego → channels/templates/timelines → AI/CLA policy → leadership → self-care) into a one-page "before you open contributions" worksheet for WordPress component leads. > [!link] Cross Reference > - [[3. Resources/MOCs/Open Source Governance MOC]] > - [[3. Resources/MOCs/Commons & Community Governance MOC]] > [!quote] Vocabulary > - *Bus factor* — the number of people who could disappear from a project before it stalls; a bus factor of 1 means the maintainer is a single point of failure. > - *CLA* — Contributor License Agreement; protects a project legally but deters contributors unwilling to sign over rights. ## Bib capsule AlmaLinux maintainer, "The checklist that keeps open source projects alive," All Things Open (ATO) talk, YouTube, 2026. [[3. Resources/Readwise/Articles/The Checklist That Keeps Open Source Projects Alive]] ## Author's thesis The failure mode that sinks small open-source projects is usually human, not technical — ego, undefined expectations, and burnout — so a maintainer opening a project to outside contribution should work through a people-first checklist (define goals, get an outside evaluation, drop the ego, define channels/templates/timelines, set explicit AI and CLA policies, build leadership beyond yourself, find a partner, protect your own energy) before recruiting contributors. ## Key arguments 1. Ego is the hardest and most decisive step: if a maintainer can't accept disagreement, opening the project for feedback "is going to go poorly." 2. Consistency, not speed, builds contributor trust — a reliably kept two-week reply window beats an unpredictable one-day-usually-but-not-always window. 3. AI and CLA policy should be explicit, decided-on-purpose artifacts, not ad hoc reactions to the first contentious PR or AI-assisted contribution. ## Claim atoms ### Open source surfaces more opinions than people > [!quote] ID:rw_h1 > "We know that there are more opinions than there are people most times. And we want those opinions because they're good for us." Opening framing — reframes "too many opinions" as the value of opening a project, not its cost. ### Ego is the hardest barrier to receiving feedback > [!quote] ID:rw_h2 > "You need to let go of your ego immediately... there are going to be people that come in and disagree with you with and without valid reasons for doing so." Named as the hardest step in the whole checklist; the gate before any of the others matter. ### Templates make contributor feedback consistent > [!quote] ID:rw_h3 > "Templates are going to be your friends. Use them everywhere that you possibly can." Mechanism: copy-paste-ready information structure produces consistent, usable reports from contributors. ## Permanent candidates - "Ego is the first blocker to opening a project for feedback" — promoted. - "Consistent reply timelines build trust more than fast ones" — promoted. ## Processing checklist - [ ] Verify whether AlmaLinux's no-CLA stance is documented publicly and why it fits their specific build model - [ ] Turn the checklist into a one-page worksheet for WordPress component leads - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — a direct, practical contributor-onboarding checklist. - [[3. Resources/MOCs/Commons & Community Governance MOC]] — bus-factor and leadership-distribution are commons-governance concerns beyond any single project.