What Is Open Source Software? Explaining Licences, Contributions and Community
Every time you open a browser, check a notification or run a command in a terminal, there is a good chance you are using software that someone built, gave away, and then trusted strangers to improve. Open source is not a marketing label or a licence to extract free labour. It is a set of legal permissions, a way of working, and a community that has to be maintained as carefully as the code itself.
What "open source" actually means
Open source software is software whose source code — the human-readable instructions behind the program — is published under a licence that grants everyone specific rights. The Open Source Initiative, which has been certifying licences since the late 1990s, treats a licence as open source only if it allows free redistribution, access to the source, modification and derived works, without discriminating against people or fields of use. Those conditions matter more than whether the code sits on a public website.
Plenty of projects publish their code but restrict what you may do with it. "Source-available" is not the same thing. If a licence forbids commercial use, caps the number of users, or requires you to ask permission before shipping a modified version, the project is not open source in any useful sense — even if the repository is public and the issue tracker is busy.
Note also that "free" refers to freedom, not price. Companies sell support, hosting and managed versions of open source software all the time. That is allowed, and it is often how the work gets funded.
Permissive and copyleft licences
Most licences you meet fall into two families. The difference comes down to what happens when you redistribute the code, especially inside a product you do not want to open up.
Permissive licences
MIT, BSD and Apache 2.0 are the common ones. They let you use, modify and redistribute the code, including in closed-source products, provided you keep the copyright notice and the licence text, and accept that there is no warranty. Apache 2.0 adds an explicit patent grant, which some organisations prefer for that reason. If you want to build something proprietary on top of an existing library, permissive licences are usually the straightforward route.
Copyleft licences
The GNU General Public License and its relatives work differently. If you distribute a modified version of GPL code, you must generally release your version under the same licence, with the source available. The Affero GPL extends this to software offered over a network, closing the "run it as a service" loophole. Weaker copyleft licences such as the Mozilla Public License apply the requirement file by file rather than to the whole program, which is why they are popular for libraries.
Copyleft is not anti-commercial. It is a deliberate choice to keep improvements in the commons. Still, licence compatibility is genuinely fiddly, and mixing licences can create obligations you did not intend. If you are shipping a commercial product, have someone qualified review your dependencies before release — this is not a decision to make from a blog post.
How a project is actually run
A repository is not a democracy by default. Most projects have maintainers who decide what gets merged, and the shape of that authority varies. Some have a single founder with the final say. Some are governed by a committee, a foundation, or a company that employs the core team. Others are quiet, with two or three people reviewing pull requests in their evenings.
That last point is worth sitting with. Many widely used packages are maintained by a handful of volunteers, which is why "bus factor" — how much would break if one person stepped away — comes up so often in conversations about supply chains and security. When you adopt a dependency, look at how releases are managed, whether security reports get answered, and whether more than one person is active. Funding usually arrives through donations, sponsorship or employers paying staff to work on it; none of that is guaranteed.
Contributing responsibly
Good contributions are rarely about writing the cleverest code. They are about reducing the maintainer's workload and fitting in with how the project already works.
- Read the front door. CONTRIBUTING.md, the README and the code of conduct explain the ground rules. Skipping them is the fastest way to have a pull request closed.
- Start small. Documentation fixes, clearer error messages and reproducible bug reports are genuinely valuable. Many projects label approachable issues as "good first issue".
- Talk before you build. Open an issue describing what you plan to change and why. It saves you a weekend of work on something that will not be merged.
- Keep changes focused. One pull request, one purpose. Reformatting a whole file alongside a bug fix makes review painful.
- Match the project's style. Tests, commit messages, formatting and documentation all have conventions. Follow the existing ones rather than your own preferences.
- Take review feedback well. A request for changes is normal. Ask questions when you disagree, but accept that the maintainer decides.
The same manners apply in issues. A bug report that includes your version, your operating system, exact steps and the full error message will be fixed far sooner than "it doesn't work". Remember that the person reading it is probably unpaid and quite tired.
Making your first contribution stick
Pick a tool you already use and understand, not the largest project you can find. Spend an evening reading its issue tracker to learn what people struggle with. Fix a typo in the documentation, rewrite an unclear paragraph, or reproduce a reported bug and add the details the maintainer is missing. Submit it, then wait a few days before chasing.
Once that lands, you have a relationship. Ask whether there is an area that needs help, offer to review other people's changes, and keep showing up occasionally. That is how contributors become maintainers, and how projects outlive the enthusiasm of the week they were started in.
Photo: Daniil Komov / Pexels
