How open source works

Licences, maintainers, contributing guides and codes of conduct. Most rejected first pull requests break a norm, not a test.

Also called license, OSI licence, SPDX

What: The legal terms that let anyone use, change and share a project's code. Licences approved by the Open Source Initiative meet the Open Source Definition and are named by short SPDX identifiers such as MIT.
Why: Without a licence, code is all rights reserved even if it is public. The licence decides whether companies can use it, how you can reuse it and what you must share back.

Watch out

Assuming a public GitHub repository with no LICENSE file is free to copy into your own project.

Also called MIT, Apache 2.0, BSD

What: A licence that allows almost any use, including in closed source products, as long as you keep the copyright notice. MIT, BSD and Apache 2.0 are the common ones; Apache 2.0 also grants patent rights.
Why: Permissive licences are the easiest for companies to adopt, which is why many libraries and frameworks use them.

Also called GPL, AGPL, LGPL, MPL

What: A licence requiring that modified versions you distribute are shared under the same licence. GPL is strong copyleft, LGPL and MPL are weaker, and AGPL also covers software offered over a network.
Why: Copyleft keeps improvements open. It matters when you combine code, because mixing it into a product can oblige you to publish your source.

Watch out

Copying GPL code into a permissively licensed or proprietary project without understanding the obligations.

What: The people who review and merge changes, triage issues, cut releases and set a project's direction. Many are volunteers doing it in spare time.
Why: Your pull request competes for their limited time. Contributions that are easy to review, follow the rules and respect their decisions get merged.

Watch out

Demanding a review or pinging maintainers daily when a pull request has waited a few days.

Also called BDFL, foundation

What: How a project makes decisions: a single lead (sometimes called a BDFL), a core team or steering committee, or a foundation such as the Apache Software Foundation, CNCF or Linux Foundation.
Why: It tells you who decides on features, how to propose bigger changes and how people become committers.

Also called CONTRIBUTING.md

What: A file, usually CONTRIBUTING.md, explaining how to set up the project, which issues to pick, coding style, tests to run, commit rules and how pull requests are reviewed.
Why: It is the rulebook maintainers expect you to read first. Following it is the quickest way to a smooth first review.

Watch out

Skipping it and opening a pull request against the wrong branch without tests or a linked issue.

Also called CODE_OF_CONDUCT.md, Contributor Covenant

What: A document setting expected behaviour in a project's spaces and how to report problems. Many projects adopt the Contributor Covenant.
Why: It keeps communities welcoming and gives maintainers a clear basis for acting on harassment or abuse.

Also called contributor licence agreement, developer certificate of origin, sign-off, CLA, DCO

What: Agreements some projects require before merging. A CLA grants the project rights over your contribution; a DCO is a lighter statement, added with git commit -s, that you have the right to submit the code.
Why: They protect the project legally. A missing signature or sign-off line is a common reason a bot blocks a first pull request.

What: Common reasons include fixing a bug that affects you, learning from experienced reviewers, building a public track record, and companies maintaining software they depend on.
Why: Knowing your own reason helps you pick the right project: one you use, in the stack you want to grow in.

Go deeper