In an age when anyone over 45 seems to have a story about the end of local community and how "everyone used to leave their doors unlocked," community has never thrived so much in the Open Source world.
Although it is true that Open Source and Free Software fundamentally revolve around the rather technical and programming-oriented concept of freely available software, there is a phenomenal amount of diversity of contributions in the Open Source community.
We don't just have one huge blob of people called "the Open Source community," but instead thousands of smaller groups, each interested in a specific portion of the community – whether it's documentation, translations, local advocacy, mapping, testing, gaming, or indeed programming. Although each group focuses in on their particular area, the global network of groups fits together like a jigsaw puzzle to form the wider Open Source movement that we all know and love.
For some people getting started in Open Source, it feels like other people set up communities. You install Linux, you play with it, you realize you want to contribute to it, you figure out what kind of contributions interest you (documentation, advocacy, coding, etc.), and you look for a community to fit in to.
In many cases, you can find a home to make your contribution, but sometimes you reach a dead end or worse: a community that exists but is doing nothing. One that's merely kept on life support by a few interested yet busy members.
In this article, I am going to discuss how to build a community, more specifically an Ubuntu LoCo team (Figure 1). Whether you want to help get an existing team on its feet or create an entirely new team, everything in this article is designed for you.
Not only that, but everything here can be applied to both online and offline communities – from technical software communities to quaint local book clubs.
Alrighty then, grab that cup of coffee, sneak away a cookie, and get ready to build an empire…
I will use an Ubuntu LoCo Team as an example of a local community group to create. LoCo teams are locally based collections of enthusiastic Ubuntu fans who get together to talk about Ubuntu and Open Source, get technical support from each other, and often spread the word about Linux in their local area.
When I first got involved in Open Source, the very first community I created was a Linux User Group (Wolverhampton LUG) and setting it up was a hugely fun and rewarding experience.
So, in the interests of my future Oscar nomination, for which I will naturally thank the academy, I will assume the role of Jono Bacon who lives in Hill Valley, a sleepy little town devoid of a LoCo Team, which I am about to set up in the interests of rocking the worlds of local Linux fans. And, I will describe the necessary steps.
Setting up a team involves three primary tasks:
*1. Set Up Resources – You first need to set up some important tools and resources that your group will need to function, such as methods of communication, a website, and some other requirements.
*2. Plan Projects – The greatest communities do good work and do it well, so I will describe how to plan and run projects successfully.
*3. Build Buzz – With a home set up and some projects in place, you then need to then tell the world about your group and get people pumped up about joining you.
Although each of these elements will be discussed within the context of setting up the Hill Valley Linux LoCo Team (HVLT), the approaches outlined here can be applied to any community you want to set up (Figure 2).
When you have decided what you want your team to do (e.g., providing support and advocacy in the case of the Hill Valley LoCo Team), you need to first figure out what resources you need to get the group up and running.
All communities need a home, they need a place to communicate, and they need certain tools to do their work, so this is the very first order of business. Obviously, because of space constraints, I won't delve into all the technical details of how to get these resources set up but will instead point out the major tools your community is likely to need and some pointers and pitfalls in getting them up and running.
For the majority of communities, you need to satisfy the following requirements:
With these different elements brought together, you have everything you need to communicate together, work on projects as a group, and have a public presence so that others can find your group and get involved. I'll take a quick spin through each of these elements now.
Communication is a critical component in a community. When people can communicate freely and easily, communities feel like vibrant, thriving places. When communication is unclear, clunky, or restrictive, communities feel boring and devoid of life.
Setting up great communication channels involves not only picking suitable media but also building a culture of positive tone and communication on top of them.
I'll look at the media first. Fortunately, you have a range of different options for your groups. These include:
By far the most popular method of communication in most communities, and particularly Ubuntu, are mailing lists. I recommend that you set up a mailing list as your main communication medium, and you may also want to set up an IRC channel for more interactive discussions.
Aside from choosing you communication media, you should strive to keep the communication active and pleasant.
Many communities, and particularly those in the Open Source world, collaborate on projects to produce content (Figure 3). A huge range of tools out there are designed for various types of collaboration (e.g. programming, writing, testing, design, translations, etc.). You should assess which tools your community needs to do its work and provide simple and freely available access to them.
As an example, if you want to do software development, you will likely need code hosting, bug tracking, and translations tools. Various free online software development sites provide these services such as Launchpad [4] and GitHub [5].
On the topic of external sites providing the tools you need, you should always be a little wary of being sucked into the well of hosting your own tools. Although many of you can set up and provide your own self-hosted tools, I heavily recommend that you use a third-party site (e.g., Launchpad). A third-party site has a team that ensures the site stays online, has security fixes, and protects your data. When you maintain hosted tools yourself, you will get busy at some point, and it will become a burden.
The HVLT is most likely to collaborate on documentation and content (e.g., HOWTO guides for the group, other documentation, and promotional literature about Linux). For these kinds of collaborative documentation needs, a wiki is a perfect solution. Wikis provide an editable web page that anyone can contribute to, and they are simple to use. Thankfully, there's an Ubuntu wiki [6] that you can use right away!
A website is essential for any community group. Websites are how people will find you. They provide a vessel to share the benefits of your group to prospective community members, and they provide important details about events and other group activities.
Unfortunately, setting up the group's website is where many teams experience their first problems. The reason is largely because of the personality trait that knits us all together: We are geeks, and as geeks we like to debate software preferences. Unfortunately, this can often devolve into weeks of debate about this content management system versus that one, their respective benefits, and other inane and often irrelevant chatter.
In these situations, it is important to remember that the "content" in a Content Management System is more important than the "management system." In other words: Just pick something and move on. Some people may be unhappy, but stress the importance of making progress and moving the group forward, and the debate will eventually pass.
Several great free providers are available for getting a website online, and I would highly recommend WordPress as a good start. It is a mature and popular content management system; it provides the means for multiple authors to post content, and the service is reliable. Whether you use WordPress or something else, find a provider, get your site online, and start creating content.
When creating your website, you need to provide some "must-have" pieces of content that most of your visitors will look for. These are:
A very common mistake many new communities make when creating a website is to make the language overly complicated and unattractive. As an example, for HVLT, we welcome the full spectrum of users (both new users and experts alike) into our group. That means the language on the website must be simple and accessible for this range of users; otherwise, some users will get confused, grow bored, and move on.
A great way of preventing this is to get feedback from new members: Ask them what they thought of the website and whether anything needs to be improved and simplified.
With your resources and communication channels up and running, the next step is to decide what type of projects your group wants to work on. For some teams, this will be obvious; a software development team focuses their efforts on a software project, a documentation team writes content, and a translation team decides what to translate and into which language. For some teams, however, this is a little less obvious.
One challenge that every team faces is the ability to coordinate what goals and ambitions the team is going to work on and to unite the group around an agreed set of projects. Traditionally, this process has been somewhat ad hoc: People join a team and work on whatever they feel like.
One of the most wonderful elements of a community is that there is no manager telling you what to do, and the environment produces an incredible sense of creativity and fresh ideas. Every community every day finds themselves knee-deep in ideas that sound fun, rewarding, and that ultimately satisfy the purpose of the group.
Ideas are cheap, though. For some communities, coordinating this work can seem complex. Some projects require coordination across many people with different skill sets, time availability, and resources. For example, if HVLT wants to produce a regionally focused booklet that explains what Ubuntu is and provides an introductory tutorial, the project likely needs people with the following skills:
Many communities don't take a particularly organized approach to these types of projects, and that can kill motivation in the team. If there's one thing that will cause a community to struggle, it's a sense that nothing happens and nothing gets done. Providing a more structured way of organizing projects and documenting how they will work and who is working on which parts is known as a specification , and it has a number of benefits:
The first step is to open up a discussion with your team to talk about the things that the team would like to do. The most effective way to have this conversation is to produce a wiki page in which people can jot down their ideas and work on them together.
This process provides the foundation of converting popular ideas into more specific and concrete items. Keep the discussion focused on the project and what is doable. Always make sure you have these discussions out in the open in your team communication channels, whether that means mailing lists, IRC channels, or otherwise.
Once you have a set of ideas for a particular project (e.g., creating HVLT's booklet), it is recommended that you drill the ideas down into a specification for each project.
This specification will again form a set of commitments that outline what is involved in completing the project and who is going to be doing what. A wiki is also a great place to do this.
Over the past few years, I have developed a useful format for documenting these plans. For each project, note down these key pieces of information:
To illustrate the elements, here is an example of a simple plan for running a demo event at Hill Valley library:
Although it may take a little bit of extra work to put together your plan for a project, it will dramatically improve the project's chances of success. This in turn makes the group feel nimble and effective.
Although plans and specifications are a great way to ensure project work is spread out across the team and well structured, this alone will not guarantee a project's success or the growth of the group. To stay on track you need to regularly get the team together and focus their efforts on current projects, highlight problems, solve them, and talk about new ideas and challenges. A great way to do this is to have regular meetings.
With your team up and running, resources in place, and projects to work on, now is the time to build some buzz and excitement about the group and encourage people to join you.
Thanks to the work you have already done in putting together your website and communications channels, you have plenty of interesting and fun things to point to that can help show off your group. Now is the time to make some noise, my friends.
Fortunately, many options are open to you for spreading the word about your community and what you are working on. First, however, you need to create the messages and content that you will spread. This content divides into two broad areas:
Decide what kind of content is most appropriate for your group and work together as a team to produce it. As each piece of content is completed, make sure it's available to the full group so everyone can use it to spread the word. A great place to do this is to put it on your community's website.
Now it is time to get out there and spread this content. You can build buzz online and offline in a variety of ways. I'll start with some online ideas:
Although the online world is a breeding ground for technical community members, there are also some great offline ways to build buzz:
Not all of these approaches will generate new members, and not all will be successful, but the more places you try to raise awareness of the team, the greater the potential for people joining you.
In this article, I explored many elements of how to get a productive and fun community group up and running, but I have merely scratched the surface. Communities are large and complex beasts involving many different skills, and I have just covered some of the core elements here.
If you want to learn more, I wrote a book about how to build a community called The Art of Community published by O'Reilly. It is available in all good bookshops and also as a free PDF online [9]. I recommend you take a look.
Good luck with your community adventures and remember to let us know how you get on! l
Infos