LCA: How to destroy your community

No, but they can prevent it from ever existing. That's even more effective!

Hmmmm, you mean the thing they've been building for five years?

You've just touched on another tactic hinted at by the article: If you don't have a community, even if you supposedly started one years ago, and people call you out on it then just claim that you're still building it!

Oh, and I forgot to mention in my list of positive interactions with Sun folks that I ran into a guy who hacks the OpenSolaris installer in a coffeeshop the other night and when I told him about the awesome "apt-clone" hack that the Nexenta folks have written he asked me to put him in touch with them in order to share code. Long live the wonderful positive tradition of collegial sharing and peer review!

NSA told them to exclude the crypto engine. This bothers me, because by law in the U.S. free/open implementations of crypto are freely exportable and in addition disclosure of crypto *to* other U.S. persons is completely unregulated. So I feel that it was improper for NSA to pressure them to withhold the GPL'ed crypto engine.

Well, I'm not sure what to say. My communication with Sun about the crypto engine of the T2 was fairly "formal" -- it wasn't with people that I had previously met. Also Sun's "Startup Essentials Program" (a hardware sales division) donated a thumper to my little Free Software startup company (http://allmydata.com). That was nice! Basically, I've had nothing but good experiences dealing with Sun as a seller of hardware, a research institute, a sponsor of open source projects, and a collection of humans. This is in stark contrast to the Linux kernel developers, with whom I've had, I'm sorry to say, mostly unpleasant interactions.

Let's turn the burden of proof around: what is the evidence that some specific corporate policy or habit is bad for open source community involvement? Surely many of the open source projects sponsored by Sun have little or no non-employee participation but this doesn't make those projects any different from *most* open source projects. Almost all open source projects have no contribution from anyone other than their founders or the company that sponsors them. So this is not specific evidence that Sun's policies are particularly destructive.

I would be very interested to learn more specific, reliable patterns about community involvement in open source. I've devoted much of the last fifteen years of my life to such projects, and I can say that the open source projects that I've led have had higher levels of community contribution than average. (Where average is zero.)

That's why I read this article with interest (and also read previous posts on the web about Josh Berkus's speech). Surely the points that Josh Berkus makes seem eminently sensible. I'm sure they are good things to keep in mind. But I'm skeptical that they are actual empirical explanations of the failure of OpenSolaris to attract external contributors, or of the success of Hudson to do so. I suspect there are other factors that are more explanatory.

> Ah yes, I remember. Your email:
>
> http://www.gelato.unsw.edu.au/archives/git/0506/5298.html
>
> And his reply:
>
> http://www.gelato.unsw.edu.au/archives/git/0506/5299.html

That was one of the conversations that I was thinking of, but the message 5298.html that cite above wasn't written by me. I wrote an earlier message in the thread that IIRC was forwarded to lkml by someone else.

> I understand that you see his reply as a bit stinging, but your whole argument was based on the assumption that you could crack md5 in a way that lets you generate a meaningful exploit and then on top of that manage to inject that into the kernel.

I'm not entirely sure what you mean by "crack md5 in a way that lets you generate a meaningful exploit". In the exchange that you cite above, the other person, <linux@horizon.com>, was right and Linus was wrong in respect to the question of whether git users depend on the collision-resistance property of the hash function or not. The truth is that they do, but in a subtle way that most people (including Linus at least at the time he wrote that) don't understand.

At this time (in 2005), when Linus was deciding to stick with SHA-1 for git, certain certificate authorities were deciding to stick with MD5 for signatures, for the same reason -- it seemed to them that they didn't rely on the collision-resistance property. In 2008 it was demonstrated that they did actually rely on that property:

http://www.win.tue.nl/hashclash/rogue-ca/

A similar attack is probably possible on git. It currently costs substantially more than USD 1 million to build a computer that can generate SHA-1 collisions (how much more is not publicly known, but probably less than USD 10 million). For now, only the rich can play.

So while I'm sure that the cryptographers who generated the rogue Root CA (above) can't inject their own code into your git pulls (because they work at public academic institutions and don't have the budget), I'm not sure that the NSA or the Chinese cyberwarriors can't.

> I can see why Linus responded with sillyness :-)

I understand that it seemed ridiculous to him at the time. However he was qualitatively wrong about the properties that git users rely on, and both he and <linux@horizon.com> were quantitatively confused about the cost to generate SHA-1 collisions. (See the rest of the thread that you cited, in which they talk about SHA-1 collisions costing 2^80 computations, when in fact the known upper bound at that time was 2^69. Today the known upper bound on the cost to generate a SHA-1 collision is 2^63.)

One effect of mocking things that seem ridiculous to you is that it deters certain kinds of people from participating in the conversation. I suppose this could be useful if you are right and they are wrong and progress is achieved by getting them to shut up, but of course you take the risk that you were wrong in the first place and by doing this you stay wrong.

I, for one, was reading that conversation at the time, and decided not to join in and try to explain more, in part because I didn't want to have my feelings hurt by mockery and in part because it didn't seem like I would have a good chance of making my point understood.

So to attempt to swerve back onto the topic of this LWN article, when I offered some suggestions to the engineers who are adding crypto to ZFS, they responded with technical arguments that were expressed in polite language. I was therefore emboldended to think that they might actually be listening, and went on to offer more ideas: http://opensolaris.org/jive/thread.jspa?threadID=117092&... . From my very specific, narrow, limited viewpoint, Solaris open source development has been easier to participate in than Linux development. ;-)