Acceptance is certainly part of it, but 8 changes per hour is 8-10 email threads per hour, which is just not that hard to track as an individual, thus no need to change anything. Right now at work on a large (200ish) team, I get cc'd on about the same amount of patches.

isn't google's situation a monorepo composed of many distinct projects? there doesn't seem much utility in the comparison.

> Email isn't about "throughput"; it's "acceptance".

this seems to be the similar, in the other direction. using (or not) an alm in an organization isn't about "throughput", it's about "accepting" a company's policy assertions.

I don't think that equating it from the reverse direction works. Here's why:

Using the article's count of ~4000 developers, let's consider all software companies that employ 4000+ developers as part of a "natural experiment"[1]. This includes companies and organizations like MS, Facebook, NASA, SAP, Oracle, etc.

Each company "votes" in the marketplace of ideas to coordinate software development for a complex project. One company might use JIRA. Another uses MS Team Foundation. Another uses FogCreek. Maybe another employer might use SMTP emails similar to Linux kernel development.

Since companies have every incentive to develop software with cost-efficiency and velocity, they will want to use the best workflow possible.

Since no single software company I know of uses SMTP emails as their ALM workflow, it either means that (1) companies are wasting money & losing iteration velocity by avoiding email -- or -- (2) the Linux kernel community has special circumstances that makes using a true unified ALM unrealistic. I believe that special circumstance is: 4000 programmers work for different employers instead of a single employer.

[1] https://en.wikipedia.org/wiki/Natural_experiment

in the abstract these are generally viewed as or presumed to be positive, but the pressures and objectives of a business can be rather complex and other things will often compete for finite resources.

having worked in a number of large organizations, the waste and inefficiencies one can find is absolutely staggering.

outside the sales pitches, it's also not clear how an alm interacts with notions of 'cost-efficienty' and 'velocity'. introducing process and bureaucracy isn't always a win.

perhaps the presumed predilection of large organizations for alms can be found in alms addressing (or seeming to address) other needs, pressures or requirements.

Sure, I agree this is true in a general sense (Dilbert cartoons, Peter Principle, etc). However, for things like choosing technology to help with market superiority, companies (especially software engineering companies) will eventually gravitate to something better.

We could argue that companies are "inefficient" for not embracing remote work-from-home instead of open offices, etc. (general inefficiencies). But, even badly run companies don't insist on using inferior floppy drives instead of USB drives or wireless network file transfers. Yes, a law firm might limp along with an 15-year old version of Microsoft Word 2000, but a software engineering company will not. (technology inefficiencies)

> introducing process and bureaucracy isn't always a win.

The Linux dev community also has process & bureaucracy. See my previous link for the strict and precise formatting rules to submit kernel patches in emails. That's process. Just because it's not in a web form with fields doesn't mean it's not "process". They're just using emails as the workflow for it. (Linus has famously chastised contributors for not following "the rules".) Process & bureaucracy is not bad thing -- its effort just has to match the scope of work being delivered. (E.g. using JIRA for a "hello world" toy program is overkill.) The Linux kernel community seems to have converged on the level of bureaucracy that works for them.

It's interesting that even young YCombinator companies with much less than 4000 employees also don't stay with SMTP email-as-ALM as they get bigger. If email-as-ALM was a better software dev philosophy, there would be a huge arbitrage opportunity to outcompete everybody. Instead, the email-as-ALM fits Linux kernel devs' specific circumstances.

I agree and that's why the author quoting Greg Kroah-Hartman about commit velocity (throughput of "8 changes per hour") in his article is actually a distraction from answering the actual question as stated in the article's title. The real reason for kernel devs use of emails isn't the throughput.

Kernel development seems to progress fine, I'm pretty sure if there was a problem, Linus would have made some effort to change it, just like the whole source control thing that ended up becoming Git.

I'm not claiming that there's a bottleneck in kernel commits. (I'd guess human code reviews checking quality is the ultimate bottleneck.)

I'm saying that using emails as "building blocks to reconstruct an pseudo ALM" instead of using an actual special-purpose ALM -- is the only realistic workflow that would be accepted by the disparate Linux community who don't work for a single employer. (If you're a single company employing all 4000 of Linux kernel programmers, you could impose an ALM tool be mandatory for code reviews, assigning work, tagging bug reports, etc.)

Discussing positive bullet points of email ... even though each bullet point is true actually obscures the underlying reason the devs won't use an ALM.

I guess I don't understand your question. In Linux, the email-as-the-workflow[1] has been agreed upon from Linux Torvald and his lieutenants all the way down.

I suppose that if a one refused to use email-based-workflow, they'd have to find a Linux kernel maintainer to be a champion for their proposed changes and submit them on their behalf. (Is this a common scenario? I don't know.)

If a rebel Linux kernel programmer insisted on staging changes for review in Gerritt/JIRA/github/etc, he's going to be isolated in an island because he's not part of the agreed-upon workflow: emails.

[1] https://github.com/torvalds/linux/blob/master/Documentation/...

Let than sink in. It's not only 4000 opinionated devs. It's, potentially, 400 completely different organizations; 400 management layers on top; 400 different priority sets; devs in every time zone; etc. Google is just 1 company (a dozen, if you want to break down Alphabet).

It's amazing that they manage to get 8 changes an hour, and still be one of the most successful open source, and software project in general.

Why changing the system?

From 3.19 to 4.7, an average of 4600 lines of code was added daily.

Over 80% of all kernel development is done by developers paid for their work.

A small number of companies are responsible for a large portion of the total changes. These being, from biggest to lowest contributor: Intel (12.9%), Red Hat (8,0%), Linaro (4%), Samsung, SUSE, IBM, Google (2%), AMD, Texas Instruments, ARM, Oracle.

Contributions from unpaid developers have been in decline for many years. 14.6% in 2012, 7.7% in 2016.

The problem with a ALM is it is a global lock. It is enormously disruptive if it is unavailable or even slow.