Open Source

Open source is the foundation of modern software — the languages, frameworks, databases, and tools you use every day are overwhelmingly open source, built and maintained in public by communities of contributors. Engaging with it, whether by contributing to projects or building your own, is one of the most rewarding things a developer can do: it grows your skills, builds your reputation, connects you to communities, and gives back to the ecosystem you depend on.

This hub covers both sides of the relationship — contributing to projects (and the licensing you need to understand to do it safely) and building and sustaining your own (the community and maintainer work that determines whether a project thrives).

TL;DR

Two Sides of Open Source

Featured Topics

Contributing to Open Source

Licensing

Community Management

Building OSS Projects

Common Questions

How do I get started with open source?

The easiest entry is contributing to a project you already use: read its CONTRIBUTING.md, look for good first issue labels, and start small — a documentation fix is a perfect first contribution that teaches the fork → branch → PR workflow without deep code changes. Remember that contributions go far beyond code: docs, bug reports, tests, and triage are all valued. The goal of your first few contributions is to learn the process and build confidence; momentum comes from a series of small, accepted contributions. See Contributing to Open Source.

Why does the license matter so much?

Because the license determines what anyone — including you — may legally do with the code. The most important fact: code with no license is not open source — default copyright applies and no one has permission to use it, even if it's public on GitHub. Beyond that, permissive licenses (MIT, Apache) let you use code freely including in commercial products, while copyleft licenses (GPL) require derivatives to stay open. Before using a dependency or contributing to a project, know its license; before publishing your own, add one. The license is what makes "open" actually open.

What does it take to run a successful open-source project?

Mostly the non-code work. Beyond good code, a project needs a clear README, a license, documentation (which is the project for most users), a contribution process, and reliable releases. Then it needs ongoing maintainership — triaging issues, reviewing PRs kindly, cutting releases, and tending the community — which is the harder, continuous half. Most projects fail not because the code is bad but because nobody can figure out how to use them, or the sole maintainer burns out. See Building OSS Projects.

How do I avoid maintainer burnout?

Set boundaries and share the load. Most maintainers are unpaid volunteers, and you don't owe anyone instant responses or unbounded support. Grow co-maintainers so the project doesn't depend on one person (a bus factor of one is dangerous), automate repetitive work with CI and templates, pursue funding (GitHub Sponsors, Open Collective), and be honest about a project's status — marking it "maintenance mode" is far better than silently letting issues rot. A sustainable maintainer helps a project far more than a heroic, exhausted one. See Community Management.

Related Hubs