Innovation

Digg This!

Page 2 of 3   « previous page   next page »

What Is a Fork?
We've now covered enough of the basics of Open Source Linux and commercial product development requirements to discuss the risks of a fork of the Linux kernel.

First, what is the definition of a "fork" in software?

In its most distilled form, a fork is any version of source code that is different (modified) from the master copy. By this definition, every time anyone, anywhere, makes a copy of Linux and begins to make modifications, they're creating a fork. In this sense, Linux is forking literally thousands of times a day.

Pragmatically however, this is not the common interpretation of the word "fork" as it applies to software in general and to operating system software in particular. A fork is generally construed as:

• A long-lived derivative of the master version of source code, and
• A derivative that's not intended to "resynchronize" with the master source code, and
• A derivative of some significance in the marketplace.

Hence, short-lived derivatives that precede the submission of the changes back to kernel.org aren't forks. Commercial companies embedding Linux inside a product that have developed a derived version with code corrections and/or enhancements that the company doesn't submit back to kernel.org is not a fork. Such a derivative version doesn't have significance to the broader operating systems marketplace; it's a private version of no broader significance.

Similarly, a derived version of Linux that's frequently resynchronized with the evolving kernel.org source code base is not a fork. Almost every commercial distribution of Linux falls into this category. Some new entrants into the Linux distribution market are striving to label such distributions "a fork of Linux." Such claims are just inaccurate, they're disingenuous for the reasons cited above: it's only through such approaches that serious commercial distributions targeting specific markets can be developed and delivered...and those making such assertions know this. The claims are useful for purposes of creating fear, confusion, and doubt, and, in general, slowing down market adoption while such companies strive to catch up with their own distribution products.

Commercial Linux Technology Leadership
Let's explore the details of commercial Linux distribution in more detail. We particularly want to consider the situation of a company using Linux as a commercial operating system platform embedded in products in a market with significant requirements that extend beyond what the Linux from kernel.org is capable of.

MontaVista's approach to this situation is relatively simple. Here are its key strategies:

• Identify the key market (or application) requirements that are underserved by standard kernel.org Linux.
• Identify any extant Open Source technologies already developed or in development but not yet integrated into kernel.org Linux, and if available, assess their maturity, their state of ongoing development and support, their state of adoption by other industry players, and their potential for adoption into kernel.org Linux.
• Either adopt an extant technology or begin developing a new technology. When developing new technology, use Open Source development models to (1) maximize community leverage, and (2) maximize the potential for both broader adoption and use and, ultimately, integration into kernel.org source code.
• Aggressively commercialize the feature in MontaVista Linux products. Provide this capability as a high-value, fully supported and maintained component in the overall set of value components of the complete MontaVista Linux product.

Obviously MontaVista maintains private source code copies of Linux. These are either a new product version in development, an actively sold and supported version undergoing ongoing maintenance and minor enhancement (primarily new hardware support), or an obsolete version that may still be under special support to customers requiring "long lifecycle" support.

MontaVista aggressively integrates advanced capabilities not yet integrated into kernel.org into the MontaVista Linux product. In many cases these are capabilities developed primarily by MontaVista, using Open Source development methods. Sometimes these are capabilities developed by others, with or without active MontaVista participation or contribution. In all cases, the following are true:

• The technologies are developed and maintained as independent Open Source components.
• The technologies are promoted for inclusion back into kernel.org source.
• MontaVista continues to move its own product line forward with new versions of MontaVista Linux, each of which moves forward to a more recent baseline of source code from kernel.org (and many other critical components, such as gcc, gdb, glibc, etc.).

To clearly distinguish how such Linux variants form a true fork of the Linux kernel, let's describe a hypothetical "real fork" scenario.

Linux is developed with a first-order focus on server and desktop computing. Requirements from more specialized areas of computing aren't given the highest levels of priority. Such areas include consumer products, telecommunications equipment, mobile handsets, and mil-aero. When implementation or optimization choices conflict with requirements from different application segments, servers and desktops typically (and arguably, appropriately) win out.

Given this backdrop, it's possible that an individual or a group (for example, an industry consortium) could build, market, and maintain a separate, specialized version of Linux. Let's say, for example, several large mil-aero firms decided to cooperate in developing and maintaining a "mil-aero Linux." To do this they'd choose a starting point set of Linux code from kernel.org and publish this code independent of kernel.org (say, www.mi-aero-linux.org). They'd then begin the process of evolving this code base to meet better the requirements of the mil-aero equipment market. The stated intention would be to make long-term design, content, and management decisions to optimize the code for those requirements. In doing so, the decision would be to diverge henceforth from the kernel.org source base due to the very different design objectives and specific code evolution being planned.

If such a development occurred, and the project moved forward successfully and the resulting software gathered significant adoption and use...THAT would be a fork of the Linux kernel.

It would have all the attributes of a true fork: a long-term variation; no intention to resynchronize with Linux proper; no attempt to get the capabilities in the fork back into Linux proper; and fielding some significance in the overall operating system market.

Legitimate Concerns
To date, no true Linux fork has arisen. So with respect to the Linux variants that aren't forks of the Linux kernel, are there legitimate concerns about them having "differences" from the kernel.org source code?

Page 2 of 3   « previous page   next page »