Home · About · A-Z Index · Search · Contacts · Press · Register · Login

An Open Source Strategy for the Open Group

How to Join

You are here: The Open Group > Open Source > The Open Group & Open Source > An Open Source Strategy for the Open Group

Draft, for comment ... comments to os-strategy@opengroup.org

Introduction

The Open Group is faced with challenges and opportunities regarding Open Source software. Foremost is the organization's responsibility to guide its members in use of, and participation in, Open Source. Secondarily, as an organization we must catch up: we couldn't have known that Open Source would be this successful, and it brings profound changes to our main areas of practice: Open Systems and Standards. We must now fully integrate Open Source into our operation. If not, it's time to change the name of our organization.

Justifying Our Participation in Open Source

First, it's necessary to justify why we, or our members should participate in Open Source at all. Any Open Source participation must be grounded in a clearly documented benefit for the membership in general. We don't participate in Open Source for subjective reasons. We do it only when we can show that our members will be able to better operate their information systems facilities, will be able to spend less, or get more functionality or better service.

Is Open Source Good for All of Our Members?

Open Source is thought of in economic terms of as a nonrivalrous public good. Nonrivalrous means that when someone uses it, that does not diminish its utility to anyone else. In general, the world benefits from the creation of any nonrivalrous public good, and this is an important justification for our participation in Open Source. However, we must keep in mind that while the world benefits in general, some may suffer. Consider the plight of the producer of a proprietary product who suddenly finds himself in competition with a public work of similar functionality but with no inherent profit motive. This is not limited to computers; there are examples in transportation and other fields.

This is the controversial aspect of Open Source for our membership. While the membership in general will benefit from it, it brings a painful transition for our vendor members. The main agent in which their businesses are changing is the commoditization of their products. In the case of software, a good Open Source implementation with low or zero cost obviously reduces the appeal of a similar proprietary solution. In the case of hardware, the commoditization happens because Open Source operating system implementations are not limited to a particular hardware vendor, and tends to conceal the differences of the underlying hardware with software that operates identically across many different hardware platforms.

But how is the commoditization brought by Open Source different from that produced by open standards? There are idiosyncratic differences between software implementations of paper standards, and of course, their various vendors have put much effort into their individual differentiation. In contrast, Open Source operating systems and applications tend to come from a single code base, and thus tend to act identically across all platforms.

Vendors collaborate in open software standards to create markets for their software and hardware. In contrast, collaboration in Open Source satisfies the need for software, and may make it possible for a particular application to be satisfied with commodity hardware.

Thus, Open Source operating systems tend to treat hardware as an anonymous provider of compute cycles per dollar. This reduces vendor margins, as all vendors struggle to find new ways to differentiate themselves and compete in a newly commoditized market. This is good for the majority - the customers, and bad for the minority - the vendors.

The most successful vendors will be the ones who simply move the value of their businesses elsewhere - for example to services. A vendor can move to higher-level proprietary software, but the functionality of Open Source tends to increase into those higher levels, thus the proprietary advantage may be limited in time.

Thus, we must understand that Open Source forces uncomfortable change upon proprietary software and hardware vendors, killing a niche that formerly provided extremely high margins. 70% margins on the hardware that enables RISC based Unix systems have been the norm until very recently, and one company that has been able to achieve a significant monopoly advantage in software has reported an annual profit margin of as much as 40%. But sorry, vendors! The easy times are over. A market that embraces Open Source is a highly competitive market, and you'll have to work harder for the customer.

KEY POINT: Although the Open Group does not plan to make proprietary versions of its software available, we must recognize that some of our members are in the proprietary software and hardware business and may harbor mixed feelings regarding Open Source.

Different Manifestations of Open Source

It's important to recognize three different manifestations of Open Source and the different benefits they provide:

Manifestation 1: Open Source Methods

Open Source Methods are a set of tools for managing an extremely loosely coupled development team. The Open Source developers on a particular project often have not met except through online communication, do not share an employer, may not reside on the same continent, and may not even share facility in a common language. These developers have created a tool set to manage their collaboration, and have in general demonstrated that extremely valuable projects can be carried out using resources and methods that would previously have been considered inadequate to the task.
Most of their coordination is carried out using very simple textual communications in pre-multimedia-style email. An important area of study is how to achieve something close to the motivation of Open Source developers in proprietary software operations. Open Source developers are so highly fulfilled by their Open Source work that many of them will carry it out on their own time, or will accept lower salaries or fees if they are allowed to work on Open Source. Some of the things that motivate them can be transferred to proprietary operations; others are unique to Open Source.

Open Source methods can greatly benefit non-Open-Source operations. Large companies share many of the problems of the Open Source developers: geographical distribution, local differences in business direction, lack of a common language. In addition, large businesses are plagued by duplication of effort, loss of intellectual property and expertise related to their own products, and poor personal fulfillment among their engineering staff, which reduces their efficiency and may lead to loss of key employees along with their expertise. These issues are addressed by the Open Source methods.

KEY POINT: an important area in which we can bring benefit to our membership is by helping them integrate Open Source methods into their non-Open-Source operations. This Inner Source program will assist them in developing and retaining the greatest utility from their own intellectual property, reducing duplication of effort, and increasing employee fulfillment.

Manifestation 2: Open Source Licensing

The particular form of covenant between collaborators embodied in Open Source licensing seems to have resulted in more successful collaboration. Witness the replacement in the market of consortia projects such as Taligent and Monterey with Linux, CDE with GNOME. The nine basic tenets of Open Source licensing tend to create a fair partnership of peers, in which all peers are confident to do software development even though they are participating with their most direct competitors. There are two important factors in Open Source partnerships that should be considered:

Power of circumvention:

Open Source developers can circumvent any other Open Source developer who tries to block them, because they have the same rights to the Open Source code as that developer.

Elevation of Engineering over Marketing:

Open Source partnerships tend to make it possible for engineering decisions to supersede marketing ones. This is probably related to the power of circumvention, above. This is important for two reasons:

Marketing Has No Crystal Ball.

Strategic marketing executives are attempting to plan the unforeseen aspects of customer demand, engineering developments, and competition. There is no reason to believe that as a group they would be any more accurate in their forecasts than professional stock-pickers, indeed there is less analytical basis supporting their field.

The marketing mechanism of global Open Source community is best described as a massively parallel drunkards walk, filtered by a Darwinistic process. This looks more like research than conventionally driven development. And like research, it is better able to take advantage of serendipity. But, also like research, it poses challenges at the interface of the free-form Open Source developers to the more schedule-and-goal-driven business environment.

Vendor Differentiation May Hurt

The Overall Market Marketing partnerships are dominated by each individual marketer's goal of doing well for their own company. Thus, they may result in market-losers like the historical decision of the X Consortium to have no canonical user interface toolkit, in order to foster differentiation between vendors. This one decision handed much of the Unix desktop market to Microsoft Windows. The development of KDE and GNOME shows the Open Source community's response to the X decision.

Where can we offer value to our members regarding Open Source licensing? Most of our members are attempting to use it or are studying it. All of them start with a legal review, and this isn't a topic that makes attorneys feel confident. When attorneys new to Open Source have access to another attorney who is experienced with Open Source licensing, especially the GPL, the process goes much more smoothly. One way we can help is to produce a reference for attorneys, or programs for attorneys at our meetings.

In addition, there is a good deal to be gained from coordination of Open Source licensing across all of our members, in a similar way to the standard licensing that I (Bruce Perens) developed for the HP GELATO consortium. One problem with the 40 or so OSI-certified Open Source licenses is that they aren't necessarily compatible with each other in their terms. The Open Group can define a standard set of three of four Open Source licenses for use by their members. These licenses should be compatible with each other, but should address a range of business purposes. Each of the licenses should be compatible with all of the others, so that code can be mixed. Standardization on licensing would allow Open Source code created by all of our members to be mixed. We could exercise a good deal of leadership here, and the result might propagate outside of our membership as well.

Manifestation 3: The Open Source Community

The Open Source community is a very-loosely-coupled group of individuals, companies, and organizations that are united only in the use of a particular paradigm of software licensing. Among the individual open source developers, there is also a common (though not universal) set of ideals. The value of this community is that:

· They have created a large body of software available for all to use.

· They are a tremendous corps of software developers willing to contribute to projects that they perceive as being for the public good.

· They are the Open Source experts for their various employers, and thus it's important for us to secure their recommendation.

KEY POINT: Part of our Open Source strategy must be means of engaging the Open Source community in ways that provide value for our members.

How We Deal With The Three Manifestations of Open Source

KEY POINT: We can divide every project that approaches Open Source into method, licensing, and community. For example, Open Pegasus is under Open Source licensing, does not currently have engagement from the general Open Source community but maintains its own very specialized community, and may be developed using Open Source methods. This could indicate problems to be addressed, or simply perceptions about the role of the project.

Open Source and Security
We should be careful in our proposals to use Open Source as a vehicle for improving security. It's probably so that Open Source provides more of an opportunity for break-through thinking regarding security. Open Source evangelists like to point out that with many eyes, all bugs are shallow. There's also the fact that Open Source has more programmers outside of the developing organization examining software for benevolent reasons rather than hostile ones – the so-called white-hats vs. black-hats ratio. But there is no denying that laying out the source code for all attackers to peruse can make the initial attacks even easier. However, The ultimate test of security is for software to be secure even though it is entirely known to the attacker, and this is a test that will always be taken with Open Source software before it's ready. Thus, initial security failures of new Open Source code are to be expected. It's probably the case that Open Source software starts out being less secure than proprietary, and becomes more secure than proprietary software as exploits are revealed and repaired.

The dominant languages used for Open Source development are older and lower level ones, like "C", which are prone to a set of exploits based upon memory boundary violations, and which do not provide adequate facilities for sandboxing or detecting tainted data. Thus, popular Open Source software comes with its own security problems.

KEY POINT: Open Source may be an effective mechanism for the development of security architectures. It's more difficult to say that a particular Open Source implementation is secure.

Strategy

I propose that five special interest groups be created within The Open Group, to deal with each of the three different manifestations of Open Source and how our organization should engage with them, and in addition with the special issues of standards, certification, and business use of Open Source.

Special Interest Group 1: Inner Source: Learning from Open Source Methods

Open Source communities share a number of problems with large companies because of their size and distributed nature. Inner Source is the use of Open Source methods, without Open Source licensing, inside of a company. These are the sorts of problems that can be addressed through an Inner Source program:

Retention of Intellectual Property:

Too often software "goes offline" in a way that is difficult to recover once the engineers who are responsible for it go on to other projects or leave the company.

Retention of Metadata:

Software licenses and other data related to software is often stored separately from the source code, and thus information about what software is licensed from other parties and what the terms of those licenses are tends to get lost. This can make it difficult to reuse software.

Duplication of Effort:

Often projects within large companies develop software without knowing that similar software already exists within the company.

Retention of Expertise:

Software is much more useful when you have access to the people who are expert in it. It may take months to bring a new employee up to speed on an existing piece of software.

Employee Fulfillment:

Open Source developers are so motivated about the projects they work on that they often donate their time without pay. Don't you wish your employees were even half that motivated about their assignments? Fulfillment may mean that the employee is less interested in financial incentives and less likely to quit.

Code Quality:

Most code is not written for broad scrutiny, and it shows. Code-reviewers tend to be on the same team as the developer, and may be as few as one reviewer.

Inner Source teams make use of the tools of the Open Source community in their software development. The most important tool is the source portal similar to SourceForge, but for internal company use only. This tool provides browsing and distribution of source code, including version control, and groupware mechanisms to coordinate developers and users. An Inner Source portal provides secure access to source code by company employees, so that they can browse for existing company code with which to leverage their projects. In addition to the software tools, there are some process changes:

· Transitioning projects to be available across the entire company.

· Developing procedures to restrict access to code that must be restricted even within the company, such as partner code with trade-secret issues.

· Training employees to write reusable code that will be seen across the company.

· Training employees to reuse code from other parts of the company.

· Treating programmers with expertise on particular software as functional departments available to more than one project within a company.

· Training employees how to associate meta-data such as software licenses with the source-code, so that it can be found later on.

· Establishing an engineering newspaper within large organizations so that engineers have some idea what other engineers are working on and can be expected to recognize synergies when they come up.

These are the expected results:

Intellectual property is better retained because it is available in a well-organized fashion, in one place that is accessible to the entire engineering staff of the company. The system retains information on who has submitted code to a particular project, and thus what employees have expertise in that code.

There is less duplication of effort because engineers have an easy way of searching for similar efforts.

A community of respect develops within the company because an engineer's work is visible to, and valued by, a much larger part of the company. Individual employees become more valued across the company for their expertise in a particular problem. This sort of community of respect is a major motivator in the Open Source process.

Code quality improves because engineers have the expectation that many people who are unfamiliar with their project will read their code and may attempt to use it.

Meta-data about code will be better retained because there will be more of a consciousness that it is necessary for the use of code in other parts of the company.

I am proposing that the Open Group develop an interest group within the organization on transitioning the use of Open Source methods into our various proprietary operations. This interest group will present training programs at our conferences, and will develop a textual guide on internal use of Open Source methods. The Open Group will adopt these same methods for its consortium and Open Source projects, and will maintain a GForge (next-generation SourceForge) or similar portal for its own projects.

Special Interest Group 2: Open Source Licensing

Most of our members are currently pursuing or evaluating some Open Source involvement, either use or participation in a development community. In just about every case, their corporate attorneys are assigned the project of evaluating Open Source licenses. This is not easy for the attorney. The licenses are substantially different from the ones they are used to dealing with, and present many new questions. Thus, our members would be well served if Open Group could convene an interest group on Open Source licensing for corporate attorney participation. This group would include presentations by Open-Source-experienced attorneys, perhaps including:

· Scott K. Peterson (HP)

· Mitchell Baker (Mozilla)

· Larry Rosen (OSI)

· Daniel Ravicher (Patterson, Belknap, Webb & Tyler LLP)

· Eben Moglen (FSF, Columbia U.)

· Tony Stanco (GWU)

The programs would allow attorneys entering Open Source licensing to more rapidly come up to speed. The interest group would also provide a forum for continuing participation in evaluation and deployment of Open Source licensing.

I propose a project for that interest group: to come up with a set of licenses for use on Open Source development by the Open Group membership. The goals of those licenses would be:

Reduction in the combinatorial problem of deploying some 40 different Open Source licenses.

Establishment of a small set of licenses that are all compatible with each other, so that projects can be mixed.

Identification of a range of licenses within this set, roughly from least to most restrictive, that implement a range of Open Source business plans.

Standardization within the Open Group membership on this range of licenses, so that all Open Source work done by our members has compatible licensing, across all of our various companies.

Compatibility with a broad range of existing Open Source projects, so that our members can take part in work under most or all of the existing Open Source projects while complying with our standards.

The licenses I recommend, from similar work for HP's GELATO consortium, would be:

A BSD-like license.

Least restrictive, can be integrated into proprietary software with impunity.

A LGPL-like license.

Can be integrated into proprietary software, the Open Source component maintains its "free" status while not placing restrictions upon the proprietary elements.

A GPL-like license.

Embodies the share-and-share-alike quid-pro-quo of the GPL. Can be used to protect revenues from a parallel proprietary licensing track. Keeps your competition from running away with your product in a proprietary form that you can't match.

These licenses need not be identical to the BSD, LGPL, and GPL, but should be compatible with them in their terms. While it may be in the Open Group's interest to propagate GPL-like terms in some cases, it's probably not in our interest to distribute the GNU manifesto contained in those licenses. Not because we object to it, but because the argument that it generates might get in the way of our efforts.

I would like to suggest that this group explore whether it would be desirable to add patent-mutual-defense terms to Open Source licenses. This is important to maintain the viability of Open Source development, but may present a problem for some of our members who hold dear their software patent revenues.

This group should also consider legal issues affecting the future viability of Open Source, and the policies our companies should adopt regarding those issues.

Special Interest Group 3: Engaging the Open Source Community

Because Open Source has become the forefront of Open Systems, the Open Group must engage in it, or lose our viability as an organization. Thus, I am proposing an interest group in Open Source Community Engagement. This group will be concerned with:

Promotion of the Open Group within the Open Source community as a force for that community's benefit - which will require at least a partial reversal of our current perception.

The release of Open Group projects into the Open Source community, when appropriate. For example, this group could be charged with expediting the DCE release that has been held up for two years.

Coordination and facilitation of the participation of Open Group membership in Open Source projects. When an Open Source project is important to the membership in general, and we want to spend money on it, it probably works better for the members to coordinate their spending than for them to go at it individually and perhaps at cross purposes to each other.

Representation of the Open Source community within the Open Group.

The projects I am recommending for this group are:

Establish an "OpenForge" portal for The Open Group, where all of the various Open Group projects that are available in Open Source will reside. This portal could also be expanded to host deserving Open Source projects on the outside.

One problem that the Open Source community is presently facing is that the owner of SourceForge is having financial problems, and there's no guarantee that whoever eventually purchases it will be viewed well by the community. Thus, an organization-hosted portal similar to SourceForge would be appreciated.

Establish an information site concerning Open Source and The Open Group's participation in it - including participation by individual members. This will have two purposes: 1) a resource for companies wishing to participate in Open Source and perhaps desiring our services to assist them. and 2) a public relations vehicle for communicating to the Open Source community our intent and participation.

Determine what software we own that is currently not Open Source, whether it should be released as Open Source, and what stands in the way of that release. Drive the release process. Participate in new project planning with regard to Open Source.

Create a position for an Open Source representative on our steering committee, similar to the position for ISVs.

Special Interest Group 4: Standards, Certification, and Open Source

Open Standards are a major mission of the Open Group, and thus we should concern ourselves with the interface of Open Source and Open Standards. We have participated for some time in the Linux Standards Base project of the Free Standards Group, and have donated test suites to that project.

I am proposing a special interest group with this mission:

Assure that Open Source, including the projects of individual Open Source developers, can participate in Open Standards, and do participate.

The projects I am proposing for this group are:

Encourage standardization groups that deal specifically with Open Source, such as the Free Standards Group, with continued sponsorship.

Assure that Open Source developers can participate in standards that are operated or facilitated by the Open Group, including the certification programs operated for those standards. This may require a special rate structure or coordination of corporate sponsorship for the Open Source project to go through certification.

Promote broad certification of Open Source software by encouraging certification of a publicly available and redistributable version of an Open Source program, rather than a particular vendor's instance of that program. This will allow multiple Linux vendors to coordinate their activities on certification, so that a larger collection of Open Source becomes certified than any one vendor would achieve on their own.

Facilitate similar activities in other standards organizations.

Produce educational material regarding the issues of standardization and Open Source, including activities that are potential blockers for Open Source participation in standards, such as the inclusion of RAND software patents within so-called "open" standards. Establish a position for The Open Group upon these issues.

Special Interest Group 5: Fulfilling Business Requirements with Open Source

The Open Group represents both vendors and members who wish to employ Open Source software in their businesses. I propose a special interest group with the following missions:

Investigate certification or validation of Open Source as being suitable for business use, so that business users can have increased confidence in it. This would include a security code review and an assessment of general code quality.

Identify Open Source projects that are of interest to business, and report to the membership on them. Determine whether it is in the membership's interest to sponsor or otherwise encourage those projects, propose sponsorships to support further development to The Open Group, and coordinate outside sponsorships.

Facilitate the meeting of Open Source developers and their business users. Create a liaison group between business users of Open Source and the Open Source developer community, so that the two groups can discuss future planning for Open Source development.

Bruce Perens, Perens LLC

Draft, for comment ... comments to os-strategy@opengroup.org

Home · Contacts · Legal · Copyright · Members · News

Print this page