Discussions about Red Hat's involvement in the OpenStack project have dredged up old enmities about Red Hat's kernel development practices, charges that are perhaps misdirected, yet still reflect a strong undercurrent on the value of code contribution in open source.
It was an innocuous article from colleague Sean Michael Kerner that started the whole thing, which highlighted an interesting analysis of code contributions to the recent Essex release of OpenStack.
In the analysis, it was revealed that Red Hat was the third-highest contributor to the Essex version of OpenStack, sending in 275 changes with 27,591 lines of code.
Kerner's original thread was to point out that Red Hat's contribution amount was higher than rival Canonical's--a point I would have picked up myself, admittedly. Since shifting its focus from Eucalyptus to OpenStack, one would suppose that Canonical would be a strong contributor to OpenStack, but with just 92 changes and 3,267 lines of code changed, this notion is challenged a bit.
Canonical would point out, of course, that code contribution as a metric is not the sole determinant of what makes a community or project strong. That's not supposition on my part: it's pretty much what Ubuntu Community Manager Jono Bacon tweeted in response to a Twitter statement from Xamarin CTO and Mono developer Miguel de Icaza.
"[C]ode contributions are one metric of contribution of many, I think people get a little overly focused on code at times," Bacon wrote.
This is a point that I think deserves a little more attention, because while I don't completely disagree with Bacon, I think code contributions have a higher value of meritocratic currency in the Linux and open source community than Bacon and Canonical want to assign. And it was another thread off of de Icaza's comment that illustrate this value quite clearly.
"Red Hat contributes more to OpenStack than Ubuntu, countdown to RHT obfuscating patches so others don't take it in 3, 2," de Icaza wrote, linking to Kerner's article.
de Icaza's initial comment highlighted a point of contention some in the open source community still harbor towards Red Hat: their acknowledged practice of releasing kernel code patches downstream in the form of tarballs, which makes it very difficult for downstream vendors to parse out exactly what changes Red Hat made to the Linux kernel.
A blog entry by Red Hat CTO Brian Stevens back on March 4, 2011 confirmed the practice and laid it out for all to see.
"When we released RHEL 6 approximately four months ago, we changed the release of the kernel package to have all our patches pre-applied. Why did we make this change? To speak bluntly, the competitive landscape has changed. Our competitors in the Enterprise Linux market have changed their commercial approach from building and competing on their own customized Linux distributions, to one where they directly approach our customers offering to support RHEL," Stevens wrote at the time.
"Frankly, our response is to compete. Essential knowledge that our customers have relied on to support their RHEL environments will increasingly only be available under subscription. The itemization of kernel patches that correlate with articles in our knowledge base is no longer available to our competitors, but rather only to our customers who have recognized the value of RHEL and have thus indirectly funded Red Hat's contributions to open source that will advance their business now and in the future," Stevens continued.
At the time, I argued that while this protectionist stance made sense to compete with vendors like Oracle (who gleefully have copied Red Hat code for their own Oracle Unbreakable Linux), this practice or pre-applying patches would still rankle many in the community.
Based on his comments on Twitter yesterday, de Icaza is clearly still rankled.
While Bacon jumped in with his comments on code contribution metrics, immediately another heated discussion thread began on Twitter, when Red hat developer Peter Jones took exception to de Icaza's comments.
"[W]hile I'm not the biggest fan of what we do in our kernel tree, you're miscategorizing it in a pretty serious way," Jones replied.
You can follow the thread of the conversation yourself, but essentially de Icaza argued with Jones (and later Red Hat kernel developer Matthew Garrett) that Red Hat's policy of obfuscating code was just Red Hat's way of enforcing its IP in a manner consistent with FOSS practices.
That is all well and good, but de Icaza's objections really aren't applicable in this case. Red Hat's contributions to OpenStack are going in the opposite direction: upstream. And while you can obfuscate code heading downstream all you want (though this is still not cool), it's impossible to hide patches going into an upstream project.
de Icaza seems to know this, because he eventually characterizes his original statement as a "humorous" call-out of Red Hat's kernel policies and not a direct commentary on Red Hat's OpenStack contributions.
That's a pretty big jump just to make a funny point. While I don't particularly agree with Red Hat's policy on kernel patch releases (and neither does Jones), it's unfair to slap that practice in Red Hat's face for everything they do. Red Hat, like them or not, contributes a lot of code, human resources, and money to a lot of open source projects and they deserve credit where credit is due.
That said, this entire conversation could serve as an insight into a faction of the open source community that de Icaza seems to represent: a faction that says that what you contribute and how you contribute is a direct reflection of a developer's or vendor's value to the community.
It can be debated just how much value should be assigned to this metric, but companies like Red Hat and Canonical cannot afford to ignore this metric altogether, because it clearly still carries a lot of meaning in the open source community, whether they agree with the weight of that meaning or not.
Read more of Brian Proffitt's Zettatag and Open for Discussion blogs and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.