How Software Actually Gets Made

Section 01The download button hides a lot of work

When you click a download link for a piece of software, you receive a finished thing: an installer, a package, a binary. Behind that lies months or years of small decisions made by people who will never know your name. Understanding even the outline of that process changes how you think about software — why updates matter, why a project can stall, why one program is trusted more than another.

Most software, open-source or proprietary, is built through a rough sequence of the same steps: writing code, tracking changes, reviewing those changes, assembling a release, and then doing it again. Each step involves tools and conventions that have become so standardised that developers across different countries, languages and time zones can collaborate without ever meeting.

Section 02Code is written in layers, and every change is recorded

Developers write source code in plain text — instructions addressed to a compiler or interpreter, not to a human reader, though the best code tries to be both. No one writes a finished program in one sitting. The process is iterative: a small change, a test, another small change. That cycle repeats thousands of times before any user sees a result.

The tool that makes collaboration possible at scale is version control. A version control system records every change to every file, along with who made it and when. If a change breaks something, you can trace exactly where it was introduced and undo it. If two developers modify the same file at the same time, the system can often merge their changes automatically — and flags the conflicts it cannot resolve for a human to sort out.

Git, created by Linus Torvalds in 2005 to manage the Linux kernel's development, became the dominant version control system and remains so. Platforms built on top of Git — the most widely used being GitHub, acquired by Microsoft in 2018, and the independently run GitLab — turned version control into something more like a social workspace. Code lives in repositories. A repository holds not just the source files but the entire history of the project: every revision, every discussion thread attached to a proposed change, every reported bug.

If a change breaks something, you can trace exactly where it was introduced and undo it.

Developers propose changes through a mechanism called a pull request (on GitHub) or merge request (on GitLab). You write your change in a separate branch — a parallel copy of the code — and then ask the project maintainers to review it and pull it into the main codebase. That review process is where a great deal of the actual quality control happens.

Section 03Review, testing and the long road to a release

A code review is exactly what it sounds like: another developer reads your proposed change and asks questions, spots problems, suggests improvements. In a well-run open-source project, nothing lands in the main codebase without at least one other person having read it carefully. That reviewer is looking for correctness, security implications, whether the change fits the project's existing style and structure, and whether it does what it claims to do.

Alongside human review, most serious projects run automated testing. A test suite is a collection of small programs that each check one specific thing — does this function return the right answer when given this input? When a proposed change arrives, an automated system runs the entire test suite against it and reports whether anything broke. The Apache Software Foundation, which stewards dozens of widely used projects, makes automated testing a requirement of its development process. The Free Software Foundation and the Open Source Initiative have both long emphasised that open development practices, including peer review, are part of what gives free and open-source software its character — not just the licence, but the process.

Testing doesn't catch everything. A test suite only checks what someone thought to test for. Security vulnerabilities in particular often lurk in edge cases no one anticipated. But a project with a good test suite is meaningfully more reliable than one without, and the tests themselves are documentation of intent: this is what we think this code should do.

Once a body of changes has been reviewed, tested and accepted, maintainers begin preparing a release. This is its own kind of work. Release candidates — trial versions — are often published for testing before the final version is announced. Changelogs are written, listing what changed and why. Binary packages are compiled for different operating systems: the same source code must often be built separately for Windows, macOS, various Linux distributions, and sometimes different processor architectures. Each of those builds is a potential point of failure, which is why packaging the same program differently can produce subtly different results in practice.

Section 04What a maintainer actually does

The word "maintainer" describes someone with commit access — the authority to accept changes into the project. Maintainers review contributions, manage the release process, respond to bug reports, make decisions about which direction the project takes, and handle the administrative work that surrounds all of it. On a large project, this role is shared among many people. On a small one, it may fall to a single person, often working in their spare time.

The weight of that role is easy to underestimate. A popular open-source library might be downloaded millions of times a week and depended upon by software its maintainer has never heard of. The maintainer still answers issue reports, still reviews pull requests, still decides whether a proposed change introduces a risk. If they stop, the project goes quiet — and sometimes the projects that quietly stop are the ones that infrastructure quietly depended on.

How a project is governed matters as much as how the code is written. Some projects are formally steered by a foundation — the Apache Software Foundation, for instance, has a structured process for how decisions get made and how new committers earn trust. Others are maintained by a company that releases the code publicly. Others still are pure volunteer efforts, where authority tends to belong to whoever has been around longest and done the most.

None of these arrangements is inherently superior. A foundation-backed project has stability and process; it may also move slowly. A solo maintainer can ship changes fast; they can also burn out or simply disappear. Before you build something on top of a piece of software — or even just rely on it for daily work — it is worth spending a few minutes looking at whether the project has active maintainers, a recent commit history and a pattern of responding to reported problems. The download button tells you nothing about any of this. The repository tells you most of it.