I wonder if things are different on the BSD side versus the Linux side. Just a guess, but Linux kernel development has always had a sort of anti-academic view, perhaps soured by the early Tanenbaum-Torvalds flamewar, whereas much of BSD was actually written by academics (the name comes from UC Berkeley, after all), and collaboration still seems reasonably common. There might be some downside to Linux being so popular, as well: it's now the default option, so people who just need <i>something, anything</i> to test on will pick Linux, whereas my guess is that people modifying, say, the NetBSD kernel for academic work are more interested specifically in NetBSD and contributing back to it. Solaris development also long had a close relationship with academic researchers working on Solaris, for whatever reason (probably Sun actively making efforts, including hiring academics for summer consultancies).
Excellent essay (and, I assume, talk). This jumped out at me:<p><i>So it seems that there is the reverse problem on the real world developer side: we are solving problems, comparing and contrasting approaches and implementations, but we are either too lazy or too busy to sit down and write a proper paper about it</i><p>That would be invaluable, but I understand that they don't do it for the very same reason that OS researchers don't submit patches to the LKML: it's not what they're evaluated on.<p>If you've ever been frustrated by the disconnect between research and industry in the area of computing, read this essay.
From the other side:<p><i>Comparing and contrasting research results is almost impossible. Even if a lot of research happens on Linux there is no way to compare and contrast the results as researchers, most of the time, base their work on completely different base kernel versions. We talked about this last year and I have to admit that neither Peter nor myself found enough spare time to come up with an approach to create a framework on which the various research groups could base their scheduler of the day. We haven't forgotten about this, but while researchers have to write papers, we get our time occupied by other duties.</i><p>This is almost entirely the Linux kernel's fault. The development pace on the kernel is quick and very few things are guaranteed to be stable. By the time my group had worked out a patch a release block was finished. I gain almost no benefit from sending this to LKML and I hear it's never worth the flames my colleagues get when you haven't done enough "work" for them. The worst was a colleague having to defend his patch from a paper to the kernel team. Who cares? The devs can take it or leave it, we don't have time for that crap.
/Unfortunately almost none of the results ever trickled through to the kernel development community, not to mention actually working code being submitted to the Linux kernel mailing list./<p>Unfortunately, when an academic submits their working code to the Linux kernel mailing list, they're likely to get flamed to a crisp if they get any response at all. They learn real quick not to waste their time with that hostile crowd.<p>Not to mention the volume of the Linux kernel mailing list is absurd. Who has the time or inclination to keep up if it's not their main passion?