Android & Linux - people

<blockquote><i>We pick [sic] a vendor a day, provide some analysis of their contributions, and easily come up with similar pros and cons of their interaction with the community.</i></blockquote>
<p>A useful exercise indeed.</p>
<blockquote><i>Anyway, if other vendors' compliance is basically only motivated by their competitors adherence to open source philosophies, well, then the whole thing is just a house of cards isn't it?</i></blockquote>
<p>The FLOSS "house of cards" is, IMHO, the dependency on people getting along well enough to achieve a shared objective:</p>
<ul>
<li>Someone has to articulate a worth shared objective.</li>
<li>Someone has to point the way for the team to achieve it.</li>
<li>Someone has to point out how the team can do better.</li>
<li>Someone has to encourage people to do right.</li>
<li>Someone has to discourage people from doing wrong.</li>
<li>There's more, and that's an understatement.</li>
</ul>
</p>The hard work of "herding cats" is even more difficult for us who excel at studying things instead of people: &nbsp; People don't appreciate being the object of being debugged (being poked repeatedly), and the process fails because people don't react reliably.</p>
<p>I'd think that hardware engineers should be better at it than software engineers: &nbsp; I'm recalling an old Dr. Dobb's letter to the editor that described a (KGB-stolen or West-rejected?) computer that didn't always get 4 when adding 2 and 2, yet a Soviet computer engineer stuck with the job was able to tease out the circumstances that led to its failure modes and code up a program that reliably provided correct output. &nbsp; Sounds just as difficult as debugging people.</p>
<p>And let's recall why Linus started his Minix replacement, via <a href="http://groups.google.com/group/comp.os.minix/msg/b5fb8c03..."><b>Google</b></a> (fancy that):</p>
<blockquote><i>[Linux] uses every conceivable feature
of the 386 I could find, as it was also a project to teach me about the
386.</i></blockquote>