Open Source

Software with source code that is publicly available and licensed to allow use, study, modification, and redistribution. The opposite of proprietary/closed-source software. "Free software" (FSF) and "open source" (OSI) overlap significantly but emphasise different values: freedom vs. practical benefits.

"Linux is open source — you can read every line of the kernel source code, compile it yourself, modify it for your specific hardware, and redistribute your modified version. This is why it powers 97% of the world's top web servers."

The legal terms under which open source code may be used, modified, and distributed. Key families: permissive (MIT, Apache 2.0, BSD — do almost anything, just keep the attribution) and copyleft (GPL, LGPL — derivative works must also be open source). Choosing the wrong license for a dependency can have legal consequences.

"Check the license before adding a dependency — a GPL-licensed library requires you to open-source your entire application if you distribute it. That's fine for open source projects but incompatible with our proprietary product. We use MIT or Apache 2.0 licensed libraries only."

Creating your own copy of a repository (on GitHub) under your own account. Used to: contribute to projects where you don't have write access (fork → change → pull request), start a new project based on an existing codebase, or when the community disagrees with the original direction and moves independently.

"I forked the markdown parser library to add the syntax highlighting feature our docs site needs. Once I've tested it, I'll open a pull request upstream — if they merge it, I can stop maintaining the fork."

A proposal to merge changes from one branch (usually in a fork) into the main repository. The PR includes a description of the changes, the diff, automated CI results, and a discussion thread for review. Accepted PRs are merged; rejected PRs are closed with feedback.

"Before opening the PR, I read the CONTRIBUTING.md — it required me to add a test for the new behaviour, update the CHANGELOG, and run the full test suite locally. Following the contribution guide is how you get PRs merged quickly."

A tracked item in a project repository representing a bug, feature request, question, or task. Issues are the primary communication channel between users and maintainers. A good bug report issue includes: steps to reproduce, expected behaviour, actual behaviour, environment details.

"When you find a bug, open an issue before submitting a PR — maintainers may have context you don't (it's a known issue being redesigned, or it's intentional behaviour). Opening an issue first saves you from submitting a PR that will be rejected."

A person with write access to an open source repository who reviews contributions, manages releases, sets project direction, and maintains the health of the codebase and community. Maintainership is largely volunteer work and can be demanding. Burn-out among maintainers is a recognised problem in OSS.

"Before filing an issue about response time, check if the maintainer has stated their bandwidth — the README said responses may take 2–4 weeks. Maintainers are often unpaid volunteers managing hundreds of outstanding issues."

Anyone who contributes to an open source project: code (bug fixes, features), documentation, translations, issue triage, design, or community support. The first contribution is often the hardest — maintainers typically label beginner-friendly issues with "good first issue" or "help wanted".

"I became a contributor by fixing a typo in the documentation first — low-risk, high-welcome. The maintainer reviewed and merged it in minutes. That built my confidence to tackle a 'good first issue' on the actual code."

A file in an open source repository that explains how to contribute: code style, branch naming, commit format, testing requirements, PR process, and communication norms. Reading CONTRIBUTING.md before submitting a PR is essential — ignoring it is the most common reason PRs are rejected or ignored.

"The CONTRIBUTING.md required all PRs to reference an open issue and include a test case. I had submitted the PR without either — the maintainer closed it with a polite explanation. I re-opened it correctly and it was merged within two days."

A document defining expected behaviour in a community and what is not acceptable — harassment, discrimination, aggressive communication. Most open source projects adopt the Contributor Covenant. Violations are reported to maintainers. A Code of Conduct makes communities safer and more welcoming, especially for underrepresented groups.

"The project's Code of Conduct was violated when a maintainer made dismissive comments about a contributor's PR. The community raised it with the project lead, who issued a public apology. The Code of Conduct defined the process and outcome clearly."

A versioning scheme: MAJOR.MINOR.PATCH (e.g., 2.4.1). MAJOR: breaking changes (API removed, behaviour changed). MINOR: new features, backward compatible. PATCH: bug fixes, backward compatible. Pre-release: 1.0.0-alpha, 1.0.0-beta. Release candidate: 1.0.0-rc.1.

"We bumped from 1.9.3 to 2.0.0 because we removed the deprecated `doTheThing()` API. Anyone upgrading from v1 to v2 will see a breaking change. Our CHANGELOG documents the migration path from the old API to the replacement."

A file documenting all notable changes to a project, organised by version. The standard format (keepachangelog.com) groups changes by version with categories: Added, Changed, Deprecated, Removed, Fixed, Security. Users consult the CHANGELOG before upgrading.

"Before upgrading the authentication library, I checked the CHANGELOG for v3.0.0 — under 'Removed' it listed the `verify()` method we use. That's a breaking change we need to handle before upgrading. Without the CHANGELOG this would appear as a mysterious production error."

Upstream: the original project that a fork or dependent project is based on. Downstream: a project that depends on, forks, or derives from another. Upstream changes must be merged downstream to stay current. Contributing a fix upstream benefits all downstream users.

"We've patched the bug in our fork, but we should contribute it upstream — if the upstream project includes the fix, all downstream users get it automatically and we don't have to maintain our own fork permanently."

A situation where two branches have made conflicting changes to the same part of a file, and Git cannot automatically combine them. The developer must manually choose which changes to keep (or combine both). Denoted in the file with conflict markers: <<<<<<, =======, >>>>>>>.

"The merge conflict occurred because I changed the default timeout on line 45, and the main branch changed the same line to a different value. I opened the file, reviewed both changes, and wrote a new version that incorporated both teams' intentions."

User-facing documentation published alongside a software release describing what changed: new features, bug fixes, breaking changes, known issues, upgrade instructions. Different from a CHANGELOG (developer-focused) — release notes are written for users and operators who need to decide whether and how to upgrade.

"The release notes for v4.0 warned about a 2-minute database migration that runs automatically on first startup — operators needed to schedule a maintenance window. Without reading the release notes, they would have been surprised by unexpected downtime."

The minimum number of project members who would need to be struck by a bus (or leave the project) for it to become unmaintainable. A bus factor of 1 means only one person understands the codebase — extremely risky. Healthy projects spread knowledge broadly to increase the bus factor.

"The authentication module has a bus factor of 1 — only Maya understands it. She's going on parental leave in two months. We've scheduled knowledge transfer sessions and she's documenting the architecture to raise the bus factor to at least 3."

A document proposing a significant change to a project — new feature, API redesign, breaking change, architectural shift. Published to solicit community feedback before implementation begins. RFCs ensure large changes are discussed openly and all perspectives are considered. Used by Rust, Ember, React, and many other projects.

"Instead of opening a PR directly with the new plugin API, we wrote an RFC first — it described the problem, the proposed design, alternatives considered, and open questions. After 6 weeks of community discussion, we had much better design insights before writing any code."