The first two posts in this series looked at how to market your open source project or package looking into the question what marketing is anyway and how to tell the world that you exist. After you have followed the instructionsin those two articles, some word about your project/package is out in the world and hopefully you will have made connections with a few interested people.
Momentum and Rhythm
To ensure that all this initial effort enables you to build a real community around your open source project or package, you will need to apply the techniques explained earlier again and again in different guises. Before I go into detail, let me look at two factors that are important ingredients in building a sustainable community: Momentum and Rhythm.
The first realization is that you are more likely to attract people to an open source project if others have already visibly joined it. It’s part of human nature: everybody wants to be friends with somebody popular who already has friends; nobody wants to be friends with a loner. When I look at an open source project for the first time, I tend to check a few things:
- Is there traffic on the mailing list (or whatever communication medium is used)
- Are there other signs of activity, such as a changing news section on the web page, regular changes in the code and bug database, regular releases, etc.
By doing this I am checking whether there is activity in the project/package, i.e. whether there is momentum. Visible signs of momentum, show me that time and energy is invested into the project and thus it is probably safe for me to do the same.
Communicating with your audience using a regular and well defined time table (i.e. rhythm) can help build momentum, or at least it will create a perception that there is momentum. This works a bit like creating a sustained wave by regularly dispensing a drop of water into a bowl of water.
This analogy reveals a few simple insights:
- Release the next drop, before the wave from the previous drop has completely dissapeared. In other words, communicate while people still remember the last communication.
- The size of the released drop does not matter. In other words, it is OK to say smaller things that do not need a lot of effort more frequently.
Besides the fact that rhythm helps build momentum, it will ensure that you actually communicate. A schedule will also limit the time you spend on communicating (vs. coding) and remind you that you need to communicate. For example, you could decide that: a) once a year you will aim to talk at a conference, b) twice a year, you will release a press release as explained in part 2, c) once a month you will spend 2 hours writing something on the blog and finally d) once a week, you will spend time responding to requests in your bug databse, merging code, etc.
That means you need something new to talk about on an ongoing basis. This may sound hard, but is actually easy. Let’s look at a few ideas.
Mailing lists, Bugzilla, Code
Given that you lead an open source project/package you should encourage everybody who asks you a question to do this publicly on your mailing list or forum. If you work in a commercial open source community, such as Symbian, the likelyhood is that you are part of an existing team working for a commercial organisation.
The easiest way to show that there is momentum is to lead technical discussions on your mailing list. This can be harder than it sounds: you may need to overcome resistance or existing habits in your organisation. Sometimes you will need to force yourself to use a mailing list rather than just walking over to a colleage. If you have problems with this, put a big sticker at the bottom of the screen asking the question: Have I used the mailing list today? The bottom line is that if you do not lead by example, others won’t follow. If the mailing list shows no activity, attempts to build momentum in other ways will not have much of an effect. As a bit of a test: check out this mailing list vs. this one and assess what you feel and which community you would join after having looked at the list.
Another really easy way to show that stuff is happening at a technical level is to
- regularly publish code (rather than develop privately for months and then publish it)
- to respond to requests coming in through your bug tracker and responding to queries swiftly
An alive mailing list, code base and bug tracker are essential, but will only get you so far. These are communication channels, which are of interest to people who already know about you and are maybe looking for your project. The key question is how to engage other people and companies.
This is where regular news comes in. The easiest way to communicate regular news is to use a blog. If you are part of a larger community, you can share a blog (as we do with this blog). If you have a blog up sign up up to at least one feed aggregator such as your community open source planet (see Symbian Community Planet, Planet Eclipse, …).
What counts as news? Almost everything related to your project/package and also about you personally. Here are a few ideas:
- If you start or finish developing a set of features, write about it!
- If a company or individual agreed to start work on bigger task in your project, write about it!
- You just completed a design, prototype, or similar write about it!
- When you publish a new release write about it with a list of what’s new and cool.
- Have you run into some interesting technical problems developing a new feature: write about it!
- You made significant changes to your web page, wiki, wish list, etc. Write about it!
- Did another project pop up that competes with you? Write about it!
- Did you go to a conference, meet some interesting people, somebody made a contribution or raised a few good bugs: write about it.
- Are you planning to go to a conference, meetup, etc. Write about it!
Anything to create a story will do: and stories related to your project/package can be short and should be easy to write. The stories do not have to be long. What is important is that you always link from the story back to your web site and/or project landing page. You also want to do this the other way round: embed RSS feeds into your landing page, wiki, website such that it refers to the latest stories. Using twitter, digg, etc. can be used to increase the impact of your stories.
Every now and then you want to do something special to build interest. Typically when you have a bigger news story. This could be a large contribution, a new release, etc. You can consider a press release as explained in part 2 of this series.
Conferences and meetups are a good way to promote your project. Just attending an open source conference provides opportunities to talk about your project to new people. Talk to people while you are at a conference, open source convention or meetup: most are designed to make it easy to connect to people. Approach speakers after a talk, etc. But remember: many people are at here for a purpose: so asking first why somebody is attending and bringing your story in if it fits is better than starting with “I am here because…”
Talks: You will get the most out of attending a conference if you give a talk about your project. However, often competition to get a talking slot in a conference is quite tough. It is worth remembering the following points when writing a session proposals
- Don’t make the proposal sound like a vendor pitch
- People attend conferences to learn how to do something or how to solve a problem. Make sure you explain what the attendees will learn from your session.
Even if your project/package solves a real-world problem, your chances to get a talk accepted increases if the project/package is not the focus of the submission. But, make use of the one line or one paragraph version of the project/package description which we covered in part 2 of this series. If you don’t get admitted for a talk, BoFs are often another option.
Articles: As your project/package matures and gets better known you may be approached by websites, blogs, magazines, etc. to write articles. If you get the opportunity use it! If you are part of a larger community, make use of community managers to help you review the article and promote it after it has been published!
Other simple things to keep yourself talked about
Your e-mail signature is a bit of advertising space. Attach a signature that contains
- Project/package name
- The one line description of your project/package
- A URL to your project landing page or website
You can normally even do this if you work for a large company, but you should check with your boss. If you have a team or community, get team and community members to do the same. You probably want to use a URL shortening service such as Tiny.URL, but make sure you use a custom URL alias. Most URL shortening services allow you to do this.
Branded T-shirts: Many open source projects have a mascot or logo and use T-shirts. Most of them, wont have budget to print up a bunch of T-shirts. So how do open source projects do this? You can use sites such as Printfection to create tshirts that others pay for when they want it. Also if you are part of a larger community, your open source foundation may help create branding for your project/package.
Business cards are very cheap to make today. If you do not work for a company, creating some fun business cards for your project, with the one line description of your project/package, a URL to your web site/portal/landing page and a contact person (probably you). Even if you work for a company, having project specific business cards may be OK: do check with your boss.
Parties & Meetups: Parties and meetups are a a great way to connect to new people and to reward people who have worked with you. If you have a big milestone coming up, a party is a great way to celebrate. It does not have to be big or expensive. It can be as simple as in a pub or bar: all you need to do is to announce on your blog, mailing list, tweet about it, etc. It is a good idea to take pictures and use the material on your blog afterwards. And you need to have a way for people to recognize you, such as a silly hat, t-shirt or similar.
Be polite and patient!
Building a community around a project is not easy: it can take up to a year (and sometimes longer) to build up enough momentum for an open source project to take off. It rarely takes less than a year! Also, not everybody you will talk to, will become part of your community. When talking to open source leaders at the CLS the common figure of converting people that have joined your mailing lists to active contributors was about 3-5%. People will come and go.
This means that if there is significant progress, the experience will be very exciting and exhilarating. When progress is slow, things can get frustrating. One piece of advice to remember is: always be considerate and polite! Choose your words carefully and gently. At the end of the day, community is often about people and people issues. This means that being polite goes a long way!