X
Tech

Google's Android fork defended, debated, dissected ... again

It should come as no surprise that Google's purported forking of the Linux kernel -- which is shaping up to be a Hatfield-McCoy scale conflict - took center stage at LinuxCon's opening day.On Tuesday, tension was evident at a session examining lessons learned from the Android/Linux debacle.
Written by Paula Rooney, Contributor

It should come as no surprise that Google's purported forking of the Linux kernel -- which is shaping up to be a Hatfield-McCoy scale conflict - took center stage at LinuxCon's opening day.

On Tuesday, tension was evident at a session examining lessons learned from the Android/Linux debacle. Later that day, panelists on both sides of the fence argued forcefully about whether Google was right or wrong about not sheparding Android into the kernel.

This time, Google had some strong supporters. Among them was Red Hat's Matthew Garrett, a Linux kernel contributor who works on power consumption issues.

At his session, Andoid/Linux: Lessons Learned, Garrett noted that the "partial forking" of the Android code is unfortunate but maintained that there are very good technical and social reasons why Google's Android code is not yet integrated into the kernel and that other companies -- including his own -- have released Linux code and patches to its customers that are not contributed to the kernel.

The big lesson learned?

"Sometimes it's difficult to be a good community member," Garrett said. "Maybe [Google should have] involved us first before the code was written but it's not fair to say they're a bad community member," he said at the Boston-based conference.

Even Red Hat ships out some Linux patches in its Linux distribution patches for its enterprise customers that don't make their way to the kernel. "It's not realistic to do all patches [to a shipping product] upstream," he told his audience. "I'd prefer the world to not be that way but [it is]."

Google provided Android code to the Linux kernel team in 2008 and improved and refined the code twice before it was pulled from the Linux kernel allegedly due to lack of participation by Google.

He said one major difficulty is that Google's wave lock code is unique to Android and not a baseline technology that would  be used by other mobile platforms.

The "partial forking" is disappointing but much better than not having any open source mobile platform to compete against Apple's iPhone, the Red Hat executive said.

Some of Garrett's comments were directed at one gentleman who kept peppering him with questions about the propriety of Google's so called unwillingness to fix and contribute the Android code to the mainline kernel.

He tried to address the man's questions diplomatically but failed to silence him. First, he told him to talk to relevant people after the session. When that failed, he asked the man to "Be Quiet."

When that command failed, too, he asked the man to leave the room, and then called out to some unknown attendant to get him out of the room.  You know it's tense when  someone gets 86'd before lunch.

[I was attending via webcast and was unable to chase the man down but would love to get an email from him or someone who knows who it was so that I could ask some questions myself].

The topic hit fever pitch again later in the day, when panelists from Google and Novell sparred a bit about the so called Android fork.

Ted Ts'o, a Linux kernel maintainer who joined Google in January 2010, said both Novell and Red Hat ship patches that were rejected by the Linux kernel but no one describes their distributions as Linux forks.

It's nothing new," he said. "Novell has a number of patches and SUSE ships with code somebody rejected but no one says Novell forked the Linux code. Red Hat ships SystemTap and no one says Red Hat forked the kernel."

Ts'o claims that Google is taking the heat because of the immense popularity of Android. Its lack of inclusion in the kernel makes it cumbersome for third party developers and manufacturers in the Android ecosystem who have to maintain two separate driver code bases.

Novell's James Bottomley sees it differently. He maintains that the Android fork is evolving in to a long term problem and that the scope of that product should not be compared to patches by distributors.  Google met with Linux kernel developers in April but has not taken serious steps to address Android's absence from the kernel, the Novell developer said.  There are "troubling signs that Google is not interested," Bottomley said.

Nobody got thrown out of the room this time around but those are fightin' words -- aren't they?

In an e-mail interview with this blogger in March, Google's open source guru Chris DiBona said the Android code will make it into the mainline Linux kernel in time but technical issues and mobile platform issues needs to be ironed out before it makes sense.

He also said in May that Google would hire a couple of developers to work closely with kernel. org.

At LinuxCon, Bottomley claimed that it might take a lot of effort for Google to resolve the issue but that the end result should "benefit the whole community, not just Google."

{editor's note: Chris DiBona's first name was incorrectly identified in this original posting. This blogger regrets the error.

Editorial standards