"It may turn out that open source's greatest contribution to organizations is not its great products, but its great working practices. Take a look at where you can take advantage of community within your organization."
Bernard Golden, CEO, Navica
What does it really mean to participate in an open source software community? If a company's open source strategy is limited to acting as end user of open source software, is there a business need to understand the nature of open source communities? Should it be the goal of all businesses to become an active participant in open source communities, or become recognized as a significant contributor?
Business users of open source software can broadly be divided into those who use open source software as end-users, and those who incorporate underlying open source technology into their products and services. This article will first address both these groups with the important facets of understanding and evaluating community in the selection of open source software, and then elaborate on the role of active participation in open source communities to enhance the value that can be obtained from the use of open source. It is based upon lessons I've learned from becoming progressively involved in a particular open source software community, Tikiwiki, and comparisons with other open source communities which I've made to identify commonalities and differences.
End User Considerations
Many businesses use open source software purely to take advantage of cost savings. However, while the code itself is available at zero cost, total cost of ownership can often escalate due to ongoing support requirements. Moreover, the initial process of evaluating and selecting open source software can be a time-consuming exercise. Open source software communities spend a fraction of what commercial software companies do on marketing. Product information is therefore often less comprehensive, not centralized in one place, and tends to be more technical in nature. Determining the right open source software to use often requires a fair bit of research. One solution is to hire a consultant who is knowledgeable in open source software for the domain of interest, to do the evaluation.
Understanding the nature of the community that produces the open source software is a critical part of evaluation that is often overlooked by users who are new to open source software. Unlike closed source alternatives, key support options for open source software include non-commercial channels provided by an extended community. Therefore, important criteria that should be considered when evaluating open source software include the size and vibrancy of the community, the availability of online documentation, and access to support via mailing lists, forums, and IRC (Internet Relay Chat). One source for such information is statistics on sites such as SourceForge and Ohloh. However, both sites focus on the contribution of developers and it is important to note that contribution to an open source community is more than just commits to the codebase. As in commercial software, production of good open source software also requires documentation, testing, support, training, and the incorporation of user feedback. An understanding of the maturity of the community can help to answer questions such as "what support mechanisms are available if we roll out this software?" and "how difficult will it be to install and use this software?"An evaluation of an open source community should also consider the broader ecosystem in which it exists. An environment in which open source is prevalent results in consumer choice that is arguably unparalleled in closed source ecosystems. Open source software has a clear advantage in some domains, for example, in the area of wikis. Freely downloadable open source solutions are plentiful and comparable in terms of quality to their expensive, closed source counterparts. As an illustration, consider the broad range of needs addressed by two popular open source wiki software, Mediawiki, the platform behind Wikipedia which is excellent for public wikis but not designed with private workspaces in mind, and Tikiwiki which is architected from the start as wiki groupware, making it perfectly suitable for environments that need securing of content for different groups of users. A vibrant open source ecosystem also facilitates software evaluation through the existence of sites such as Open Source CMS, which provides comparative evaluations and comments provided by a large community of users.
Selecting from a final shortlist of software will often require a tradeoff between access to more advanced or specialized functionality, and the size of its community. For example, in an evaluation of content management systems, we find that Tikiwiki, while it supports comprehensive wiki-based collaboration, has a community which is not as large as that of Drupal, an elegant general purpose content management system which lacks wiki functionality.
A deeper understanding of the nature of the community is also critical in determining the nature of support that will be available for an open source software. It is important to consider the nature of the resources the community has to offer in relation to the capabilities of your organization. For example, the Tikiwiki and Drupal communities have a large number of highly technical members who can provide support at a high level of technical sophistication. On the other hand, another popular content management system Joomla, has a relatively smaller team of technical experts combined with a larger community of less technical but more design oriented individuals such as graphic designers and web designers. Largely as a result of this structure, the Joomla support forums tend to become somewhat overwhelmed with questions of a "how-to" nature. Discussions over more complex technical issues are therefore less prominent. On the other hand, it is much easier to find consultants that are able to make low cost design customizations for Joomla than it is for Drupal or Tikiwiki. Another benefit of open source software like Joomla that is exposed to a wider swath of mainstream users is that they tend to be more user-friendly, although this usually comes at a price of reduced functionality.
Is Modification Required?
When evaluating open source software, a careful analysis of features is needed to determine if the software is suitable as-is or if modifications will be required. If the need for modifications is likely, a further analysis of the core architecture as well as the project itself is beneficial. This is especially important for businesses that intend to use open source software as underlying technology for their products or services. As an example, consider the differences between Drupal and TikiWiki.
In terms of architecture, Drupal has a smaller core which provides a set of hooks at a lower level; these can be leveraged when creating custom components that provide "core-type" functionality. Tikiwiki has hooks at a higher level that are used mainly by add-on components that enhance user input, output display, support new content types, and provide integration with third party systems. To add substantial "core-type" functionality in Tikiwiki, one would have to actively participate in the Tikiwiki development team; whereas in Drupal it is possible to lead and maintain the development of substantially sized new components without direct involvement with the Drupal core team. In making a final platform decision, it is therefore necessary to evaluate if development and maintaining of new components is needed, while taking into account the scope and nature of the effort involved.
Businesses incorporating open source software into their products may want to consider leading the development and ongoing maintenance of a new component. This could lead to benefits that come through influential leadership of a new sub-community which can provide ongoing support and resources. The larger the potential sub-community is, the greater the benefits will be, but greater also are the risks and the costs. Maintaining a component is likely to be a very involved effort.
There is also a question whether demand for that component will grow sufficiently to make it important enough to the community as a whole. Creating a component, as in the case for Drupal, has to be weighed against the alternative of participating actively within an established group of developers, such as in Tikiwiki, where the component is already part of its core. While dealing directly with the core development team relinquishes leadership, it can still enhance one's role in the community through active participation.
When working with open source software, it is important to consider the roadmap of the community and evaluate if it matches one's desired use and objectives. Unlike closed source software where the product roadmap is defined by management, the roadmap of open source software is in a constant state of flux influenced by the community of users, developers, and other contributors. Understanding where a community is headed requires a perceptive evaluation of the individual motivations of the various stakeholders involved.
Benefits of Collaboration as End User
Even if business use means using software as-is with no plan to develop or contribute code back to the community, there is a strong business case for some collaboration with the open source communities for the software the business is using. Implementing open source software can require time spent researching existing documentation and asking for help on forums. In open source, the nature of problem solving is highly interactive and collaborative. Large projects often have community members that respond to requests for help on IRC. One should keep in mind that support is often provided by a group of unpaid volunteers, each with their own schedules, and should not be surprised that there can be no answer at times, and many people rushing to help at other times.
Someone unfamiliar to open source might wonder why people are willing to volunteer their time this way. Responding to support questions gives community members a feel for what aspects of the software can be improved and also helps to prioritize feature enhancements. Moreover, many participants in open source communities make their livelihood from the software that the community produces. They understand that a strong community leads to the strength of their individual consulting, hosting, or product businesses. In addition, providing support leads to more users which results in more testing of the software, in turn improving the product.
In the course of using either open or closed source software, bugs are often detected. In open source, bugs and feature requests are typically submitted through the community's bug tracker software so that they can be acted upon by the rest of the community. Being actively involved in the reporting of new bugs and feature requests raises your profile in the community, and increases the likelihood of receiving help and requests for additional comments or suggestions in future.
For users who are also developers, it is often easier to fix the bug or code the feature enhancement oneself rather than to wait for someone else. By sharing these changes with the rest of the community, others can benefit and the changes can be integrated into the main stream of development. Sharing modifications benefits not just the community but also the contributor who subsequently benefits from ongoing testing and support of the code by the rest of the community.
Finally, geographical location is useful contextual information to otherwise impersonal online communication. It is useful to visit key project members in your vicinity, especially if you are intending on being actively involved in a community. Meeting face to face can add a personal touch to an otherwise staid relationship.
Understanding Community Differences
Businesses who intend to participate actively through contributing code back to the community, especially those whose products depend on the open source software, will have to gain an appreciation of the different cultures that exist in each community in order to maintain a cordial working relationship as participation becomes progressively involved. Open source communities may become suspicious of corporate intentions if they are perceived as being in conflict with the needs of existing members. Our experience is that it is best to be as open as possible up front about one's plans, especially with key members of the community. Most open source communities are characterized by more open policy discussions using tools like wikis, forums, and mailing lists than is typical in corporate environments. It is also important to be aware of the software development management procedures that are in place in the community, many of which are likely to differ from those used by your organization.
For example, different communities have different standards as to who can be a code committer. Some communities have strict published guidelines while others are more flexible. In the Tikiwiki community, any user that has contributed at least one code patch of decent quality back to the community is typically approached and encouraged to contribute their changes directly. As such, the Tikiwiki community provides a relatively large number of its developers with direct commit access to its revision management system.
Developers who are more familiar with corporate closed sourced development environments may find the looser control over code commits unusual, and worry about lack of control over changes to the codebase. However, the "wiki-way" characterized by open collaborative authoring, when applied to software development is surprisingly effective. Tikiwiki's experience has been that most new developers are extra careful with their commits anyway, since no one wants to get a bad reputation for submitting shoddy work. Moreover, before a developer is given commit access, he is directed to documentation that details expectations regarding coding conventions and practices. Any developer that is not confident in meeting those requirements is likely to avoid accepting commit access. Core developers keep a close watch on new commits; gentle warnings as well as requests for clarification are not uncommon. This creates an environment of rapid innovation driven by quick feedback and intense discussion between collaborators. At times, changes to the code are rolled back using the revision management system by core developers followed by a gentle "what is this commit trying to achieve?" or "how about trying something else instead?" Such exchanges are often extremely instructional and lead to unexpected innovations, much more so than having discussions on paper. Nevertheless, design and architectural discussions are necessary when significant changes are planned. These are often conducted first over IRC and then documented on wiki pages and forums so that the rest of the community can comment.
Many projects have an editorial board or a documentation team, providing a method for community members that are not software developers to participate. Like the developers in the Tikiwiki community, the Tikiwiki editorial board conducts extended virtual meetings discussing issues using wiki pages, forums, IRC, and the mailing list. The mix of synchronous and asynchronous mediums of communication help to overcome the timezone differences faced by this diverse group.
It is often possible to collaborate together on projects with other community members. In any community of significant size, there are most definitely complementary needs to be discovered. For each individual, the community provides a ready pool of resources that help to smooth out demand fluctuations that each face in their own businesses. Different open source communities have different cultures and varying levels of institutionalization for monetary transactions between community members. In some communities, such as Tikiwiki, privately arranged monetary transactions for work done between members are common, although there is no officially sanctioned bounty system. In other communities, such as GNOME, official bounties are often provided by the community for features that have been identified as desired by the community as a whole. In almost every community, contribution of code created as part of paid projects back to the community is strongly encouraged.
The licensing of each open source software can provide a clue to the expected level of code sharing. The LGPL (Lesser GNU Public License) used by the Tikiwiki community could suggest a lower expectation than communities of software licensed under the GPL (GNU Public License), while those licensed under academic style licenses such as the BSD (Berkeley Software Distribution) license tend to be characterized by an even lesser expectation. Businesses who are more familiar with commercial software development should refrain from the knee-jerk reaction to pay members of the community to solve every problem. Research has found that paid work within open source communities can lead to crowding out of intrinsic motivations to contribute.
Rising to Leadership Positions of Influence
Companies that depend on open source software as components for their products or services should aim to rise to leadership positions of influence within the communities they participate in. The path to leadership involves initiating conversations with users who have not previously contributed to encourage them to be more involved, depending on the goals of the contributor, and the amount of time available to work on related items. Members with ideas, patches or documentation but who have no time to integrate them can be introduced to other contributors so that they can collaborative on getting more resources into the community.
Open source communities often hold regular events to work on new software features together. These are excellent opportunities to interact and to get to know fellow community members better. Events are also organized in preparation for the release of a new version of the software where everyone collaborates to fix outstanding bugs in order to accelerate the release of the next version. Members contributing to documentation usually take this opportunity to refine the manuals, online help, and the documentation website.
By contributing to these events, a business can raise its profile within the community and increase the familiarity and comfort level other members have of its participation. A business should also take every opportunity in the marketing of its own products to support and champion the open source community, whether it is in product marketing, corporate communications, or industry forums. Such efforts are often greatly appreciated and reciprocated.
Eventually, active participation and support for the community means being offered opportunities to take on official leadership responsibilities including managing key software components, organizing events, or coordinating software releases and documentation.
Understanding the community which develops the software being used by a business provides many benefits. As an end user, the company is able to access support channels traditionally not available with closed software solutions. As an active participant, the company has the opportunity to influence the direction of the software, and if desired, to leverage that influence as part of its business strategy.