The Linux kernel repository: a guided map for nine kinds of contributors
The Linux kernel source tree: the core of every Linux operating system, managing hardware and system resources and providing fundamental services for all other software.
At a glance
- What is it?
- The torvalds/linux repository is the source tree for the Linux kernel. Its README is not a code tutorial but a role-based index to documentation, and that structure reveals who the project expects to be reading it.
- Who is it for?
- Adopt this repository if you are writing kernel code, maintaining a distribution, or studying kernel internals, because the README gives you a direct path to the exact documentation set for your role. Do not adopt it if you expect a quick-start guide or a self-contained tutorial, because the README is an index, not a manual, and every real task sends you to a separate file.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What this repository actually is
The README's most striking feature is its explicit role-based structure. It divides readers into nine categories: new kernel developer, academic researcher, security expert, backport/maintenance engineer, system administrator, maintainer, hardware vendor, distribution maintainer, and AI coding assistant. Each category gets a short list of documentation links. This is not a typical open source README, which usually gives a build command and a feature list. Here the build command is buried inside a link to Documentation/admin-guide/quickly-build-trimmed-linux.rst. The design choice is clear: the kernel is too large and too varied for a single overview, so the README routes you to the relevant subdocumentation. That is a sensible trade-off, but it means the README is useless if you ignore the links.
The documentation map and what it reveals
The documentation list is not exhaustive, and it does not pretend to be. It omits many subsystems, like the GPU stack or the audio subsystem, and it does not mention the tools/ directory or the scripts that maintainers use. That is a limitation of the README, not of the kernel itself. If you are a hardware vendor writing a driver for a niche device, the README gives you the driver API guide and the device tree bindings, but it does not tell you which mailing list to use for your specific bus type. You have to find that in the MAINTAINERS file, which the README mentions only in passing. So the README is a first step, not a complete map.
How to get it running: build and documentation commands
The lack of a direct 'make defconfig' or 'make -j' command in the README is a deliberate choice. The kernel build has many configuration options and hardware-specific quirks, so a one-line command would be misleading. The trimmed build guide exists precisely to handle that complexity. If you are a distribution maintainer, the README points to kconfig.rst and module-signing.rst, which are more relevant to your packaging work than a generic build command. So the README's approach is to send you to the right specialist document rather than give you a false sense of simplicity.
The AI coding assistant requirement and its implications
The inclusion of this section also tells you something about the project's governance. The kernel has a formal process for every kind of contribution, and AI tools are no exception. The README does not say what happens if an AI tool violates the rule, but the existence of the documentation implies there are consequences. This is a useful data point for anyone evaluating whether to use AI-assisted development on this project. The answer is yes, but with strict constraints.
Where the README is thin: limitations and wrong-tool cases
Another limitation is the lack of any troubleshooting guidance. The README does not tell you what to do if a build fails or a patch is rejected. It points to reporting-issues.rst for bugs, but that file is not in the README's main list. So a new contributor who hits a problem has to find the right file on their own. The kernel community is known for being harsh to newcomers, and the README does little to soften that. It assumes you will read the linked documents, which is a fair assumption but a demanding one.
Alternatives and how they differ
The obvious alternative to the torvalds/linux repository is a distribution kernel source, such as the one from Ubuntu or Fedora. Those repositories are forks of torvalds/linux with additional patches, configuration files, and packaging scripts. The difference in approach is significant. A distribution kernel is tailored to a specific user base, with a defined configuration and a release cadence that matches the distribution's schedule. The torvalds/linux repository is the upstream source, with no configuration applied and no promise of stability for any particular hardware. If you are a system administrator who needs a kernel that works with your distribution's tools, the distribution source is the right choice. If you are a developer who wants to contribute a patch that will be merged upstream, you need torvalds/linux. Another alternative is a stable kernel repository, like the one maintained by the stable team, which is not mentioned in the README but is a separate branch. That repository is for backporting bug fixes, and it has a different set of rules, which are documented in stable-kernel-rules.rst. The README points to that file, but it does not give you the stable repository URL. So the README is a gateway, not a full index.
Maintenance and upgrade cost
The README does not discuss maintenance cost directly, but the documentation links imply a high one. The kernel is under continuous development, and the README is updated as new documents are added. The presence of a dedicated section for AI coding assistants shows that the project is actively adapting to new tooling. For a contributor, the maintenance cost is learning the process: reading the coding style, understanding the submission process, and keeping up with the mailing list. The README gives you the paths, but it does not hold your hand. For a distribution maintainer, the cost is tracking stable kernel rules and ABI documentation, both of which are linked. The license is not stated in the README, but the COPYING file is linked. In practice, the kernel is licensed under GPL-2.0 with some dual-licensed files, but the README does not confirm that. You should read COPYING before distributing any derived code. The README's silence on licensing is a gap, and it is a serious one for commercial users.
Editorial conclusion
Adopt this repository if you are writing kernel code, maintaining a distribution, or studying kernel internals, because the README gives you a direct path to the exact documentation set for your role. Do not adopt it if you expect a quick-start guide or a self-contained tutorial, because the README is an index, not a manual, and every real task sends you to a separate file. Before you start, verify that you have read the building requirements in Documentation/process/changes.rst and, if you are an AI tool, the mandatory coding-assistants.rst, because the project treats those as non-negotiable entry points.
Community notes