The answer is both yes and no. The first area of concern is "compatibility." By definition, if there are new functions (via new or different APIs) in a Linux variant then use of those functions creates "incompatible" software relative to the current kernel.org version of Linux. Before concluding that this is a concern, however, we have to answer a couple of fundamental questions: Why did a commercial vendor add this feature or API to the system? And why is a commercial customer of that product considering using it?

The answers should be obvious by now: the features and API were added so Linux could be used in an application where it otherwise it couldn't be used. And the only legitimate reason for a customer of such a product to use that extended API would be because its requirements can't be serviced without it. So while it's true that the resulting application software won't be compatible with the Linux available from kernel.org, consider the alternative: a product development team (and possibly an entire application or market segment) denied the benefits of Linux because it won't meet their requirements.

A second concern is vendor lock-in: Does the inclusion of extensions and their use by customers re-create a proprietary lock-in situation similar to the "bad old days" of proprietary operating systems? The answer is definitely no.

The reason is that the source code for all the API extensions is included in the distribution; the customer that requires the APIs and uses them has the full implementation of those APIs and can look to other alternatives for maintenance and support of that code in the future if the current vendor fails to satisfy.

A second reason is that (for MontaVista's kernel technology and in general for all extensions of market significance) the extensions are independently available as Open Source technology. Typically, this means that the enabling source code is available as patches to the standard kernel.org kernel. So not only is there no lock-in, the switching costs can be very low from the perspective of getting the required APIs integrated into new or different versions of Linux.

Many of the extensions for a particular market segment are becoming de facto standards and are available from multiple commercial vendors. Examples include XFS for streaming media applications, OpenAIS and OpenIPMI for telecommunications equipment, and dynamic power management for mobile handsets.

Summary
The concerns about commercial vendors selling products that "fork the Linux kernel" are not just overblown; analysis shows them to be a red herring. All significant Linux distributions are Linux variants, and none of them are or have become Linux forks. We have shown how even basic commercial support activities require an independently maintained copy (a "variant") of the Linux kernel. Those value-add components (features, internal "-ability" enhancements, and quality improvements) are frequently the critical factor in the purchasing decision and without those values a Linux-based product may not be feasible. So if and when a vendor comes calling, describing competitors' products as "a fork of Linux," ask these hard questions:

• Is YOUR Linux distribution a 100% copy of kernel.org without any changes in source code whatsoever?
• If so, why should I buy it from you?
• If so, how will you maintain it and support me? How can you provide me with integrated defect corrections, without changing the code?
• If code changes to fix defects must first be submitted, accepted, and published by kernel.org, what am I to do in the meantime? That process can be lengthy.
• If your Linux distribution is not a 100% copy of kernel.org, why is it NOT a fork of the Linux kernel and yet the competitor's product IS a fork?

These questions will quickly reveal the truth: any viable Linux distributor, by the very nature of the product and services it is offering, MUST offer a Linux variant. The issue isn't who is or isn't "forking Linux." In fact, it can be argued that any vendor who suggests that a competitor's product is a fork of the Linux kernel has such a low understanding of Linux and system software in general that he should be thrown out immediately in any serious vendor evaluation. These kinds of statements indicate some combination of deep ignorance or deep misinformation under the assumption that the customer is deeply ignorant. Either is a legitimate reason to keep searching for vendors of quality.

Linux leadership requires aggressive innovation and value provision. It requires investment, but not traditional IP investment - it requires Open Source investment. Key elements of any evaluation criteria are the following questions: who is driving and leading advanced Linux Open Source technology for the markets and applications of interest? Who is actively enabling Linux on the hardware critical to that market? Who is innovating the key features needed so Linux can be used in those applications?

These questions are easy to answer through assessment of Open Source projects and their leadership, through source code counts of different vendors' copyrights and check-in log data in the kernel.org source base, through participation and the leadership history at any number of key industry forums, such as OSDL, SAF, and CELF. It's at this level of assessment that leadership, value provision, and true product differentiation become clear.