Linux Standard Base: Enough Support?
By Bill Claybrook
Sys-Con
August 31, 2004
Ask some end users what Linux Standard Base (LSB) is and most likely they either won't know anything about it, or know a little bit but not enough to qualify as understanding what all the buzz around LSB is about. Ask three ISVs and only one will likely understand the implications of LSB for their business. And only a very, very few will say that they have started the process of making some of their applications LSB-compliant.
Are these statistics bad? Yes, they are for ISVs. Although users will benefit from LSB, they are not the direct focus of the Free Standards Group (FSG), an independent, nonprofit organization that is dedicated to promoting the use of LSB and the development of open standards. ISVs, Linux distributors, and system vendors, however, are in the FSG spotlight because they are the parties that will have to boost LSB to give it a favorable outcome and make Linux even more appealing to users than it already is.
Today, all major Linux distributions are LSB certified and LSB conformance testing has become part of the distributors' quality assurance testing. As of July 2004, there were 35 LSB-certified products from 11 companies (almost two-thirds of the products are Red Hat and SUSE distributions) listed in the LSB Certification Register. None of them are ISV applications.
LSB will not create a single Linux operating system. Dirk Hohndel, director of Linux and open source strategy at Intel (and a member of the board of directors of FSG), predicts, however, that it will create a space in which the different LSB-compliant Linux implementations can compete with each other, and the customers (users) can use LSB-compliant applications on any of them. For example, if one of SAP's applications is LSB compliant, it will run on any LSB-compliant Linux distribution.
The overall goal of LSB, says Scott Handy, vice president of worldwide Linux strategy and market development at IBM, is to have a single Linux platform that ISVs write applications to - not a single Linux, but a single interface. Novell's Jeff Hawkins, vice president, Linux Business Office and an OSDL board member, says that LSB faces both technical and political challenges. None of the distribution vendors want Linux to fork (fragment). But, at the same time, they want unique value and a brand that sets them apart from the competition. This is a challenge that LSB faces and some companies may approach it cautiously, though Novell/SUSE fully supports LSB.
The story around LSB is an interesting one. Keeping project team members together was one of the biggest problems throughout the project. By the time the project was three years old, dozens of engineers had contributed to it, and only a few of the original roster were still active participants. In July 2002, many of the Caldera developers disappeared completely, due to a reduction in the company's workforce, leaving the sample Linux implementation in disarray. Engineers were under extreme pressure in many cases - pressure from their peers and from their employers. The LSB project had both effective and ineffective leadership, vendor politics, struggles to survive with competing standards groups, and, in two or three cases, exceptional assistance from individuals and/or organizations (e.g., The Open Group) that helped keep the project on track.
In spite of these issues, the new release, LSB 2.0, appears to be sufficient for FSG to work with ISVs to get them to make some of their applications LSB compliant. Prior to LSB 2.0, some members of FSG were reluctant to push LSB with their ISV partners, fearful that the application certification process would be an unsatisfying experience (for the ISVs).
Why LSB?
One of the motivations for LSB was that for Linux to succeed in challenging Microsoft Windows, some form of Linux standardization would be important. The history of UNIX fragmentation also loomed over the Linux community. By mid-1998, fear that UNIX fragmentation would spill over into Linux drove members of the Linux community to start thinking about a project to prevent Linux fragmentation. UNIX fragmentation had led many ISVs to port to several UNIX variants. They complained loudly, but they did it anyway to remain competitive. ISVs were saying that they would prefer that there be just one Linux port required per application.A Brief History of the LSB Project
The concept of an LSB began to materialize in May 1998. Bruce Perens was the first chairperson and created the name for the project. During his tenure as chairperson, the project made progress, but the structure required by the project did not materialize, and he resigned in August 1998. Three additional chairpersons would follow - Daniel Quinlan, George Kraft, and Mats Wichmann. Quinlan and Kraft, through almost Herculean efforts, served consecutively as the LSB project chairperson from August 1998 to January 2004, when Wichmann became chairperson. All of the chairpersons found that they had to deal with the egos and diversity of opinions of groups of extraordinary engineers as well as the politics of various vendors. After the LSB project was initiated, two or three other groups formed, bidding to take control of Linux standards. Being the LSB chairperson was not an easy job.By 2000, a significant push had begun to incorporate the LSB. In April 2000, Quinlan announced that the LSB and the LI18NUX projects had been joined to form the FSG. As a result, the LSB project began operating as a workgroup under FSG. Scott McNeil was hired as the first executive director and shortly thereafter George Kraft replaced Daniel Quinlan as the LSB project chairperson. By the beginning of 2001, the LSB project was well underway and over the next three-plus years, the project made progress in creating the process for making Linux distributions and applications LSB-compliant.
Today, the LSB 2.0 specification provides an open specification to support development of portable, binary shrink-wrapped applications for the Linux platform. The LSB utilizes some of the source code standards of the POSIX standards and The Open Group Single UNIX specification for many of its behavioral interface definitions.
The LSB specification is composed of two basic parts:
LSB Certification Process for Linux Distributions
While the certification processes for Linux distributions and ISV applications are very similar, there are some differences. The following section on LSB certification for applications addresses the differences. The certification process for Linux distributions requires a demonstration of conformance to the LSB Certification Authority - a vendor or neutral third party.To provide greater confidence in claims of conformance to the LSB specification, the FSG has trademarked the term "LSB Certified" and operates a certification program that can grant the right to use that term only after the criteria of the program are met. Conformance includes passing suites of tests and completing a conformance statement. The requirements for conformance are identified in the LSB Product Standards. There are numerous documents on the Web that describe the certification process in detail.
The process for LSB certification involves four steps:
The supplier of a certified distribution guarantees that the distribution meets all the applicable conformance requirements against which it is certified. Each applicant distributor must complete the Trademark License Agreement and submit it to the FSG before a product can complete certification and be entered into the Certification Register.
After a distribution "passes" the informal tests, the applicant distributor completes a conformance statement. This statement provides the name of the distributor, the name of the product and its version/release information, the processor-specific architecture with which conformance was demonstrated, the name and versions of the test suites used to demonstrate the product's conformance, and the distributor's policy on rebranding the product.
An applicant distributor applies for certification by completing a Web-based registration form. As part of the registration effort, the distribution supplier must select the LSB Product Standard against which certification is being sought. The product standards for Linux distributions include LSB Runtime Environment 2.0 for IA-32, IA-64, PowerPC 32-bit, PowerPC 64-bit, S/390, S/390X, and 64-bit AMD.
Formal testing is the next step. It's a self-test activity in which the applicant submits results to the Certification Authority for audit. Submitted results must contain full journal output from an uninterrupted execution of the complete set of applicable tests. For Linux distributions, these tests include LSB runtime environment and LSB internationalization environment tests.
The final step in confirming Linux distribution compliance occurs after all the required information has been submitted to the FSG and/or a number of Web locations. When the information is determined to be complete and accurate and the LSB Trademark License Agreement is in place, the distribution company is notified and the details of the certified distribution are entered into the Certification Register. Certification is valid for a defined period of time.
LSB Certification Process for Applications
The overall process of certifying applications is basically the same as it is for Linux distributions, with a few differences. The requirements for conformance identified in the LSB Product Standards differ for Linux distributions and ISV applications - for example, the sets of test suites for applications and distributions are different. The Product Standards for applications include LSB Version 2.0 Application for IA-32, IA-64, PowerPC 32-bit, PowerPC 64-bit, S/390, S/390X, and 64-bit AMD.The guidelines for LSB-compliant applications include:
The Future of LSB
There are several questions/issues surrounding LSB and its future. One of these involves the difficulty involved in certifying ISV applications. According to Intel's Hohndel, normal user-level applications, such as accounting or line of business applications, should have few, if any, problems becoming LSB compliant. The closer an ISV's application code is to the operating system, the more difficult it is to certify the application. ISVs, such as Oracle and Veritas, that work at the system interface level and have their own kernel drivers may have difficulties making some of their applications LSB-compliant. For example, Oracle's DBMS is an application that is highly tuned and needs to work with a specific kernel version. On the other hand, most of Oracle's other applications can be made LSB-compliant with few, if any, problems.One of the primary reasons for the creation of the LSB project in mid-1998 was to prevent Linux fragmentation. According to Hohndel, people will continue to talk about Linux fragmentation. There is no easy solution that does away with the problem because fragmentation is one of the inherent rights associated with open source projects. From a commercial viability point of view, the LSB, along with LSB-compliant applications, should make fragmentation a nonissue.
During the past two years, there has been a lack of buzz around LSB. One reason for this is that LSB 1.3 was not sufficient to get application certification working. Some companies refrained from pushing LSB certification with their ISVs because they were concerned that the ISVs might not have a successful experience. But these same companies believe that LSB 2.0 is much better and will likely promote it with ISVs that support Linux. IBM's Handy says that his organization just went through the certification process with some ISVs (both open source and proprietary) to help them understand the process and the value that LSB compliance brings to them, as well as to IBM.
What would happen if large numbers of ISVs suddenly decided to try to become LSB compliant? Would the FSG have the resources to deal with them? LSB certification is very much a do-it-yourself process. The instructions and necessary tools are provided by FSG and by the LSB project via the Web. LSB 2.0 scales well enough to handle many concurrent applicant certifiers. Another plus is that The Open Group is the certification partner with FSG.
OSDL's CEO, Stuart Cohen, is a strong supporter of LSB, and he says that there is frequent communication between him and Jim Zemlin, the newly appointed executive director of FSG, just as there was between him and Scott McNeil. Cohen says that OSDL would prefer that the LSB project move at a faster pace because they are a key part of the industry ecosystem and getting ISV applications to be LSB-compliant is important to the success of Linux, with users being the beneficiaries.
My perspective is that LSB is positioned to succeed. The eventual competition between Microsoft Windows and Linux for the market share that UNIX will drop over the next several years will push the Linux community toward LSB compliance. Microsoft has been running ads in Europe promoting Linux fragmentation as a problem for ISVs and users. Novell's Hawkins says that LSB is necessary to combat Microsoft FUD. IBM's Handy says the Microsoft ads show that Microsoft does understand the issues. IBM's Software Group is one of the largest, if not the largest, providers of software on Linux and has over 275 products shipping on Linux. It ships the same binary across multiple compliant distributions for all products.
Conclusion
After more than six years of effort by various LSB project teams, LSB 2.0 is available. Most industry experts believe that LSB 2.0 is the first release of LSB that is sufficiently complete for ISVs to begin making their applications LSB-compliant. It is my belief that LSB is necessary for Linux to compete head-on with Windows for dominance in the enterprise over the next several years.The real question about LSB is support. The vendors and nonprofit organizations of the combined memberships of FSG and OSDL all say they believe in the importance of LSB. They must support it (including funding the FSG) and encourage their ISV partners to become LSB-compliant. Today, there is only one large ISV, Computer Associates (some consider IBM with its large software offering on Linux to be an ISV), on the combined membership lists of FSG and OSDL. More ISVs need to be added and added quickly, because without ISV support the full value of LSB will not be realized.
Copyright 2004