Community Beyond Open Source

One of the most attractive aspects of open source is its concept of community. While there is no authoritative definition of community within the open source world, most people acknowledge these elements are present in an open source community:

• Direct, non-hierarchical communication among developers. Instead of orders being issued from on high (aka management), the development team itself works out what features to add, what the quality level of the product is, and when the product is ready to release, As might be imagined, leading an open source development team requires unique interpersonal skills -- not merely geniality, but strong technical skills mixed with the ability to motivate headstrong volunteers.
• A focus on code rather than design documents, opinions, or the like, when settling disputes. As one can easily understand, this focus on code can sometimes be the arena in which headstrong invidividuals express their conflicts. Nevertheless, this focus on code indicates that, to paraphrase Shakespeare, "the code's the thing." 
• Transparent communication between developers and users and among users themselves, all with the aim of sharing knowledge and improving the product. This is very different from the traditional software development model, where developers are cloistered away in the back room, with absolutely no exposure to real end users. In software companies, the stated reason for this is so that developers won't be distracted, although, as often as not, it's done coercively to ensure no programmer decides to listen to a real user and change the carefully spec'd product on a 'whim.'

One only needs to look at the adoption and quality of open source software to see the positive effects of community. When I first was exposed to open source software, it was the experience of community that convinced me that something special was going on in this (what I assumed) anarchical system; my background in enterprise software had given me plenty of reason to think the existing system's usefulness was exhausted.

Recently, however, something unusual has been going on around community. Several organizations have discussed with me their desire to begin applying community principles to their development activities, even though the projects they're working on have nothing to do with open source software, being, instead, old-fashioned self-developed applications.

Each of them differs -- one is a government entity, a second is a large multinational, the third, surprisingly, is a consortium of competitors. What is common among the community initiatives is a desire to foster a broader and more direct communication among project developers -- with a desire to achieve the high quality and faster release cycles emblematic of open source.

This is a powerful illustration of how the practices of open source are diffusing well beyond activities that would fit the OSI definition of open source. 

What's interesting to me is that the motivation for these activities varies enormously. In the case of the consortium, it's a desire to see if better alternatives than the poor quality verticals available in the industry are possible. The governmental body wants to ensure that consistent processes are used throughout the different agencies. The multinational is focused on reducing costs and gaining re-use among independent lines of business -- even though each of the business lines is profitable doing its own development, the holding company can see that increased profitability is possible if applications are shared among the different entities.

All of the organizations have questions around community. How do you start one? How can you nurture a community? How do you get indifferent (or even competitive) organizations to cooperate? How can you tell if you're succeeding?

Because open source just "seems to work," it's not easy to extract the underlying principles of community success. While not pretending to be comprehensive, here are some things that must be present for community to have any chance of working:

• Don't boil the ocean. Start small and build upon success. A limited project with participants from only three or four different organizations will allow them to feel their way toward a working style that makes sense. One thing to keep in mind is that despite the phrase often heard: the "open source community," each product has its own community with unique characteristics developed through time and reflecting the personalities and working styles of the individuals involved. Let your first projects incubate and grow from hatchlings.
• Avoid dictates from above. I guarantee you, no participant will fail to remember that there are real-world needs and constraints that affect the project -- organizational deadlines, regulatory or legal requirements, and so on. Set out the goal and let the team figure out how to get there. This may be the most difficult challenge for traditional managers; it feels ephemeral and disorderly, but letting the community figure out its path to success is vital -- otherwise, the "community" will be no more successful than the quality circles of the 80's that were really nothing more than covert manipulation.
• Reward the participants for their efforts. After all, this is something different, and, as the cliche goes, humans hate change. If people step up to trying something new and make a go of it, give them something in return.
• Reinforce the effort with old-fashioned interpersonal interaction. In this world of remote outsourcing, telecommuting, and self-management, it's easy to forget how much face-to-face interaction can accomplish in developing bonds between people. Hold biannual community meetings in interesting places. Create an agenda that allows people to show off what they're working on. And be sure to allow plenty of time for informal conversations, because that's where the strong working relationships and great ideas happen.

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.