Why Linux’s Email‑Driven Development Process Still Matters (and How to Evolve It)

Commit Messages and Patch Granularity

Linux requires every change to be expressed as a single‑purpose patch accompanied by a detailed commit message that often exceeds the size of the diff. The message must explain the problem being solved, the conditions under which the bug appears, why the change is safe, and any back‑porting considerations. This uniform documentation enables developers from many companies to understand intent without additional context.

Key benefits:

Consistent communication across a massive, long‑lived code base with contributors from diverse backgrounds.

Facilitates backporting: well‑structured patches can be cherry‑picked to older branches (e.g., LTS releases) without extensive re‑work.

Example of a concise but insufficient GitHub commit ( fix bug) versus a Linux patch that includes a multi‑paragraph rationale and testing instructions.

Cost of Code Re‑organization

When a later patch introduces a change that conflicts with earlier patches—such as adding a new parameter to a function used by previous patches—developers must revisit and modify the earlier patches, retest, and potentially rewrite history. This cascade can invalidate prior testing and increase reviewer workload.

Typical workflow:

Reviewer requests an additional parameter in a function introduced in the first patch.

All subsequent patches that call the function must be updated to pass the new argument.

Tests for those patches must be rerun, and any dependent patches may need further adjustments.

While painful, this discipline ensures that every change is reproducible and that the code base remains stable across versions.

Potential Tooling Improvements

Several ideas aim to preserve Linux’s strengths while reducing manual effort:

Separate development and review storage: Use Git solely for storing the final history, while a dedicated review system holds intermediate patch series. This mirrors the CSS/HTML separation, allowing developers to rewrite history locally without affecting the public repository until review approval.

Higher‑level change descriptions: Instead of line‑by‑line diffs, describe transformations (e.g., “add integer parameter y to create_bar() ”) so the system can apply the change across slightly different code bases. Emerging AI models (e.g., GPT‑3) could assist in interpreting such intent.

Gate‑controlled history rewriting: Require that every line added to the code base be approved by a reviewer before the commit is merged into the main branch. Only after approval is the Git history rewritten, guaranteeing that all modifications have been vetted.

These concepts aim to keep the disciplined patch granularity and exhaustive commit messages while streamlining the reviewer’s workload and reducing the risk of large re‑organizations.