You find a project on GitHub with a promising issue labelled "good first issue", spend a weekend writing a patch, open the pull request — and then nothing happens. Two weeks later a maintainer closes it with one line: "This changes behaviour we rely on." You did the work, the code was clean, and you still lost. Why?
That gap — between writing code and getting code accepted — is what Open Source Contribution is really about. Not git commands (those you can learn in an evening), but the social and technical machinery around a shared codebase: who decides, how decisions are recorded, what a licence permits, and why some PRs sail through while better ones die in review.
Below is what that machinery looks like from the inside, where it breaks, and how people actually learn to work with it.
What is actually happening when you contribute
An open source project is a governance structure disguised as a repository. The code is the visible part. What governs whether your change lands is: the maintainer's time budget, the project's compatibility promises, the CI pipeline, and the licence that determines who may legally use the result.
That's why the same patch can be welcome in one project and rejected in another. A small library with one maintainer who merges within a day has an entirely different decision process from a project with a release train, a deprecation policy, and three reviewers who must all approve.
A practical consequence: before you write a line, read the CONTRIBUTING.md, the last twenty merged PRs, and the issue thread. If you have ever worked with CI/CD pipelines, you already know why — a red pipeline is not a small annoyance, it's the maintainer's first filter.
A walkthrough: fixing a bug in a library you use
Take a concrete case. You use a date-parsing library and hit a bug: parsing the string 2026-02-30 returns a valid date instead of an error. Here's how a practitioner handles it, and what breaks at each step if done differently.
1. Reproduce before you touch anything. Write the smallest failing case. If you can't reproduce it on the current main branch, the bug may already be fixed or may live in your usage, not the library. Skipping this step is the most common cause of a wasted weekend.
2. Search the issue tracker. Someone may have reported it. If yes, comment with your reproduction — that's a contribution too, and it saves the maintainer triage time. If no, open an issue describing the input, the expected output, and the actual output. Do not open a PR before the issue is acknowledged in projects with active maintainers; you may be solving a problem they've decided to solve differently.
3. Read the test suite. Find where date validation is tested. Your fix should come with a test that fails before your change and passes after. A PR without a test in a project that has tests is usually sent back.
4. Make the change minimal. One logical change per PR. If you notice a typo nearby, fix it in a separate PR. Reviewers can hold a large diff for weeks because reviewing it costs more than rewriting it.
5. Run the project's checks locally. Linters, formatters, the full test suite. A pipeline that goes red on formatting tells the maintainer you didn't read the setup docs.
6. Write the PR description for a stranger. What problem, what approach, what you deliberately did not change, and any compatibility risk. This is where most first-time contributors lose — the code is fine, the description says "fixes bug", and the reviewer has to reverse-engineer your intent.
7. Expect review, not approval. Respond to comments with changes or with reasoning. Silence is not rejection; maintainers are volunteers with day jobs.
What breaks if you reorder this? Opening a PR first and an issue later often produces a rejected PR plus a duplicate issue. Skipping the test means the change gets merged and later reverted when it breaks something else — and a revert is much harder to recover from than a delayed merge.
Where the scheme itself breaks
These aren't beginner mistakes. They're structural failures of open source as a model — conditions that changed, rules that stopped applying.
The maintainer disappears
A project looks alive: stars, forks, recent issues. But the last merge was fourteen months ago. Spot it early: check the commit history on the default branch, not the star count. Look at whether issues get responses. If maintainers have gone quiet, your PR will sit forever regardless of quality.
If it's already too late: fork it, or find a maintained fork. Legally you can, thanks to the licence — see below. Practically, you're now maintaining your own version, which is a different commitment entirely.
The licence changes the deal under you
A project under a permissive licence can add restrictions in a later release. Your company may have adopted a version whose terms no longer match what you assumed. Spot it early: read the LICENSE file and check whether the project has a contributor licence agreement (CLA) — a document you sign before your contribution can be merged, which sometimes assigns or licenses your copyright to the project owner.
If it's already too late: you can keep using the old version under the old terms, but you can't un-contribute. This is why reading the CLA before your first PR matters more than reading it before your tenth.
The "good first issue" is a trap
Labels age. An issue marked beginner-friendly two years ago may now sit on top of a refactor that changed everything. Spot it early: check whether the issue has recent comments and whether the referenced files still exist in the current code.
If it's already too late: comment on the issue asking whether it's still current, and offer your work as a starting point rather than a finished PR. Maintainers usually appreciate it.
Your contribution conflicts with a direction already decided
A roadmap decision made in a discussion thread six months ago means your feature is out of scope — permanently. Spot it early: search closed PRs and discussions for your idea before building it. If it's already too late: the honest move is to publish your change as a small standalone package or plugin, and tell the maintainers it exists. That's a legitimate outcome, not a failure.
Licences: the part everyone skips and later regrets
Licences are not legal decoration. They determine what your employer can do with the code, and what you can do with a fork.
| Licence family | What it typically allows | Where it bites |
|---|---|---|
| Permissive (MIT, Apache-2.0, BSD) | Use, modify, redistribute, often commercially, with attribution | Apache-2.0 adds an explicit patent grant; MIT does not address patents at all |
| Copyleft (GPL family) | Use and modify, but distributed derivatives must carry the same licence | Embedding in a closed product can trigger obligations you didn't plan for |
| Weak copyleft (LGPL, MPL) | Derivative files must stay open, but linking from proprietary code is generally permitted | The boundary of "derivative" is where disputes start |
Two practical notes. First, the licence of the project you contribute to does not automatically cover your employer's use of your own code — that's a separate question your employment contract may answer. Second, if you're choosing a licence for a project you're starting, the decision is about what you want others to be able to do, not about which licence sounds professional.
This is the same class of reasoning as reading a standard carefully before relying on it — the same discipline that technical writers apply to specifications, and that anyone working with Observability in Production applies to metrics: the meaning is in the details, not the label.
Growing from contributor to maintainer
The transition isn't a promotion; it's a change of work. As a contributor you optimise for a merged PR. As a maintainer you optimise for not being the bottleneck — which means reviewing others' work, writing release notes, deciding what to reject, and documenting decisions so you don't have to repeat them.
The non-obvious part: the skills that make you a good contributor actively work against you as a maintainer. A contributor writes minimal, focused changes. A maintainer has to think about compatibility across versions, deprecation timelines, and whether a change will create support burden for years. Many first-time maintainers burn out because they keep reviewing as if they were still contributing.
Community building follows the same logic. A project grows not through announcements but through a visible, predictable process: how issues are triaged, how long reviews take, what counts as a welcome contribution. Predictability is the recruitment tool.
How people actually learn this — and what each path costs
Honest comparison, because the trade-offs are real:
Self-study by contributing directly. Cost: zero money, high time. You learn by making mistakes in public. The problem is feedback latency — a rejected PR teaches you something, but you may wait two weeks to learn it, and you may misread why it was rejected. Without someone checking your reasoning, wrong lessons stick.
Reading guides and documentation. Cheap and fast, but it teaches the rules, not the judgment. Knowing that a CLA exists doesn't tell you whether to sign one for a given project.
Structured courses. Cost: money and scheduled time. Gain: feedback on your actual decisions — the PR description, the licence reasoning, the triage call — before you spend three weeks finding out the hard way. The Open Source Contribution course on asibiont.com is built around exactly that: licences, CI for open source, code review, release management, and community work, with lessons adapted to your level. It's one route among several, not the only one.
Contributing inside a company's open source program. The best feedback loop if it exists — you get paid time and internal review. It doesn't exist for most people starting out.
A rough rule: if you have a project you already use daily and a maintainer who responds within days, self-study works. If you're choosing a project from scratch and can't tell a healthy one from an abandoned one, structured feedback saves you months.
Who this suits, and who it doesn't
This path suits people who can tolerate asynchronous, delayed feedback and who are willing to read before writing. It rewards patience and clear writing as much as coding skill — arguably more.
It does not suit anyone expecting a fast, deterministic outcome. Open source runs on volunteers' spare hours; your timeline is not the project's timeline. It's also a poor fit if you need a guaranteed merge for a deadline — for that, a fork or an internal project is the honest choice.
If you've read this far and recognised your own rejected PR in the walkthrough, you already have the right instincts. The next step is getting your reasoning checked by someone who does this for a living rather than guessing at it alone. The Open Source Contribution course walks through licences, review and release work with concrete examples and gives you feedback on your decisions — start with the project-selection section if you're unsure where to begin.