Understanding FOSS

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

Hewlett-Packard's picture

For software to be defined as open source, it must meet a strict set of guidelines established by the Open Source Initiative. Licenses certified as open source must also provide a set of rights to the user as specified in the definition. The official definition of open source can be found at:

http://www.opensource.org/osd.html

Three Basic Areas of FOSS

There are typically three aspects of open source: licensing, community, and methodology. A better understanding of these aspects can enable you to properly use and benefit from FOSS in your organization.

Licensing

Licenses are obligations set forth by owners of a particular work, such as software, that govern the use of their work. Many types of licenses exist today and various organizations within the open source development community have differing beliefs regarding licensing and how to use it in their work.

FOSS licensing is often overlooked by developers and IT management. As the number of licenses within an organization continue to grow, it becomes even more important to understand FOSS licenses to avoid violations that could result in litigation or loss of business. The nature of open source licensing presents unique challenges. The major challenge is knowing what the specific license requirements are and, whether you are in compliance. Understanding the context within which FOSS licenses are used must also be examined.

Unlike commercial software licensing, open source has many people contributing to the work for free, many people holding copyrights to their work, and restrictions exist for some open source software that deal specifically with how it interacts with other software. Consequently, it is important to understand what rights and restrictions exist when using a particular piece of FOSS. In addition, some open source licensing terms do not typically exist in commercial licenses, making it important to understand these terms. For a list of current, approved open source licenses by category, see the Open Source Initiative web site located at:

http://www.opensource.org/licenses

Open source software can also place license restrictions on the open source code's interaction with other software. For example, multiple open source licenses can be embedded in larger software and/or hardware products. These interactions can be complex as projects grow into multiple layers of code. It can be difficult to verify that the license provided with the software reflects all of the lower-level licenses that are embedded within it.

Some open source projects are performed by organizations who control all copyrights to the code. This allows organizations, such as MySQL, to follow a dual-licensing strategy: MySQL offers their product as open source, but companies who do not want to follow the open source license can obtain a different license form the company. In the case of the MySQL database, this is useful for organizations that want to incorporate the database into their product.

Community

Another key aspect of open source software is the community. An open source community is a collection of developers and users with a common interest in the creation, enhancement, and support of a specific piece of open source software. Historically, the community was comprised of many “free agents” or individual contributors. One of the main attractions to the open source community is the ability to customize open source software to meet an individual's needs. Once modifications are made, new features can be released back into the community. Another benefit of the open source community is the large network of peer reviewers. Because open source code must be accepted and reviewed by a large peer community, the code is generally written in a sound manner with strict adherence to coding standards. With the input and scrutiny of the open source community, the resulting software can often be more robust.

As the open source community evolves, FOSS activities are increasingly funded by large organizations which share development costs. For example, HP invests in Linux to improve the operating systems performance on their hardware. IBM invests in Linux because it provides an opportunity to use a common development set across all their platforms and for other business reasons. Government and academia are also contributing to the open source community at an increasing rate.

Participation in the open source community can bring many benefits to an organization's business model. Organizations can use open source software to improve development models, minimize development costs, and decrease time to market for software or products. Organizations have also discovered that some goals can be achieved faster using open source code as building blocks.

Methodology

The final aspect of open source is the general methodology that guides open source development by the community. There is more than one open source methodology. However, there are certain characteristics shared by all, such as open development. The specific methodology can vary depending on the project. The methodologies can be very different than organizations might expect. When organizations use FOSS, they like to know the community's plan for evolving the software. Very few road maps currently exist, but some projects are starting to create and publish them. Influence and control over the use of FOSS can be achieved by integration and involvement of the individuals who are largely in control of the development of FOSS. Different projects generally have their own subculture which has an impact on the governance methodology that is used.

An organization's involvement in open source projects through their employees must be done in alignment with the culture of each project. It is important to understand that participation and merit is earned; it stays with the individual and not the organization. When you have a high-performing employee who is working on a project, the business is heavily invested in the outcome of that project. If that employee leaves the organization, the ability to work within that community moves with that employee.

The following examples show two significantly different open source development methodologies.

  • The “benevolent dictator” methodology can be seen in use for the Linux kernel. Linus Torvalds initiated the development of the Linux kernel, leads development activities, and makes key decisions. However, he appoints “lieutenants” that oversee large portions of the development. One of his key mottos is “simplicity over performance.” This autocratic development methodology has proven over time to be a successful management strategy for dealing with contributions to the Linux kernel from a variety of competing development groups.

  • A well-documented governance methodology can be seen in use at the Apache Foundation. The Apache Foundation has specific documents that define their methodology for related contributions to the Apache project, overall governance rules, and in general, how the Apache project is managed.