From the ‘No Conspiracy Here?’ files:
How do Linux kernel devs figure out which kernel will be the basis for their enterprise distros?
The Linux kernel community is made up of lots of different developers working at different companies. But as it turns out, those companies don’t really control their own kernel roadmaps as much as they might think.
Linux Kernel (Jolly Good) Fellow, Greg Kroah-Hartman has publicly exposed a ‘cabal’ that has set the tone for the last set of major enterprise Linux releases across all major vendors.
Kernel devs are a tight community and work together at conference, IRC and mailing lists – something that we already knew. What I personally did not know was how those interactions combined to set broader policies.
Kroah-Hartman and his ‘cabal’ of developers devised such a ‘conspiracy’ for the 2.6.32 kernel, which at the time became the base for every major enterprise distro.
“We all agreed, informally, to push for a specific kernel release within our communities/companies that I would then maintain in the kernel.org community in the same way I had done for the 2.6.16 kernel release,” Kroah-Hartman wrote in a blog post. “We all drifted back to our companies, and planted the seeds that maybe something like the 2.6.32 kernel would be a nice one to do our product on. This planting worked so well, I had to refrain from fits of laughter in one meeting where a project manager got up and said, “We decided that the 2.6.32 kernel would be the best for our product, what does engineering think about this?”
That’s funny.
Product managers really don’t control Linux do they? It is the kernel developers and always has been, no matter what corporate management may want or think. The collective open development nature of the kernel is what makes it the thriving success story that empowers so many of us to live, work and play.
Sean Michael Kerner is a senior editor at InternetNews.com, the news service of the IT Business Edge Network, the network for technology professionals. Follow him on Twitter @TechJournalist.