The practices and culture associated with the Opens Source method and community bears all the characteristics of practices and culture expected of a high performance organization. The members come together in virtual communities for the sake of achieving a common goal that is of interest to the assembled group. They are motivated by intrinsic rewards and value creativity, doing quality work, personal growth, and task accomplishment. The open style and dynamic process of Open Source contrasts with the greater management oversight and more structured methods of "closed Source" development.

The essential differences have to do with coordination, selection, and assignment of work. Commercial development typically uses a number of coordination mechanisms to fit the work of each individual into the project as a whole. Explicit mechanisms include such things as interface specifications, processes, plans, staffing profiles, and reviews. Implicit mechanisms include knowledge of who has expertise in what area, customs and habits about how things are done. … In small projects direct communication is the primary means of coordination, but it does not scale well to larger projects. OSS projects, on the other hand, are generally highly modularized with a small team of core developers and an informal style of coordination. (Mockus, et al)

A company wishing to leverage the talents of the Open Source community has some natural barriers to overcome. The natural tendency for a firm to want to control and manage a project is a liability. Open Source projects usually start with a small group of programmers who grow the project contributor base over time. While ultimate authority lies with the group that started the project, there are detailed, explicit, and transparent plans for volunteer inclusion in decision-making for the overall project. The copyright license is the key element that facilitates the cooperative development through its mechanism for sharing, copying, and redistribution.(Long)

The volunteers who made products like Linux possible are only there, and the companies are only able to cooperate, because of the rights that come with Open Source. The average computer programmer would feel stupid if he put lots of work into a program, only to have the owner of the program sell his improvement without giving anything back. Those same programmers feel comfortable contributing to Open Source because they are assured of these rights: The right to make copies of the program, and distribute those copies. The right to have access to the software’s source code, a necessary preliminary before you can change it. The right to make improvements to the program. (Perens)

These licenses tie sharing of modifications to the distribution of code. If you make changes to the code but do not distribute the code you may violate the spirit but not the letter of the license. There are several reasons (all having to do with control) a company might be tempted to withhold their modifications from the community. This defensive strategy is not necessarily a winning one. Enlightened self-interest is the motivation for nurturing the Open Source commons. Business software, which is not necessarily proprietary, is ripe for commoditization. Developers who plug into the reputation-driven meritocracy of Open Source – while advancing company goals – are a force to be reckoned with. (Udell)

There are two directions from which a company may want to engage the Open Source community: as an interested user of a product from an existing project or as the founder or leader of a project. Any company using Open Source products would be encouraged to have employees develop a relationship with the groups supporting the products used. This need not be done through software coding, but can be done as part of the larger user community. Contributions of documentation, feature requests, and testing of new releases are all activities welcomed by the community. By participating a reputation can be built providing influence on the projects progress.

Successfully initiating a new project or transitioning an existing project to Open Source requires careful work to build a community with commitment to the project. Developers are motivated by intrinsic rewards. New free software is written to solve a specific problem facing the developer—to “scratch an itch” (Raymond, 1999). A project brought to the Open Source community needs to have general appeal or be useful outside of your company. Otherwise, it will be difficult to find volunteers to work on it. Assuming an active leadership role or becoming the maintainer for a project that has stumbled and is not progressing can be difficult and politically challenging.

Firms benefit in creating volunteer attachment and commitment by focusing on fostering community solidarity and involving the community in decision-making. (Long). Distrust of corporations is not uncommon these days; yet, trust is essential in Open Source development. In the Open Source culture in general, the importance of speaking the truth in daily work practices is a key value that carries over to Open Source software development (Elliott, 2002). Every effort should be made by firms to be open and have their actions match their words. Having the code base hosted by an organization like SourceForge that is friendly to the Open Source community and having some non-staff as leaders can reassure the community that the code will remain open source.

As the maintainer of a project the company must harness the work of developers by making responsible decisions and by responsibly choosing not to make a decision. Direction must be given without being bossy or overbearing (Hill). Successful Open Source projects have allowed an organizational scheme to emerge, rather than attempting to impose one. "Designing an organizational structure for what might be, rather than what is will likely impede the project rather than facilitate it." (Kim).

It is important that the developers see the leaders enthusiasm so they can share in the excitement. The more active the leader is, the more active the community will become. Leading by example is especially crucial for Open Source communities, because its participants are largely volunteers. Tasks cannot simply be delegated to participants with the expectation they will do it if the leader has not first earned the authority. If the leader is not working hard, enthusiastically, and visibly, then others who will, will not be attracted (Kim). Enthusiasm can also be encouraged by following the principle of releasing new versions of the code – both for testing and as stable upgrades – frequently.

The Open Source approach implicitly allows new features to be chosen by the developer/user rather than a marketing or product management organization (Mockus, et al). It is obvious that a project maintainer must constantly strive to attract and keep developers who can easily leave at anytime. What may not be apparent is that the users must be courted as well. Developers and maintainers need to listen to the users and be responsive to them. The line between user and developer are blurred in ways not common to proprietary software because users are frequently potential developers. In addition they commonly volunteer to be the testers. To keep the testers, make it easy for them to find and install the software. Also, explain what the tester is supposed to test. Respond and respond quickly to bug submissions. Quick and consistent responses will make the testers feel like their work is heard, important, and appreciated (Kim).

Open communication is important. A web site should be established and should contain statements of the product vision, a description of product scope, explicit plans for community involvement in decision making, and expectations for behavior. Avoid tying email addresses to an individual. Rather use addresses like project.support@domain.org. Forums and IRC chats should be set up and monitored constantly. It is important to have a qualified person respond to all communications quickly. Be inclusive, respectful, and helpful even with the less qualified. Good ideas can come from poor programmers. Also, be aware that volunteers may come from anywhere in the world and English may be their second or third language (Kim). Along with understanding the language, cultural differences can lead to misinterpreting communication or the tone of the communication

To build commitment the leader has to insure that each person’s opinions are heard and respected. New comers need to be informed of the behavioral norms. Off topic messages or inappropriate comments need to be minimized. (Butler, Sproull, Kiesler, Kraut).

The same leadership style and practices can strengthen the effectiveness of collaborative and self managing teams that are not in the Open Source arena. Open source communities promise to be a fertile source of reusable patterns of high-performance collaboration.