Why kernel development still uses email (2016)
<i>&gt;, 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&#x27;s ~1875-per-hour from 2015[1]:<p><i>&gt;, and Google’s 25,000 engineers make about 45,000 commits (changes) to the repository each day.</i><p>Obviously, we can&#x27;t extrapolate that Google should switch to an internal SMTP project management system layered on top of Perforce because <i>&quot;email is faster than any of the alternatives&quot;</i>.  Same for other companies with high commit rates to their source repos like Microsoft and Facebook.<p>Since Linus &amp; 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&#x27;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 &quot;threaded tree views&quot; etc is actually <i>hiding</i> the underlying reason email-as-workflow works for Linux.  Email isn&#x27;t about &quot;throughput&quot;; it&#x27;s &quot;acceptance&quot;.<p>[1] <a href="https:&#x2F;&#x2F;www.wired.com&#x2F;2015&#x2F;09&#x2F;google-2-billion-lines-codeand-one-place&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.wired.com&#x2F;2015&#x2F;09&#x2F;google-2-billion-lines-codeand...</a><p>[2] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Application_lifecycle_management" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Application_lifecycle_manageme...</a>