Why kernel development still uses email (2016)
<i>>, kernel developers still use email because it is faster than any of the alternatives. Over the course of the last year, the project accepted about eight changes per hour — every hour — from over 4,000 developers sponsored by over 400 companies</i><p>Compare with Google's ~1875-per-hour from 2015[1]:<p><i>>, and Google’s 25,000 engineers make about 45,000 commits (changes) to the repository each day.</i><p>Obviously, we can't extrapolate that Google should switch to an internal SMTP project management system layered on top of Perforce because <i>"email is faster than any of the alternatives"</i>.  Same for other companies with high commit rates to their source repos like Microsoft and Facebook.<p>Since Linus & Linux community never did an A-vs-B experiment of email vs open-source-JIRA-clone as a project workflow, I think we can only safely say that email works best for a disparate group of volunteers with different employers.  Email is the lowest common denominator that everyone could agree to use.<p>You couldn't get 4000 <i>opinionated</i> developers to agree to use an open-source JIRA-clone or MS-Team-Foundation-clone or some other ALM[2]-in-the-cloud.<p>Therefore, listing advantages of email clients such as "threaded tree views" etc is actually <i>hiding</i> the underlying reason email-as-workflow works for Linux.  Email isn't about "throughput"; it's "acceptance".<p>[1] <a href="https://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/" rel="nofollow">https://www.wired.com/2015/09/google-2-billion-lines-codeand...</a><p>[2] <a href="https://en.wikipedia.org/wiki/Application_lifecycle_management" rel="nofollow">https://en.wikipedia.org/wiki/Application_lifecycle_manageme...</a>