A colleague of mine pointed me to an interesting post titled Resource Fetishism by Jono, who is Ubuntu Community Manager for Canonical, and looks after the world-wide community of Ubuntu contributors and developers. (Ubuntu is a community developed Linux-based operating system).
In his post, Jono paints this common problem:
Its funny how the same approximate process seems to happen for many communities, and sub-communities in projects. It happens a little like this:
- A new team forms from a small group of enthusiasts.
- They create a raft of resources - version control, repositories, mailing lists, IRC channels, bug trackers, councils, forums etc.
- A discussion happens on the new mailing list about which website CMS to use.
- The discussion lasts approximately a month. There are many opinions. Bickering ensues. It turns into a Drupal vs. Wordpress war.
- Two months pass, little has been achieved other than yet more CMS arguments archived to the Internet.
The problem here is a lack of focus on what is important - building a team.
So, obviously the challenges of "community" building exist as much in the open-source world as inside organizations.
One of the advantages of Web 2.0 inside the enterprise is how reportedly easy the tools are to use for a variety of purposes. Emerging best practice studies point to bringing together a tool "suite" and letting users pick the right one for the situation / task at hand, but there is potential for debate on tools/technology & configuration to overshadow the whole point of a group coming together.
As Jono's story illustrates, more important than the tools is focusing on connecting people, community development, and good group process for the community to maintain momentum, activity and value.