step 28 / 32 · 5 min
Using and contributing to other people's code
Most of what you ship is code you did not write. Choosing it and contributing back are both ordinary parts of the job.
Choosing a dependency
Every library is a long term commitment: its bugs, its security issues, its maintenance, its breaking changes.
| Check | Why |
|---|---|
| Last commit, and recent releases | abandoned libraries do not get security fixes |
| Open issues, and whether they get answers | tells you what support looks like |
| Number of dependents | more eyes, and more scrutiny |
| Its own dependency tree | you inherit all of it |
| Licence | some are incompatible with commercial use |
| Size | for anything shipped to a browser |
And a real question before any of that: could this be twenty lines of your own? A dependency for a trivial function is a supply chain risk and an update treadmill for something you could have written and understood.
Licences, briefly
MIT, Apache 2.0, BSD: permissive. Use freely, keep the notice. Apache also grants patent rights, which is why companies prefer it.
GPL: copyleft. Distributing software that links it obliges you to release your source under the same terms. Fine for internal tools, a serious decision for a product.
AGPL: extends that obligation to software offered over a network, which closes the loophole GPL leaves for hosted services.
No licence at all: you do not have permission to use it. A public repository is not a grant.
Check before adopting, not after the product ships.
Contributing
The path in is smaller than people expect:
1. use it, and hit a real problem
2. search the issues; it may be known
3. read CONTRIBUTING.md, because every project has conventions
4. start small: documentation, a failing test, a clear bug report
5. discuss before building anything largeStep 5 saves the most pain. A large unsolicited pull request is often declined because it does not fit a direction the maintainer has in mind and has not written down.
What a good contribution looks like
One focused change. A test that fails before and passes after. A description saying what and why. Following the project's existing style rather than your preference. Patience, because maintainers are usually volunteers with a day job.
Why it is worth doing
It is public evidence of how you work, which is more persuasive to an employer than a claim on a CV. It is also how you learn to read unfamiliar code and accept review from strangers, which are the two skills a first job demands immediately.