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.
Every community that forms needs resources. It needs facilities and tools that people can use to achieve the goals they set for the project. But when starting a new project, there is so much excitement and anticipation, and this combined with the freedom to create resources easily, means that a lot of unnecessary tools and facilities get set up. In these cases, the focus is taken away from the intended goals of the project, and is instead dialed into debates about these tools and implementations. The problem is that too many tools and resources can actually be detrimental to a project.
Lets look at mailing lists as an example. Pretty much every project needs a mailing list. It is typically the primary medium for communication. But even with just mailing lists there is a strong temptation to not just create a single list such as *myproject-devel* but to also create *myproject-discuss*, *myproject-announce*, *myproject-users*, *myproject-commits* etc. Hey, if you set up a mailman server, you may as well make use of it and create a bunch of lists, right?
The same temptation can occur with forums. So many projects go out and set up a phpBB forum on a server somewhere and instead of creating a single forum, they produce 10 different forums – *General Discussion*, *Feature Ideas*, *Technical Problems*, *Announcements*, *Offtopic* etc. Hey, if you go to the time and effort of setting up a phpBB server, why not have a large array of forums – other sites do, why not yours?
And herein lies the problem, my trigger-happy friends. Just because you have the ability to create more than one mailing list, more than one forum, more than one VCS, more than one bug tracker or more than one anything else, does not mean it makes sense for your project to do so.
The reason why it is a problem is that it *fragments your community*.
The hardest element in building a community is gaining critical mass. The first order of business with new communities is to get them up and running, with a regular flow of traffic and development. You want your community to feel busy, thriving and productive. The reason why such tool-fetishism seems to happen is because it is assumed that to achieve the *regular flow of development* part of your community, you need a strong set of tools available. Wrong. You need the *appropriate* tools and some strong guidance, focus and direction. This direction can only be achieved when you have all the eyes in your project looking in the same place – and when you have 5 mailing lists, 10 forums and a bunch of other distractions, your project loses focus, and problems set in. As such, I recommend that you have one primary medium of discussion (such as one mailing list), one primary web-page, and only the required resources for getting your project under-way (e.g. bug tracking and a (D)VCS).
Of course, this is not to say that multiple lists and forums are not useful – they are. But every project has a life-cycle, and the time for these additional lists and forums are when the project is mature, running and productive. The primary focus in the critical opening few weeks should be on growing a team, not growing a mailing list archive.
Earlier in this post I referenced another element of tool fetishism – debates over CMSs. I see this time and time again with communities, and in the Ubuntu LoCo team world I recommend all teams to simply create pages on wiki.ubuntu.com and get started there. CMSs are nothing more than a distraction when teams get started. The focus and discussion in the first two weeks should not be about arguing about which CMS to use – it merely distracts away from the core purpose of building a team. Sure, people need to jot things down somewhere online, and people need to be pointed at a page about the team, but a wiki is perfectly suitable for this. A wiki may not be as sexy as a CMS, but an inactive team is the pure definition of “not sexy”.
So, the rule of thumb in this post is – when starting a new Open Source project, keep your eyes on the prize and your efforts focused on building a team, and don’t be tempted by these distractions. I can assure you it will put your team in better stead.
