Seeing this post in context of whole conversation will show that Linus&#x27; stance was not that bad:<p><a href="https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2000&#x2F;8&#x2F;22&#x2F;12" rel="nofollow">https:&#x2F;&#x2F;lkml.org&#x2F;lkml&#x2F;2000&#x2F;8&#x2F;22&#x2F;12</a>
(quote from Linus&#x27; post)<p>`<i>It&#x27;s true that &quot;simple and tested code means less bugs&quot;. And quite often, code sharing will imply that the code gets (a) more complex and (b) has cases that people who make changes will never be able to test.<p>No, I&#x27;m not saying that sharing is bad. Sharing is good. But anybody who makes a blanket statement like &quot;sharing reduces bugs&quot; is full of crap.<p>Good and clear interfaces reduce bugs. Avoiding complexity reduces bugs. Using your brain before you code something up reduces bugs.<p>But making a very complex driver that handles ten different variations on the same hardware? No. That does _not_ reduce bugs. It&#x27;s quite often more efficient to have two people work on two drivers that are independent of each other, than to have two persons working on the same driver. Alan put
it well at some point: the way to create working open source software is to minimize the amount of communication needed.</i>`<p>I think he&#x27;s <i>veeeeery</i> reasonable in this. This reminds me &quot;Wrong Abstraction&quot; article. 
<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11032296" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11032296</a>
Sometimes it is better to create two separate things than create some weird obscure abstraction which cover all the cases.