How Linux is developed: patches, mailing lists and maintainers

In short: The Linux kernel arises in an open process with thousands of participants from companies and volunteers. All changes run as patches over mailing lists and maintainers; in the end Linus Torvalds decides on inclusion in the main version.

The path of a change

1. Someone writes a patch (a small, well-justified change) and checks it against the current code.
2. They send it by email to the responsible mailing list and the area’s maintainer (the file MAINTAINERS names them). A script (get_maintainer.pl) helps.
3. Others read along and answer with criticism. The patch is revised until it is fine. Confirmations appear as Reviewed-by: or Tested-by: in the text.
4. The maintainer takes it into their branch and passes collected changes to the next level.
5. In a merge window of two weeks Linus takes the branches into the main version. Then come pre-releases (rc1 to rc7 or rc8) with fixes only and then the release, see Kernel versions and release cycle.

Rules and culture

• Do not break existing programs (“don’t break userspace”).
• A patch must do one thing, described cleanly, with Signed-off-by: (confirms that you have the rights; the Developer Certificate of Origin).
• The tone has become friendlier in recent years; criticism of the code, not the person.

Taking part

Beginners start with spelling in documentation, small clean-up patches or testing release candidates. The Kernel Newbies project helps. For the Rust part see Rust and eBPF in the Linux kernel.

See also: Open-source licences: GPL, MIT and Apache, History of Linux and GNU