|
Previous Table of Contents Up Next Variations on Open Source: Gated Communities and Internal Open SourceSometimes a company is not willing or able to relinquish all control of the source code it has written. It may be that sale of the software is too important a part of its business. Or it is unwilling to give up the intellectual property (IP) used in the software--or it cannot because it uses another company's IP that it only licenses. Whatever the reason, it chooses not to open source its code. There are two important variations on open source that the company can consider in order to get at least some of the benefits of collaborative development. The first is to share only with people or companies that agree to a license that lets them see the source code but that strictly limits what they can do with it. The other alternative is to keep the source code totally within the company, but allow access to it by the company's developers who are working on other projects. Both options reduce the size and scope of the potential community but can still provide additional value. Gated communitiesOne of the hallmarks of open source is that anyone can redistribute the code, with or without changes, to anyone else. This is not so when the source requires a special license that restricts the distribution only to other licensees. For example, from 1975 until 1992 anyone wanting to access the source code for the Unix operating system was required to purchase a license from AT&T. Many organizations relied on the Unix sources distributed by the University of California at Berkeley, but they all were supposed to have an official Unix license from AT&T. It was only after 386/BSD was released in 1992, followed by releases by both the NetBSD and FreeBSD projects in 1993, that source code for a full Unix system became freely available as open source. A source license can be used to create a gated community: Anyone agreeing to it is in the community, and anyone who does not is left outside the gate, unable to see and use the source code. This can be attractive to the company that wrote the source code because it can still sell the software and retain all of its IP. Whether this is attractive to outside developers depends on the other license terms. The most restrictive source licenses only allow a licensee to look at the source code--a licensee cannot modify or redistribute it. Even this little access can be useful if you are building other software that must interoperate with the licensed software. The source code essentially provides additional documentation and can aid debugging. This is what Microsoft offers with its Shared Source program for its Windows operating system. Those few companies that qualify can use the source code to help them better understand Windows in order to debug or tune their own hardware or software. A less restrictive source license might allow a company to modify the source and use it internally, but not distribute it to anyone. Only when the license allows redistribution is an open-source community possible. For example, Sun's former Free Solaris Source License Program allowed anyone who had signed the license to view and modify the Solaris 8 source code. Licensees were allowed to distribute their changes only to other licensees via a Sun secure website that included mailing lists for discussing the source code.1 Licenses of this type often make a distinction between commercial and research use. Commercial use is when a company takes the source code and modifies it to create a product it then sells or uses internally for a production system. Such commercial use may require an additional license, possibly including royalty payments to the original author of the source code. Research use involves no sales or other commercial gain, and the distribution of binaries to anyone may be allowed. The Java community is a good example of a gated community. It is an open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits. Java technology was originally created by Sun Microsystems and released under the Sun Community Source License (SCSL). Decisions are made using the Java Community Process (JCP), which has evolved from the informal process that Sun used beginning in 1995 to a formalized process overseen by representatives from many organizations across the Java community. The original reason for using a gated community was to maintain the compatibility of different Java implementations--write once, run anywhere. Now that Java is established and seen as a standard, the JCP is beginning to allow true open-source Java development. The Jini project is another example of a gated community. It uses a variant of the SCSL that allows free commercial use and has a more democratic governance structure. In fall 2000 Hewlett-Packard's printing and imaging division launched what it calls the Collaborative Development Program (CDP), a secure web-based development environment that links HP's worldwide employees, business partners, and customers to collaborate on software development projects. As of early 2002, the program hosted over 350 projects and 3000 users; approximately 10% of the users are external to HP. Forty-five external companies are developing projects with HP using CDP. Some of the benefits of joining a gated community include using the source code as additional documentation, enhanced ability to find and fix bugs, ability to make local modifications, and ability to obtain and share modifications with others. The disadvantages can include the tainting of your developers by their seeing proprietary code, licenses that do not allow modifying the source code, and licenses that do not allow you to share changes with others. The company that originally created the software can benefit from additional sales due to the extra value customers perceive from having access to the source code, assistance in finding and fixing bugs, customer porting of the code to additional platforms, improvements that can be distributed to other customers, and receiving better feedback from customers. Internal Open-SourceThe source code for most proprietary software is usually seen only by the team of developers assigned to work on it. Some companies limit which employees are even allowed to look at a program's source code, and most companies severely control who can modify source code. Some companies do have code reviews where people not on the team look at the code, but their involvement is generally limited to a critique of the code. It can be to a company's benefit to open up the source code to everyone within the company. Access to a product's source code provides documentation to those developing other products that must interoperate with it. It can help in testing and fixing bugs. It can facilitate code reuse. In short, all of the same benefits that outside companies can get by being able to see the source code are available with internal open source. Even when sharing totally within a company, proposed changes must still be approved by the project's core team or other people who have earned their trust. We refer to such projects as internal open source, but others sometimes use the term corporate source . Sharing source code within a company is much simpler than sharing it with those outside. Internal use requires no software licenses, just putting the source on some internally accessible file server. Of course, so far we're speaking only of the technical aspects of sharing--it may take a very big shift in mindset to open up a project's code to developers in other parts of the company. In fact, one of the biggest benefits might be increased communication between different parts of the company. The focus on creating communities is a major difference between internal open source and other programs many companies have to encourage software reuse. Software reuse has at its core the idea of a library of reusable software components maintained by a code librarian. The code is usually seen as being static--contributed by a developer on one project for use on unrelated other projects. Software reuse projects often fail by not addressing social and political issues inside the organization. Internal open source must also overcome similar social and political obstacles, but they are faced more directly in working to build a community of developers and users to collaborate on an application that the community is all interested in moving ahead. If your company has a software reuse program, to make it more successful consider using open-source principles to build communities around the various components and frameworks. Because internal open source takes place totally inside a company, there is no way to know just how many companies are applying open-source principles to their internal development process. Both VA Software, with their SourceForge product, and CollabNet, with SourceCast, are companies committed to open source that make their living by selling collaborative software development tools to other companies. Although many of their customers may only be seeking assistance for geographically distributed project teams, others are no doubt taking advantage of the ability to involve people outside of a project in its development. Hewlett-Packard started a Corporate Source Initiative to use open-source practices internally in June 2000. One of the major goals of this program is to increase the technology transfer from HP Labs to the rest of the company. By using the community building aspects of open source, HP hopes to build a stronger community within HP Labs and then extend that community to include other developers in the rest of HP who are working on products, infrastructure, and corporate operations. By early 2002 it had about 1500 registered users working on about 30 projects, all of which were research projects not tied to any HP product. Researchers at HP Labs have written about a variable approach to open source they call progressive open source (POS) to describe the range of ways a company can use open-source development methods: traditional open source, gated communities, and internal open source.2 IBM uses tools from VA Software--SourceForge Enterprise Edition--to host an internal-project, open-source site called the Internal IBM Open-Source Bazaar , where any team can do open-source development within IBM. The tool provides a source-code repository, mailing lists, source-code control mechanisms, and license management. The site supports hundreds of projects and thousands of developers working on open-source projects that IBM doesn't want exposed to outside parties. IBM is one of about 50 companies that use SourceForge Enterprise Edition for their internal open-source projects. Sun Labs set up a very similar program inside Sun called OpenProject, starting in December 2001, with the twin goals of helping with technology transfer from Sun Labs to the rest of Sun and providing a home for small, unsponsored projects to encourage innovation. In May 2002 the scope of OpenProject grew with the addition of a number of groups from Sun's Enterprise Services organization that wanted to build communities around the development and use of internal Sun tools. These tools include the various applications that are used internally by Sun field engineers and customer support to install, test, and maintain Sun computers. The aim is to enable the worldwide shared development of these tools, as well as to create forums where Sun employees can locate the tools they need and discuss how to best use them. By March 2004 there were over 800 registered users of OpenProject working on over 300 hosted projects, most of which were internal tools. Internal open-source projects need to be nurtured just as all open-source projects do. In fact, they may need even more support from managers and executives because the people involved in them do so as part of their job and, although the project may benefit the company as a whole, their involvement can be seen by their immediate manager as taking too much time from their assigned job.To manage and guide this internal tool development effort, a special Technical Council was created with representatives from organizations throughout Sun. This Technical Council is responsible for locating existing tools and working with their developers to contribute their source code to OpenProject, for identifying gaps in the existing tools and developing new tools to fill them, for pointing the community to what is cool and identifying the best-of-class tools, and for encouraging groups and engineers throughout Sun to work together. Done correctly, internal open source allows a company to leverage the work of all of its employees, to eliminate duplicate work, and to encourage innovation. The same open-source principles come into play whether the potential community is the entire Internet or just a single company's intranet.
|
|||
|
|
