A consistent set of policies and guidelines is needed to govern FOSS within an organization. These policies and guidelines must be carefully developed to insure that all issues that may affect the interests of the organization are addressed. Because an open source governance policy is a key business management process, it is recommended that all FOSS policies are developed jointly with other departments in your organization which might be impacted, such as legal, business management, IT management, and engineering.
The following content provides guidance for developing an open source policy and describes the rationale behind various aspects of the policy, such as motivations, business justifications, and open source community participation. This section also considers additional information that can be used when developing FOSS policies. These components of an open source policy include: business use cases, appropriate and inappropriate uses of FOSS and associated projects, employee participation, and other considerations.
A few general guidelines that should be considered and addressed when developing a FOSS policy include:
Determine if the use of FOSS is beneficial. This can be examined by defining the business need, the role it plays in infrastructure and development projects, and cost saving trade-offs.
Develop a process for FOSS governance. This includes policies, procedures, and tools to manage the acquisition, use, licensing, deployment, and distribution of FOSS. Within the context of this process, employee and management responsibilities should be defined, specifying their roles and responsibilities in support of the FOSS governance strategy.
Define the extent to which an employee can contribute to open source. Provide specifics for how, when, and where an employee should bring FOSS and its related projects into the organization and how much they should participate in the related community.
Determine relationships with the open source community. Consideration must be given to how your organization works with the open source community, in general and in relation to specific FOSS projects. Develop best practices for managing the relationship. This should include organizational policies for licensing FOSS projects and protecting proprietary assets.
Develop a documentation plan in support of communication and awareness of the organization's FOSS governance strategy. In addition to traditional documentation, this may include training, internal public relations campaigns, and other educational opportunities.
There are many things FOSS policies should address, and questions that need to be answered. The policies needs to go beyond just understanding the license requirements and answer some of the following questions:
How is FOSS chosen?
How is FOSS acquired?
How and where is FOSS used?
How is FOSS supported?
How is FOSS tracked and how are FOSS projects tracked?
It is crucial to perform an analysis of FOSS candidates to insure potential risks are clearly understood and documented. This analysis includes a determination on whether the open source software is designed for a specific use case; and if so, whether the licensing terms reflect this purpose. You should determine if the use of FOSS for a particular project is “mission critical.”
To determine if a particular piece of FOSS is a good fit for your organization, information should be obtained and evaluated regarding the particular open source project community. This requires delving into open source community issues such as the size, age, and activity level within the community. The “health” of the community and its goals are also important.
Another important factor to examine is the legal status of a FOSS project. You should look for both current litigation and the potential for future litigation. There are many resources available on the web that can assist in your evaluation of FOSS. For a list and description of some of these resources, see the FOSSBazaar web site located at:
Once it has been determined that a particular piece of FOSS is to be used within your organization, the next step is defining the process for acquiring the software. Knowing where to retrieve the software is only the first step. In addition, you should verify the following:
The open source code came from a single, authentic source repository.
The open source bits arrived intact.
The open source is not corrupt.
The open source code was compiled from the source; if not, verify there is no malware embedded in the binaries.
It is important to know how open source will be used in your organization in order to understand both the short and long-term ramifications. This section discusses the types of questions that you need to ask to clearly understand how FOSS will be used.
How FOSS will be used can come into play when addressing a variety of FOSS licensing issues. It should be determined if the open source software is currently used with other proprietary code and whether it will be used this way in the future. You should determine if the license allows for the use for which you intend. Not all FOSS licenses are compatible with one another. As licenses continue to proliferate and become more complex, more and more pieces of software are becoming incompatible so you cannot always combine two different pieces of software for different purposes.
Next, you should find out how many groups use each FOSS component. It is important to determine if there are other groups in the organization using similar but different components, or different versions of the same component. The open source policy needs to provide a mechanism, such as a database, that can be used to inventory, track, and manage all FOSS use within the organization. A common complaint from production teams is that development teams are using different open source software to perform the same fundamental functionality, or they are using different versions of the software. For example, Apache Geronimo and JBoss JEE Application servers have very similar functionality. The organization must put controls in place for different versions of software that are in use to avoid unnecessary work maintaining multiple versions.
The use of FOSS can be valuable to the operations of an organization for reasons other than specifically generating revenue. For example, turning software over to the open source community can be used as an exit strategy to enable the user community to continue to enhance and maintain the software.
Another benefit of using FOSS is the ability to distribute development costs across multiple organizations with no loss of competitive advantage. When an organization wants to be an active participant in a FOSS project, it is more cost-effective to build non-differentiating technology so the organization can spend more of their resources building innovative technologies that provide differentiation. There are numerous new efforts aimed at developing open source consortiums so vertical markets can leverage each other for code and technology but without any differential advantage.
Determining how to support FOSS use in an organization is critical. Every employee within the organization should adhere to the established guidelines. There are three different approaches that are commonly used when supporting FOSS:
The decision as to whether FOSS can be self-supported is dependent on the quality of the ties to the specific open source community; employee participation in the open source community; and ultimately, whether a specific plan can be developed for self support.
Commercial support can be provided to an organization through vendors such as HP, Red Hat, Novell, MySQL, Symas, and so on. This type of support is used when an organization has a direct, vested interest in the project. The organization typically employs contributors or people who can focus on the maintenance of specific components. The relationship between the different vendors is important. When considering the use of commercial support, you should determine if a positive working relationship exists with the vendor and whether some level of integration support exists. The stability of the organization providing support should also be considered.
|Commercial Support by Integration Vendors||
An organization can use integration vendors to provide commercial support such as HP, OpenLogic, SourceLabs, Spike Source, Covalent, and so on. Integration vendors may not be major contributors or to the development or maintenance of the open source, but they still have some level of investment in those projects. They also play a role in a larger set of projects and perform integration testing.
Part of an ongoing maintenance policy for using FOSS in your organization is determining how the FOSS project is to be tracked over time. Unlike commercial software vendors with one or only a few vendors to track, FOSS has numerous entities that must be monitored. This reflects a different tracking process than what has traditionally been used by organizations.
It must be decided who is going to track certain aspects of the open source. Important issues to track include vulnerabilities and critical defects that might be posted against a particular piece of FOSS. If possible, these defects should be integrated into the organizations’s development cycle. The health and road map of the FOSS project should also be tracked. Potential problems to look for are off shoots from the original project, discontent within the community, and whether major contributors are leaving. How often the health of a FOSS project should be monitored depends on the particular project.
In theory, internal FOSS should be controlled by restricting access to open source repositories. However, in practice, successful implementation of such a policy has not yet worked. With a prolonged process for the submission and approval of a FOSS request, it is inevitable that the members of the organization will circumvent the process and obtain FOSS in a more timely fashion.
FOSS can be advantageous for an organization and can have cost-savings benefits. Additionally, there are a number of other business use cases that might not be as obvious. The following is a list of use cases to consider when determining whether your organization should contribute to the FOSS community.
Establishing your FOSS implementation as an industry standard. An organization can maintain a controlling interest in the FOSS project while still allowing others to view, modify, and use the particular piece of FOSS.
Increasing sales of other products including hardware and software. Vendors such as HP leverage hardware sales by modifying Linux and other FOSS projects so they are compatible with their hardware. This can also lead to wider acceptance of the open source in the marketplace.
Distributing the expense of FOSS maintenance among other collaborators. Because the use of FOSS is so pervasive in product development today, this distribution of costs to a larger community can offer significant cost savings as well as leading to the development of a more robust product.
Gaining cooperation from the open source community. Some organizations may become involved by taking the lead in a FOSS project while others may choose to leverage the results that are gained through open source community cooperation.
Providing a strategy for a product’s end-of-life plan. This is can be an attractive alternative for an organization. By open sourcing software that was previously proprietary, product support can be continued through the open source community. Users are given access and self-support capabilities.
Enhancing an organization's image in the marketplace. Advertising your organization’s involvement in open source can improve your image, resulting in a more “high-tech” image. By leading or participating in the development of FOSS, you can generate favorable publicity among peer organizations and the open source community. This can also attract new hires.
Because there are many ways in which an employee can make contributions to open source, thought should be given to developing guidelines and policies related to these contributions. This section discusses potential issues to consider when developing these guidelines and policies.
First and foremost, an organization should provide documentation and training on their FOSS policy. It is only with a clear understanding of the policy that employees can be held responsible for compliance.
Next, a procedure should be implemented through which an employee can submit a proposal for management approval for using or developing FOSS.
Employees should understand they are responsible for disclosing any involvement with FOSS projects, regardless of whether they consider it work for the organization or personal work outside of their employment. Many large organizations have clauses in their employment contracts, particularly for software development, that anything the employee develops is an asset of the organization. In some cases, even though an employee may perform work on FOSS projects outside the realm of their employment, they may still be obligated to the organization's policies and licensing requirements. In addition, it is not always clear who holds the copyrights to FOSS contributed by an employee. Copyrights may belong to the employee, the organization, or both. An employee is also responsible for protecting an organization's proprietary information and trade secrets.
Work performed on a FOSS project has the potential for conflicts of interest. One way in which a conflict can exist is how closely the external work of the employee is tied to their job within the organization. An overlap between the external open source work of an employee should, in most cases, not overlap with their internal company projects. For example, if the organization is working to create a product to compete with one that already exists in the open source community, it could be a problem if an employee is also working towards the same goal on personal time. Another conflict of interest could occur when an employee works on a particular FOSS project while employed with the company, but has the intent of leaving the organization to build a business that supports the open source software he has worked on.
Conversely, there may be reasons why an organization would encourage employees to work on their own time on a FOSS project. For example, it would be beneficial for an employee to work externally on a FOSS project which could compete with another vendor's proprietary offering. Additionally, when an organization introduces legacy software into the open source community when it is at the end of its life cycle, an employee with intimate knowledge of the software could make external contributions as a member of the open source community at large.
Another issue regarding an employee's contributions to FOSS projects, is the consideration of what is appropriate use of an organization's time versus employee personal time. This includes organizational resources such as e-mail, internet access, phone, computer equipment, and so on.
There are some less obvious but equally important policy considerations that should be taken into account when developing your organization's FOSS policy. An organization's relationship with the open source community and knowledge of copyrights and patents that pertain to a particular piece of FOSS.
Maintenance of positive working relationships within the open source community is very important. To develop appropriate guidelines, you should determine the objectives of the organization's relationship within the open source community. Organizations often lose credibility when they create business models around generating revenue through a FOSS project in such a way that they are not sufficiently giving back to the community. Organizations should retain software that differentiates themselves from their competitors. Part of the policy should be to distinguish between software that provides a competitive advantage and software that is "common" and could be beneficial to many. The result is less software that must be maintained solely by your organization. If code is maintained locally, it substantially increases the level of effort required to merge the code into new releases of the FOSS.
Software developers in the organization also have certain roles and responsibilities in their interactions with the open source community. Policy considerations should include how to work on disclosed FOSS projects, performing work in the community where a third party might have intellectual property rights within a collaborative effort, and tracking their ability to access and leverage of FOSS.
Guidelines should be developed regarding IT's roles and responsibilities for acquiring, testing, and using FOSS and interacting within the open source community. It is important to respect other people’s time by performing due diligence on your work before it is presented. This is one way in which you can gain credibility, respect, and have a stronger voice within the open source community.
Competing with existing FOSS projects is typically viewed as inappropriate in the open source community. However, there are certain instances when competing with an existing FOSS project can be beneficial. Ultimately, there needs to be a compelling reason for creating competition. For example, competition can be appropriate if the direction of the existing project is not the same as the organization's project, or if the party responsible for maintaining the existing project is unwilling to accept your contributions.
Without knowledge of who owns the copyrights and patents for a particular piece of FOSS, it is difficult to understand when copyright or patent infringement occurs. You must recognize that software patents are a concern for any software consumer, independent of whether the software is open source or commercial. Commercial entities offer some level of indemnification, although they typically have a limit on how much they are willing to pay. No company can fully indemnify anybody else. For example, consider an organization using a commercial software package in a mission-critical environment. If that software is found to infringe on patents to the extent that the organization can no longer use the software, the potential impact on business is enormous. Recognize the risk and exposure presented by using FOSS and mitigate to the extent possible.
Even with a policy in place, you are still at risk for committing patent infringement. In the open source community there are a variety of ways you can mitigate patent infringement risk such as using an IP company such as the Open Invention Network (OIN) which is stockpiling Linux-related patents for the purpose of minimizing IP issues related to using Linux.