Organizations can benefit significantly from participating with Open Source communities and using the Open Source development model. But organizational policies designed to maximize resource utilization and ensure security can prevent an organization from effectively engaging with Open Source communities and fully realizing the benefits of the Open Source development model.

Proprietary software development practices lend themselves well to hierarchical policy disciplines that place a premium on tightly controlling processes and resources. However, effectively taking advantage of the Open Source development model may require modifications to certain organizational policies. This paper explores organizational policies that can prevent, or can be modified to enable, effective engagement with Open Source communities or internal use of the Open Source development model.

Defining the Open Source Community and Development Model

• The Open Source Community[1]

  Most simply, Open Source communities are loosely organized groups of self-selected software developers and users who come together to develop software that addresses a common problem. Linux and Apache are perhaps the most widely known Open Source software applications and communities. Software is developed by these communities under one of a number of Open Source licenses that mandate or permit public availability of the software source code, hence the name Open Source.[2] Some Open Source based software products are also dual-licensed for commercial distribution. Despite its “open” nature, the Open Source community adheres to strict quality control mechanisms for software development.

  The Internet typically connects Open Source communities. They use email and other Internet enabled development tools to communicate and coordinate the tasks of software development. The Internet is used as the transport to contribute the source code and other work products developed by community members. Typically software is distributed among community members, and package releases may be made available to external end users, via Internet download. With the rapidly growing interest in Open Source and the development of Open Source enabled business models, commercial methods of distributing Open Source based software products are also being used.

• The Open Source Development Model

  The Open Source development model is a software development process that depends on a relatively flat, developer led hierarchy, individual responsibility, and collaborative peer review and testing of source code. Those engaged in this development model create and submit software code, bug reports and fixes, documentation, and other work products that further the construction and validation of the software. Community leaders, who have earned their positions by consistently developing high quality work products and being recognized by their peers, review these submissions to ensure that the resulting software is of high quality. The software product produced by this open and collaborative process is typically built on a daily (or nightly) basis and the current build is kept continually available to facilitate ongoing peer review. As each major cycle of development is completed, the software product is released to the end user population. Open Source software development is said to adopt a “release early and often” approach because these releases typically occur much more frequently than with comparable proprietary software products.

  From the perspective of the end user organization employing the Open Source development model, the fundamental differences between a traditional software development model and the Open Source software development model are the self-managed hierarchy of collaboration, the peer review process, and “release early and often” practices. These are fundamental shifts in the way software is developed, requiring changes in management and human resource practices.

  Open Source software development groups are considered to be self-managed because their leaders are developers. This is a radical departure from the traditional software development model, which typically features non-developer management personnel controlling the pace and quality of software development.

  The peer review development practice is based upon the principle that developers submit their code publicly for all to see and the most correct and efficient source code is selected for inclusion in the software under development. Alternative approaches and refinements to the software are submitted openly within the community and vigorous discussions on the merits of competing solutions occur that generally result in a collective decision.

  The process of releasing code early and often provides for rapid, incremental developer and end-user feedback allowing the development group to balance new, cutting edge functionality with application stability. The development group leaders decide, in conjunction with the organization's operational management, about what new functionality the organization needs versus how much software stability risk the organization is willing to accept. The balance point that the organization selects determines its pace of software development and the level of software risk it incurs.

  An additional factor in the Open Source development model is the capability of the software end-user organization to determine its level of engagement with an external Open Source community, if one exists. The user organization can establish and/or actively engage in an Open Source community supporting the application, thereby gaining insight into, and influence over, the software. Alternatively, it can simply use what becomes generally available, in which case it won't use the Open Source development model internally but can still benefit from using software developed by an existing Open Source community.

What is required for engaging with an Open Source Community?

• Participation

  To gain the full benefits of Open Source software, an organization's resources must be able to participate in the work of the Open Source community. In order to be productive from the perspectives of both the organization and the community, these resources must be able to openly interact with the community under as few constraints as possible, that is, provide input and respond to the needs, priorities, and decisions of the community.

• Communication

  In order to engage with an Open Source community, the organization's resources will need access to high-bandwidth Internet communications and enabling software applications. These channels will be used for the comparatively large amounts of email, real time messaging, and other communication methods required by the developers, as well as high volume downloading and uploading of source code, executables, documentation and other work products associated with the community.

• Legal Support

  Open Source licenses allow, or require, open distribution of the source code and end products of Open Source communities' development efforts to all members of the communities and to the public at large. Ownership of copyrights associated with the work of these communities belongs to the individual contributors (or their employers), or are sometimes assigned to the Open Source communities' organizations as a condition of participation. An organization's legal policies must support the source code ownership and licensing characteristics required by a particular Open Source community in order for the organization to engage with and benefit from its participation.[3]

• Computing Resources and Support

  An organization's developers who are engaged with an Open Source community will need the computing resources necessary to actively participate with the community. These computing resources might require different infrastructure software (operating systems, etc.) than are already supported by the organization's Information Technology (IT) department. These computing resources will need the normal support services of the IT department, such as network connectivity, backup/restore, file system connectivity, etc.

Organizational policies that can hamper Open Source engagement

Organizational policies, practices, and procedures can explicitly or inadvertently present barriers to engaging with Open Source communities. Some policy categories where adjustments might be needed to enable Open Source work include: Governance and Human Resources, Information Technology, and Legal.

• Governance and Human Resources

  Organizational governance policies that disincent or restrict people from working on projects other than those directly assigned to them by management will discourage software development resources from participating in Open Source communities. It will often be the case that people engaged with Open Source communities will need to be working on priorities set by the community rather than by their organization's management. This can make it difficult to closely manage the time and productivity of the people so engaged. Open Source resources need sophisticated management oversight that is adept at recognizing individuals' contributions to both internally assigned tasks and Open Source efforts.

  Reviews of Open Source staff should focus on their contributions to their internally assigned tasks and the overall progress of Open Source projects to which the employee is assigned. Traditionally, rating of a developer's performance is based upon programming metrics such as lines of code written, hours worked, or function points implemented. Performance of resources engaged in Open Source projects should be based upon such factors as code accepted by both internal and Open Source projects, number of bugs identified and fixed, documentation contributed, and other factors necessary for the development of quality software. A developer's contributions and achievements in both internal software development projects and the Open Source community should be evaluated fairly, potentially with equal weight. This requires a high level of trust and progressive management and incentive approaches based upon the enlightened self-interests of the organization.

  As Open Source technologies and processes become more important to an organization, its acquisition of human resources with skills in Open Source software and specific Open Source technologies will become more important. Organizational recruiting processes will need to seek candidates with Open Source software development skills when hiring software developers. Hiring key members of Open Source communities who are building technologies important to the organization will be an attractive option for obtaining high quality staff. Cultivating supportive and engaged relations with Open Source communities will be important to the success of an organization's Open Source related recruiting efforts.

• Information Technology
  • External Communications

    Employees engaged with Open Source communities need high-bandwidth access to the Internet in order to contribute to the work of the community. Corporate firewall policies might limit the size of, or prevent, large data files from being moved through the firewall, either inbound or outbound. This can prevent employees engaged with the Open Source community from downloading or uploading code, documentation, executables and other work products to and from the community.

    Open Source communities use file transfer protocols, instant messaging, real time conferencing, and other Internet enabled communication technologies to supplement email. Corporate IT policies (or IT staff capabilities) can discourage or prevent these technologies from being used through the company firewall. Organizations might need to selectively adjust such policies or invest in more sophisticated Internet communications capabilities to support Open Source engagements.

  • Computing Resources and Support

    An organization's IT department might have established policies for supporting only a limited set of systems and applications software in order to simplify support requirements and control support costs. Open Source communities can require additional or different operating systems and software products in order to do the development work of the community. Employees engaged in Open Source development will not only require availability of required computing resources, but will also benefit from the full complement of traditional IT support services for these resources. These services will include connection to the organization's network and file server resource, backup/restore, and failure recovery services. In some circumstances, Open Source resources can better provide their own computing infrastructure and operational services, and in these cases they will require management sponsorship and funding support in order to be successful.

• Legal

  An organization's legal and employment contracts, policies, practices, and procedures that require retaining ownership of all work products resulting from the use of organizational time and resources when developing Open Source software need to be reviewed and possibly modified to explicitly permit Open Source contributions. This will need to be done to enable Open Source copyrights, patents, and licensing of the organization's contributions to Open Source. The language used within employment contracts can be constructed to properly protect the organizations intellectual property rights in copyrights, patents, and trademarks, without significantly negatively impacting an employee's Open Source contributions.

  When using proprietary software, organizations typically pay for usage rights, usually in the form of either one-time or recurring license fees. Often, some limited support is included with these license fees but more comprehensive support is available only at additional cost. When using Open Source software, an organization typically will not pay for software usage rights or acquire associated minimal support entitlements. However, with Open Source software, the user organization will have a number of options for obtaining software support, including free community based support (via mailing lists, online forums and email) as well as various commercial options involving support contracts. The user organization can also choose to download the software from the project website while not paying any license fee, and provide for software support either internally with the help of community resources or on an ad hoc basis by hiring support contractors as needed.

Altering company policies

An organization can test its involvement with Open Source communities by starting with a small pilot project. Such a pilot project should be of real interest to the organization but not mission critical. Within the confines of this project, organizational policies and procedures can be modified or developed and refined in order to support the organization's engagement with the Open Source community. This limited modification can be used by the organization to develop and test policies that are more conducive to Open Source community engagement. As the organization gains Open Source experience and an understanding of its value and benefits, and builds confidence in its ability to adapt its policies, it can increase the breadth of subsequent Open Source engagements and expand its modified or newly developed policies accordingly. A test project may be small, but the adaptive effort required from an organization's management and legal departments is likely to be significant. The benefit of keeping the test project small and non-mission critical is in limiting the risk and impact to the organization's core business while Open Source friendly policies and procedures are worked out.

Conclusion

There are many benefits available to organizations that engage with Open Source software communities and/or deploy the Open Source development model. As we have described above, there are organizational policies, procedures, and practices that can hamper developers and organizations from realizing all the benefits that engaging with an Open Source community and/or using the Open Source development model have to offer. Close examination and judicious modification of these policies can remove potential obstacles to effective Open Source engagement and software development.

About the authors: The authors are management consultants with Olliance Group, an Open Source strategy-consulting firm offering a comprehensive portfolio of education, business strategy, and technology planning services. Olliance Group can be reached at (650) 493-3800.

Footnotes

[1] See the Olliance Group white paper “Engaging with the Open Source Community” available here.

[2] For more information please visit the Free Software Foundation and the Open Source Initiative.

[3] Patents may be held by companies or individuals but usually must be licensed without royalties to the Open Source community in perpetuity. Trademarks associated with Open Source communities are normally held by communities' organizations. An organization's legal counsel should be consulted regarding appropriate policies for use of copyrights, software licenses, patents, and trademarks.

Copyright © 2003, Olliance Group LLC. All rights reserved. Reproduced by LinuxDevices.com with permission.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.