How do you participate in — and help sustain — open source?
Your progress in this module0%
0 of 10 steps · 0 of 1 Compass Challenges complete
Step 1 · Learn
How do you participate in — and help sustain — open source?
Start as a contributor, learn how maintainers think, then learn the strategy and legal context. By the end you should be comfortable making contributions, running a small project, and advising a team on open source decisions.
Topic 1 of 9
Contributing Code & Documentation
Contributions don't have to be code. Docs fixes, examples, tests, bug reproductions and translations are often the most valuable, and the easiest place to start.
A respectful contribution workflow:
Read CONTRIBUTING.md and the code of conduct. Follow the project's conventions.
Find or open an issue first for anything beyond a typo, and confirm the change is wanted.
Fork, branch, make a small, focused change. One concern per PR.
Test it and follow formatting and lint rules.
Write a clear PR description: what, why, how tested, and a link to the issue.
Respond to review graciously and promptly. Reviews are how you learn the codebase.
Never open low-effort or AI-generated "drive-by" PRs to farm contributions. Maintainers notice, and it harms both the project and your reputation.
Key takeaways
Docs, tests and reproductions are valuable contributions
Read CONTRIBUTING, discuss first, keep PRs small
Respect maintainers’ time — no low-effort drive-by PRs
A tidy issue tracker is a public signal of project health. An overgrown one tells people the project is abandoned, even when it isn't.
Triage practices:
Label consistently: type (bug, feature, docs, question), area, priority and status (needs-repro, needs-info, accepted), plus "good first issue" and "help wanted".
Regular triage sessions: weekly, work through new issues: reproduce, label, deduplicate and route.
Close with care: stale, duplicate or out-of-scope issues get a kind explanation and a link.
Move questions to Discussions or forums so issues stay actionable.
Milestones or projects to show what's planned.
Triage is one of the best ways to contribute to a project you care about, and to learn it deeply. Many maintainers started as triagers.
Good first issues are the onboarding ramp for new contributors. Done well, they turn users into contributors; done badly, they frustrate everyone.
A good "good first issue":
Is small and well-scoped: achievable in a few hours
Includes context: what's wrong, where in the code to look and what "done" means
Links to setup instructions and relevant docs
Has a mentor: someone who'll respond to questions and review quickly
Is genuinely useful, not busywork
Keep a steady supply, label them consistently (so sites like goodfirstissue.dev find them), and consider reserving some for first-time contributors only. Celebrate first contributions publicly; it's powerful recognition.
Key takeaways
Small, scoped, with context and a clear definition of done
Governance defines who makes decisions and how. It matters most when people disagree or when a project outgrows its founders.
Common models:
BDFL (Benevolent Dictator For Life): one person has final say. Simple, and common in early projects.
Meritocracy / committers: contributors earn commit rights and decision power through sustained contribution (the Apache model).
Liberal contribution / consensus: decisions are made by the people doing the work, via consensus or voting.
Company-led: a single company controls direction. Transparency about this matters for trust.
Foundation-hosted: a neutral foundation (Apache, CNCF, OpenJS, Linux Foundation) holds trademarks and provides governance processes, which signals neutrality to other companies.
Document governance in a GOVERNANCE.md: roles, how decisions are made, how people gain and lose roles, and how conflicts are resolved.
Key takeaways
BDFL, meritocracy, consensus, company-led and foundation models
Foundations signal neutrality to other contributors
Companies open source software for different reasons, and the reason should shape how they do it:
Adoption: remove barriers so developers try and embed the technology (open core, SDKs, CLIs)
Ecosystem: create a standard others build on
Recruiting and brand: show engineering quality and culture
Collaboration: share maintenance of commodity infrastructure with others
Trust and transparency: let users inspect security-sensitive code
Key questions before open sourcing: What's the goal and how will you measure it? Who will maintain it long-term? What's the business model (open core, hosted service, support)? What license? Will you accept outside contributions?
Many companies run an OSPO (Open Source Program Office) to handle policy, compliance and strategy. The TODO Group publishes excellent OSPO guides. DevRel often partners with the OSPO on community and adoption.
Key takeaways
Know the goal: adoption, ecosystem, brand, collaboration or trust
Plan maintenance, business model and license up front
OSPOs coordinate company open source — partner with them
You don't need to be a lawyer, but you do need to explain licenses accurately, and know when to call a lawyer.
The main families:
Permissive (MIT, Apache 2.0, BSD): use, modify and redistribute, including in proprietary software, with attribution. Apache 2.0 adds an explicit patent grant.
Copyleft (GPL, AGPL, LGPL, MPL): derivatives must be released under the same license when distributed (AGPL extends this to network use). Strength varies. LGPL and MPL are weaker copyleft.
Source-available (BSL, SSPL, Elastic License): code is visible but with restrictions, often on competing hosted services. These are not OSI-approved open source licenses, and changes to them can upset communities.
Other essentials: a CLA or DCO for contributions, trademark policy separate from code license, and checking dependency licenses for compatibility. Use choosealicense.com and the OSI list, and involve legal counsel for company decisions.
Key takeaways
Permissive vs copyleft vs source-available — know the differences
Source-available licenses are not OSI open source
CLAs/DCOs, trademarks and dependency licenses matter; involve legal
Done well, open source is one of DevRel's most powerful levers:
Credibility: contributions are public proof that you build and understand the ecosystem.
Relationships: maintainers and contributors become peers, collaborators and advocates.
Integrations: contributing integrations to popular projects puts your product where developers already work.
Content: real-world contributions become talks, posts and case studies.
Feedback: issues and discussions are unfiltered signal about developer needs.
The key is giving before taking. Contribute to the ecosystem your developers use, not only your company's repos. Sponsor maintainers, fix docs and help triage. The trust you build is what makes your company's projects welcome later.
Key takeaways
Public contributions are proof of credibility
Integrations put you where developers already work
Give before taking — contribute to the wider ecosystem
Land your first meaningful open source contribution
The prompt
Get a pull request merged into an open source project you (or your target audience) use. Docs, tests, examples or code all count, as long as it's genuinely useful. Then write a short post about the experience: how you found the issue, what you learned and how the maintainers helped.
The template
## PR description template
**What:** <one-line summary of the change>
**Why:** Fixes #<issue> — <the problem it solves>
**How:** <approach, any trade-offs>
**Testing:** <how you verified it — commands, screenshots>
**Checklist:**
- [ ] Follows CONTRIBUTING.md
- [ ] Tests added/updated
- [ ] Docs updated
— — —
## Post: "My first contribution to <project>"
- How I chose the project and issue
- Getting set up (what was hard)
- The change and the review
- What I learned
- Link to the merged PR