On giving back [LWN.net]

On September 8, LynuxWorks announced the availability of a beta release of BlueCat Linux 5.0. BlueCat is the company's embedded Linux distribution; 5.0, interestingly, is based on the (still unreleased) 2.6 kernel. LynuxWorks claims to have applied a lengthy series of "ISO 9001:2000" reliability tests to this kernel. The PR also cites some of the features of this kernel which are of interest to the embedded community, including kernel preemption, the O(1) scheduler, and the improved threading support. LynuxWorks, they say, is the first embedded systems company to make these features available in a Linux-based system.

The interesting thing, of course, is that all of those features were developed at other companies. Kernel preemption, in particular, was done by Nigel Gamble and Robert Love at MontaVista - a direct LynuxWorks competitor. The extensive testing done by LynuxWorks must certainly have turned up bugs; the 2.6 kernel is still an unreleased product, beta quality at best. Yet no fixes appear to have been sent back to the community. Over the last year, only one posting appeared on linux-kernel from either lynuxworks.com or lnxw.com - a request for help with a compilation problem. The 2.6 BitKeeper repository, containing all patches merged since February 2002, shows one set of patches from LynuxWorks.com: a USB Pegasus driver by Petko Manolov. The last patch was merged in May, 2002. We asked LynuxWorks if it had a list of recent contributions (which could, after all, have been sent in from a different email address), but got no response.

LynuxWorks, in other words, is taking full advantage of the work of others - including its competitors - to claim to be "first to market" with a set of new features. And it has done so without contributing much of anything back to the community from which it draws the software it is selling. LynuxWorks is far from alone in this behavior, of course. LynuxWorks is also acting entirely within its rights. As long as they abide by the GPL, nobody can complain if they use the software in this way. That is what free software is all about.

It is also true, however, that being within your rights and being right are not always the same thing. A company that is making money selling Linux should feel some obligation to contribute back to Linux. Especially when that company is in the operating systems business and clearly has the technical resources to make that sort of contribution.

Contributing back is not just the right thing to do; it is also good business. Customers feel better when they see that their suppliers have a good relationship with the development community upon which they depend. Customers also like the feeling that a supplier understands the software well enough to make changes and get them accepted; it improves that chances that bugs can be fixed and requested changes implemented. They feel better about the software as a whole if the vendor cares enough to make it better. Software with active support from those selling it has a better chance of being around and still maintained a few years from now.

Many free software companies understand this well; they point to their free software contributions as a source of pride. As users of free software become more sophisticated, they will ask for that information. Customers need to know that their suppliers can provide them with the support they need, and that said suppliers are committed to the future of the software they work with. A history of contributing back to the software in question is one of the best ways to show customers what they want to see. It also has the incidental benefits of making the software better and being the right thing to do.

to post comments

On giving back

Posted Sep 11, 2003 4:46 UTC (Thu) by xorbe (guest, #3165) [Link] (5 responses)

As soon as they distribute the kernel, then the kernel-source follows. How hard is it to diff for the changes?

On giving back

Posted Sep 11, 2003 8:29 UTC (Thu) by james (guest, #1325) [Link] (1 responses)

As soon as they distribute the kernel, then the kernel-source follows. How hard is it to diff for the changes?

I don't think the complaint is that they're keeping the changes to themselves, but that they haven't made any changes or enhancements: they're acting as little more than a packaging company.

James

On giving back

Posted Sep 18, 2003 17:34 UTC (Thu) by pdundas (guest, #15203) [Link]

You're probably right - the author doesn't actually state which case he believes to be true: no fixes made, or none given back.

Of course if they have made major changes their work amounts to an unmaintained fork, which is more work for them in the long run.

Possibly they might accept the overhead of this in the short term, as a cost of being first to market. But as has been pointed out, if there are improvements, inspection of the source (or eventual contributions from these guys) should allow improvement of the "real" kernel in the slightly longer term.

Paul

On giving back

Posted Sep 11, 2003 15:41 UTC (Thu) by proski (guest, #104) [Link] (2 responses)

It's not hard to make a diff, but there is a huge difference between a patch submitted by a person who wrote it, with an explanation, and a patch extracted from someone else's kernel for an embedded system, when it's not even clear if the patch is good for general consumption or it's just a hack for a certain class of systems.

Writing the code is often less than 50% of work. Submitting and documenting changes and making others understand them is often the hardest part, at least in terms of time.

The requirements of quality in the Linux kernel are higher than in an average software project. I really doubt that any patches exctracted from distributions will be applied unless they are submitted by the author of the code, even it GPL allows to incorporate such code legally.

On giving back

Posted Sep 11, 2003 15:52 UTC (Thu) by error27 (guest, #8346) [Link] (1 responses)

I really doubt that any patches exctracted from distributions will be applied unless they are submitted by the author of the code, even it GPL allows to incorporate such code legally.

It does happen. The kernel janitor project tries to make it happen. I haven't seen very many of these kinds of patches make it to the kj list but that could be because everyone is focussed on 2.6 and the distributions haven't started patching 2.6 yet.

On giving back

Posted Sep 11, 2003 17:42 UTC (Thu) by proski (guest, #104) [Link]

It's good to know. My point still stands - it still takes efforts to process changes that were not submitted properly.

If my colleagues make changes, I always ask them to submit their patches. It saves time in the long run - you won't have to apply the patch to the new versions.

ISO 9001:2000

Posted Sep 11, 2003 8:53 UTC (Thu) by james (guest, #1325) [Link] (2 responses)

LynuxWorks claims to have applied a lengthy series of "ISO 9001:2000" reliability tests to this kernel.

Actually, the press release doesn't claim this. Which is good, because, ISO 9001:2000 is nothing to do with computer kernels as such.

The ISO 900x series is a business methodology for ensuring that what you produce falls within set limits. The standards don't set those limits: they impose a Quality Management System, with business processes to ensure that whatever is produced falls within agreed standards. The processes all have to be fully documented, and records kept of the checks and balances made.

It's been described as "making sure that if you're producing Robin Reliants, you don't produce a Bentley by mistake".

So, for example, if you had regression tests set up for your entire product line, you could document the way that these were run and ensure that nothing was released that didn't pass these regression tests.

LynuxWorks are careful, in the original press release, to apply the label to the business and the way they work (which is allowed under the standard), and not to the finished product (which isn't).

I can see that a BlueCat customer might legitimately want to know that they can rely on agreed functionality continuing to work across different releases. But all it does for the OS is ensure that things keep working.

That's good in itself, of course, but we don't know how good those hypothetical regression tests are. Evidently, they don't catch much.

James.

ISO 9001:2000 -- Concrete Life Preservers

Posted Sep 13, 2003 5:21 UTC (Sat) by AnswerGuy (guest, #1256) [Link] (1 responses)

The more cynical view of ISO 9000 is that it can be used to
"ensure" the quality process and management for production of
concrete life preservers.

A concrete floatation device is an absurd concept, but ISO 9000
does assure the quality of your product, just the process by
which your products are created.

That's the joke; obviously it mostly a marketing term, a buzz
word to put in your press release and on your web site, and an
excuse to hang a big tacky looking banner off your offices out
in the industrial park.

Jim

ISO 9001:2000 -- Concrete Floats (yes)

Posted Sep 18, 2003 17:26 UTC (Thu) by pdundas (guest, #15203) [Link]

> A concrete floatation device is an absurd concept

Actually, to demonstrate that truth is stranger than fiction, there was a concrete flotation device.

Google for Mulberry harbour (or harbor), and you'll read about a floating prefabricated harbour of concrete and steel that was built during the Second World War in England and Scotland, and towed across the channel to France, to provide the D-Day invasion force with harbour facilities.

Random link follows:
http://roselli.org/tour/06_2001/167.html

Just an embedded distribution

Posted Sep 11, 2003 13:18 UTC (Thu) by freeio (guest, #9622) [Link]

What you have described appears to be a packaged distribution for embedded systems. Even though the heavy lifting may have been done by others, how is the act of packaging and distributing this a bad thing?

I have on several occasions looked at previous versions of the MontaVista embedded development package, but had no immediate need for it. Sure enough, it was slick, and well-done. I have also approached their sales office for pricing, and was amazed at how much is would cost me to obtain the full package. It was well more than I as an individual would be able to pay. The MontaVista pricing made an opening for someone else to attempt it commercially.

Is this good or bad? I don't know, but it is certainly allowable under the GPL.

On giving back

Posted Sep 11, 2003 16:22 UTC (Thu) by npitre (guest, #5680) [Link] (1 responses)

Just a few links with developer comments:
http://lists.arm.linux.org.uk/pipermail/linux-arm/2001-June/001549.html
http://lists.arm.linux.org.uk/pipermail/linux-arm/2001-June/001551.html
http://mhonarc.axis.se/jffs-dev/msg00809.html
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2002-October/011786.html
See that some of them are not especially recent.
You may of course draw your own conclusions from the above links...

On giving back

Posted Sep 13, 2003 2:11 UTC (Sat) by pimlott (guest, #1535) [Link]

Russell King often comments on this issue, not specifically in connection with Lynux Works. I found some relevant words linked from the above discussion.

On giving back

Posted Sep 11, 2003 19:26 UTC (Thu) by cdmiller (guest, #2813) [Link]

BFD.

If their kernel is the best or really good at what it does it will rise to the top and patches will eventually be stripped out of their fork and included in the main kernel whether they submit or not. If it is mediocre or sucks their work will get ignored and fade into insignificance.

Seems like one of the main reasons for the GPL to me.

- cameron