ELC: Morton and Saxena on working with the kernel community

I applaud Andrew and Deepak for their efforts here. The best Linux projects are run as
extensions to the community. The company gains by interacting with experts in the community,
resulting in better code. Linux gains by new features or hardware support being added to the
kernel.

We need to make more hardware and silicon vendors aware of the benefits in working with the
community. Too many SoC vendors, for example, don't submit their kernel patches to the
community. They prefer to distribute their own "patched" kernel to their customers directly,
as if they're adding value by doing so. In the last two years, I've worked on projects at
different companies using SoCs from three different silicon vendors and none of those silicon
vendors were actively working on submitting their code to the kernel. Why? The article gives
several reasons that I won't repeat again here. A few more are

- High perceived difficulty in getting patches approved. Companies who try to submit work to
the kernel lists can be scared off by what they perceive as aggressive or unreasonable
comments from the community. The Linux community could do better in this area. This is where
Andrew's initiative comes in - educating people about how to work with the community. Greg KH
is also active on this.

- Concern that releasing open source drivers for hardware somehow gives away competitive
advantage. This is a hard nut to crack. If companies understood more about the potential
advantages of submitting code into the kernel, more might do so. Some companies though are
just stuck in their ways.

- The quality of the vendor's code isn't up to scratch to be accepted into the kernel. The
hardware vendor knows it so doesn't bother submitting it. I even saw one comment in one
vendor's kernel distribution along the lines of "Heaven forbid we are forced to release this
code to linux-mips.org. We'll be laughed at." Unfortunately, some code written by or for
hardware vendors is done in a way that is never intended for submission into the kernel. As a
result, it is often buggy and difficult to keep up to date when new kernel features come
along.

The bottom line is that if you are starting an Embedded Linux project and are evaluating
hardware alternatives, choosing hardware that is already supported by the Linux kernel could
save months of software effort, even if the hardware vendor claims Linux support by "special"
out-of-tree code. Let's help them understand what's in it for them in working with the
community.

Shameless plug. I published a white paper on Best Practices in Embedded Linux a while ago.
http://www.katalix.com/doc/embedded_linux_best_practices.pdf

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development