The economics of free software work
Nobody pays you to fix bugs at midnight, so the currency must be something else. Skills, reputation, and access — honestly accounted.
By Nzubechukwu Cyprian · Pharmacy student at UNN, full-stack developer

Open source work is unpaid by definition, which means every contributor is running an economy of one. Mine includes no delusions: I can't pay rent with merged PRs. So what am I actually earning? An honest accounting.
The real currencies
Skills you can't buy. Review from a senior maintainer on your patch is a code review you could never schedule. Contributing compresses years of "how real software is run" into months.
Reputation that travels. A merged PR in a known project is a verifiable work sample — timestamps, code, collaboration style, all public. No interview claim can match that evidence.
Access. Contributors get into conversations — design discussions, maintainer channels, conference rooms — that outsiders don't see. Careers have pivoted on being the person who fixed an annoying bug thoroughly.
Leverage on tools you use. Every patch to a library I depend on is a patch to my own stack. Self-interest is a legitimate fuel.
The costs, honestly
Time — the obvious one. And emotional exposure: public criticism of your code is a real tax on beginners.
The balance I strike
Contribute where the four currencies overlap: tools I use, maintainers I can learn from, projects whose reputation I want to share. Everything else is charity work — good, but budgeted.
One email when a post lands
No schedule, no spam. Just the posts worth reading — new writing on software, AI, products, and the Pharmacy × Tech life.
Prefer a feed reader? Grab the RSS feed.
Keep reading
Open sourceYour first open source contribution doesn't need code
Docs, reproduction steps, and tested bug reports are contributions. The barrier you imagine is lower than the one that exists.
Open sourceReading the issue tracker: the skill nobody teaches
Issue trackers are where projects tell the truth. Learning to read them well reveals what to contribute and what to avoid.
Open sourceThe anatomy of a pull request that gets merged
Small scope, clean description, tests, and the maintainer's style. What separates merged PRs from the ones that die open.