Don’t allow old project ideas

I allowed a few project ideas from 2010 into the 2011 list. None of them were very popular with students. I think there are two reasons:

• It’s too easy for mentors to just pick up an old idea. In the end there is a risk that the mentor doesn’t take GSoC and engaging with the students as seriously as he should and don’t get into the right mindset.
• Applying for a GSoC project is a bit of a gamble for students too: good students will look at ideas lists from several years and will notice that an idea is old and just not apply.

So, if an old idea is used (because it is still relevant), it is probably best to totally re-evaluate and write it from scratch.

Pro-active mentors = Lots of good student applications

We had 13 mentors, who fell roughly into two camps. Mentors who communicated with the students, but could have done better. Mentors who replied to students questions within a couple of days and ensured that there was communication about the proposal, the background, how to solve the actual problem, etc. Much of this discussion happened on a dedicated IRC channel. The projects by the mentors which were pro-active, had more student applications and the applications were of higher quality. As a result, the students working with pro-active mentors were more likely to win. Not entirely surprising. The lesson is, that as an org admin, it is important to work with the mentors early on and filter out proposals early if it becomes clear that the mentors behind these are may not be fully committed.

Unsolicited proposals need discussion with a mentor to succeed

We had a number of unsolicited GSoC proposals. They fell into two categories:

• The proposal just appeared with little or no discussion with the mentor; in some case no mentor could be found. Needless to say, the proposal could not succeed.
• The proposal idea was raised by the student in the community, which helped find a mentor early on. We had two such proposals, one of which succeeded.

As an org admin, the challenge is to provide ways of enabling this in a structured way.

A dedicated IRC channel and IRC meetings work

We created a dedicated IRC channel where I and a few of our mentors were present at certain times of the week for students to ask questions. The channel also was used as a channel for mentors and students to have an IRC discussion at an agreed time. We also had a timed open IRC meeting which worked very well. Maybe one meeting is not enough: probably running one at the beginning and one towards the end of the application period is better.

Build gates and motivators into your program

Having a few goals to work towards, both for mentors and students helps focus minds. The GSoC timetable does this, but this is not enough. For example, some of our mentors participated in a mentor meeting early on, to discuss and formulate project ideas. The result were well formulated ideas. The meeting also helped build relationships amongst mentors: agreeing on which students should be chosen can be divisive and knowing each other helps. IRC meetings were good to stimulate engagement between students and mentors and led to draft proposals being made available by students early. And we had mentor meetings to rank student proposals (I disabled the ranking mechanism and forced mentors to attend the meetings).

Encourage good students to hedge their bets

We had a few projects, which had 5 students competing with each other. You could end up in a situation where the top 5 students apply for one project and only one can win. If there was an engaged discussion between mentor and student, the mentor will get a feeling for such situations and should encourage students to apply for another project, or even two. However, this only really works if mentors work together and co-ordinate.

A well run program will lead to repeat applications

Despite having to turn away good students (we just had too many good proposals), we had a few students thanking us for giving them support and leading them through the process. Hopefully these students will apply again in the following year and succeed.

Becoming manager of existing social networks, groups, etc.

The community I work has a presence in 40+ different social networks and other on-line services. Some support the concept of a group admin/manager. Others don’t and admin rights tend to be tied to a specific user ID. When you try and take over management of some social networks you can end up in a number of situations.

• The easy one is where there is the concept of an admin or manager: all you need to do is to ask another admin/manager to promote you to manager. Now this works easily if you your existing manager cares and knows their log-in details. Which for me was luckily mostly true.
• The more probematic case is where managing a group is tied to a specific account and manager ownership cannot be transferred: there are quite a few sites where this is the case. What you essentially need to do is: get the password and change the profile. If the profile was personal, e.g. Joe Bloggs, make it generic (i.e. changed it from Joe Bloggs to Xen Community Manager) otherwise the next person will face the same problems. I also changed the profile such that it mentioned that Joe Blogs was community manager during a specific time period. This was necessary because some of the hitsory in comments refers to Joe Bloggs, which may confuse users.
• The worst case scenario is where the management role is tied to a specific universal ID and cannot be changed (such as a Google, Twitter or Facebook ID). I was surprised to find out that there are a quite few such services. In this case, you are stuck if your predecessor has used a personal ID which he/she will want to continue to use.

It was a little bit surprised that a seemingly simple task like taking over the management of a few social networks was actually hard, tedious and rather inconvenient. Much harder than it should have beeen.

You can also run into other interesting problems:

• A previous manager may have forgotton a password
• Or their account was tied to an e-mail address which does not exist any more (because he left a few months back)
• In the meantime the account may have been disabled because an e-mail to said account bounces

From my experience dealing with the support teams from some of the free social networks and services was slow and painful; in some cases non-existent. Where there was really good support, these services obviously needed to ensure that you didn’t try and abuse the service and take over somebodies identity. A disabled e-mail address does not help there.

Thus, plan for the future

The only way how to avoid such problems is to plan for the future. Basically you need to assume that you are run over by a bus tomorrow and ask yourself the question how easy would it be for successor to get started.

Here are some tips how to do this:

• Where there are admins, make sure there are always several admins besides you. Make sure you always keep the list of admins up-to-date (i.e. replace an inactive admin with a new one).
• Make sure the list of admins is written down somewhere. Some services don’t allow you to see who their admins are: so if you don’t know you can’t contact them. Googler Analytics is an example of one of those services.
• Avoid using user IDs that are tied to your person. It’s OK to use your e-mail address if it is not used to identify your account and can be changed later.
• Be careful not to use your personal twitter, google or other ID to create a new group. In particular when you know it cannot be changed later: or when you do not know. In this case, you probably want to create an identity which is tied to the job rather than yourself.
• Make sure passwords are stored somewhere and shared with at least another person in your organisation.

Getting on top of the social media landscape

When you start in a new community, one of the other challenges is to find out what goes on on the web. The easiest way to do this, is to use commercial tools such as Lithium or Radian6 (note that by far these are not the only ones; google for “Social Media Monitoring” to find such services). Unfortunately almost all of these services are incredibly expensive and practically out-of-reach for open source users.

There are free alternatives

There are a number of free alternatives: you can use socialmention.com, which works really well if your project or community has a unique name. Google alerts also works well in this case. You start getting into trouble when your project has a common name. Well, Xen is such a common name and you will need to use complex search expressions to exclude keywords as you come across false positives. In the case of Xen, I need to exclude an ever growing list of terms such as guru, travel, incense, art, yoga, … you name it. In this case, brush up your skills on creating complex search expressions (I thought I saved a link for you, but didn’t … sorry).

However I found that even with complex search expressions, you still will get a lot of noise. So the only way how to eventually get on top of these is to use Google Reader, Yahoo Pipes or tarpipe to create yourself an aggregated stream of trustworthy sources as you come across them using search, socialmention, etc.

You should also be able to use Google Custom Search, but I have not tried this.

How do others cope?

This is it for today: my bit of recent wisdom. I would really be interested to hear how others in open source or other community managers grapple with these problems.

And, I promise that I will at least write one article per month from now on.

For me this also means a departure from mobile computing and venturing into cloud computing and virtualization. I will stay however on the board of Symbian DevCo and help see it through the difficult times the transition of the Symbian Foundation has caused.

With regards to this blog: it will continue as its focus is on sharing open source and community building stories. When we set up this blog, the intention was to use it as a collaborative hub for sharing and learning about community building problems. All of the initial contributors have worked for the Symbian Foundation; so it remains to be seen whether the blog will become truly collaborative or whether it will morph into my personal blog.

In any case: if you have a good community building story or need help writing such a story, get in touch.

In summer, I took on a board seat at Symbian Devco, an organisation whose aim it was to give individuals a bigger role in the Symbian open source community. DevCo is (almost) entirely independent of the Symbian Foundation. The only dependency was that the Foundation was nice enough to host the DevCo website, help out with admin work and pay for a number of legal services.

It was my hope, that DevCo could continue in the event of the foundation closing. Unfortunately this hope was put to the test before a real community could form around DevCo. Just when the first issues were raised, such as “it really isn’t good for Symbian and MeeGo if there are two different Qt implementations”, which is essentially the direction things were going, events overtook us. First Nokia did make the right decision on Qt and then came the news about the Symbian Foundation.

At this stage, it was not at all clear whether Symbian DevCo would survive. To save DevCo, we had to go through a number of steps:

• Get backing amongst the board and advisory council
• Get enough of a vote to c0ntinue
• Find a new purpose
• Find somebody hosting the website
• Find some volunteers who would run everything – some of this was previously done
• Do some paperwork

At the beginning, it looked as if we wouldn’t get enough backing together. We started a discussion and a vote and at first it didn’t seem it would go anywhere. I am pleased to say that it does look as if we will be able to continue for some time. I have been impressed by people stepping up and volunteering. It took a while to build momentum: the news that Symbian Foundation would shut down the Symbian web-sites has helped focus minds. It became clear to many of our members that there is no home for the Symbian open source community any more, at least until Nokia has made their move.

The web-site has almost been moved to a new location (we are testing at the moment and the DNS has to be changed). We have some ideas on what the new vision will be. There has been really good grassroots support and more than a dozen people who are willing to volunteer and invest a little bit of time. There has been great support from what is left of the foundation and from All About Symbian. The legal set-up of DevCo has also some positive consequences, which should help Symbian centric open source projects such as Wild Ducks.

At this stage Symbian DevCo has a fighting chance to remain and fight for the interests of its community. I will let you know when I know more. It even looks as if we may be able to keep some Symbian Foundation web services, such as the Wiki as a proper Wiki instance running.

I am rather humbled. Thank you for the support. Let’s hope we can pull this off.

Before I go there, I wanted to share though why I think this is necessary. The background is a situation where many engineers from within the Symbian eco-system, with little hands-on open source practice suddenly faced the challenge of  becoming making open source work for them and their employers. Although there is now some really good literature out there, such as The Art of Community by Jono Bacon and the Open Source Way by Red Hat, I found that many of the people I worked with found both books too verbose, or the latter too much geared towards the use of tools and open source as a business. When I followed up with a few of our project lead, what they were really looking for was “a model of  building communties described in terms of architecturual diagrams, supported by not more than 20 pages of documentation“.

Is it possible to do this? First I was sceptical: after all open source communities are as much about people, as well as business needs and technology. People problems are often hard to express. Nevertheless, I had a first go at it and managed to put a crude, but not that well defined model in place and trialled with a few people with moderate success. At the Community Leadership Summit in Portland I hosted a session with other community managers, which was interesting but we didn’t end up with a model. I participated in many of the other sessions and came to the conclusion, that this can be done. I came away with many ideas mixed with my own experiences, with a core model and its basic elements in my head and lots of scraps and ideas on pieces of paper. Some of it I managed to develop on this blog, others I didn’t as my work-life got rather busy and I had no time to pick this up.

So what next? I hope I can spend some time on the model and publish installments on this blog over the coming months. By floating the idea publicly, I am putting myself under to get going. I am confident, that there will also be lots of discussion and conversation that will influence the evolution of the model. Am looking forward to it!

The reason for this is mainly that I am not a multi-tasker. I tend to single-mindedly work on one task at a time, and usually only have one (at most two) windows open on my desktop (I may have a few minimized though). For that reason, applications such as Tweetdeck do not appeal much to me. The same is true for RSS and news readers. Although I have these apps installed, I hardly ever use them.

If I didn’t have a Twitter client on my phone, I would probably have long given up on Twitter altogether. I have been using the GRAVITY twitter client for a year: typically on the way to or from work and sometimes at lunchtime. My usage of Twitter has thus been restricted to posting interesting snapshots and photos orchids taken with my phone, the odd patchy conversation, retweeting what other people found and tweeting the occasional announcement. Not much to build up a big following. Partly a consequence of using Twitter only at certain times of the day.

This started to change for me when I came across Layman’s Take on Gravity. I decided to try Gravity’s Google Reader and Facebook support. As a consequence I use Gravity now as the main tool to keep on top of news sources for work and also privately. I use Twitter and ,more often and keep on top of what is happening on forums and blogs that I otherwise would only check occasionally. I also more often tweet articles that I read, simply by pressing a button.

Before I did not do this often because the process was too inconvenient for a single-tasker like me: having to open twitter.com or Tweetdeck, shorten URLs, copy and paste the URL, etc. etc. is far too annoying, even if you have browser plug-ins.  Many news sites on the web have widgets that integrate withT witter, Facebook, etc.: well, my consciousness filters them out like ads or I get annoyed when I click them and then have to log into another site before being able to do something.

The simple consequence is that because of Gravity I use Twitter more and that I keep on top of news (before I would check maybe once a week and then mark everything unread because I did not have enough time to check everything). In fact I am seeing clear signs of change with regards to my web usage patterns. What this shows is how powerful simple integration of social media can be. If it is simple to use,  it even has the power of changing the usage habits of somebody as single minded as me. This means that projects such as the Social Mobile Framework can have a huge impact on the life and habits of mobile users. I will certainly watch what happens with such technologies in future.

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.

Regular News

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.

Promotions

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!

how to market your open source project or package

However none of the groundwork matters, if the world does not know you exist. I use the term advertising in the widest sense, to tell the world that you do exist. The first thing to realize is that advertising is not a one-off thing: in a world of information overload, you need to constantly remind people that you exist. If you don’t, the world assumes you don’t exist any more. It’s that simple.

Defining your project or package

The first question somebody will ask themselves if they see information about your project/package is: what is it about? Remember, that your goal is to get your audience to invests their time, passion, code and feedback by contributing to your project/package.

To achieve this a brief and concise description of your project/package is essential. If you can’t summarize your project/package in a paragraph or even better a single sentence, you probably have not thought through what you are about. The more crunchy your description is, the easier it will be to catch somebody’s eye. The more accurate it is, the less you are in danger wasting anybody’s time.

A good approach to create your project/package description is to:

• Describe the project one one page of A4 paper
• Reduce it to one paragraph
• And then to one sentence

This will help you create a focussed description and material that you can use over and over when you start advertising.

If you cannot do this, it is worth getting more clarity on your audience, market, what you need and what you think your audience needs. If you are part of a bigger community, e.g. a Symbian package, the same principles still apply. Huge open source communities or foundations use the same techniques too: look at Eclipse which defines itself by Eclipse is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle.

Examples

The Symbian build package states that “the Build package provides everything you need to build the Symbian platform” and then goes into the extended version: “the tools can be used to build existing releases of the Symbian platform, but the package also supplies the (deprecated) tools for building earlier releases (it consolidates the former Build, Build Tools and Host Environment packages).” The visitor can at a glance determine if they should investigate further or move on. Which means neither your, nor the visitors time will be wasted.

This screenshot is from the Flying Saucer project. One paragraph tells the new reader everything they need to know: the library renders XML and XHTML content with CSS, and it is 100% Java. Again, immediately clear what the project is about.

Other good examples are:

• The summary of the Symbian kernel package
• The summary of the wild ducks project: “prove that it is possible for an individual or a small group of people to build a device running the Symbian platform“. A more eyecatching tagline of the summary has evolved over time: “Use the Symbian code and some off the shelf hardware to make a phone!”
• Or the summary of the homescreen package: “Provides the Homescreen and Menu applications, that enable the user to manage and use widgets and launch other applications“

Landing Pages, Google Code, etc.

For people to find you in today’s world you need a website: that site is the single place where people go to learn about your project or package. You are essentially competing with the world to get attention.

If you are part of a larger open source community such as Symbian or Eclipse you need an appealing and easy-to-find portal within the community website. You may not compete with the world to get attention, but you are competing with other projects within your community.

The first thing to note is that a project landing page or Google Code site is not a website. Landing pages can at most provide a short description of your package or project and otherwise link to lots of useful resources, tools and information. They are typically used by people who have a pretty good idea what they are looking for, but may for example not know how your project or package is called. This means that the text on such pages should be short (the 1 paragraph version) but have enough keywords in them to ensure that the page can be found through a keyword search. E.g. if your project/package implements “GPS” functionality on a mobile device, a search for “GPS” should  find your project/package.

That does not mean these pages are not important: because they provide links to tools and other resources, people who have an interest in your project/package will keep on coming back to the landing page. Although I can’t talk for other communities, at least at Symbian the web stats clearly show that this is the case. This means that the information on the landing page has to be up-to-date, concise and is also a good place to publish news (e.g. via an embedded twitter or blog feed).

Website

As I work within a larger community, I will not cover how to create your own independent website. What is worth mentioning though is that the primary function of the website is to

• help generate initial interest in your project/package
• create a foculpoint that is used to sustain interest

In a larger community the function of your website is fulfilled by a portal to your project/package which is hosted within the community website. In the Symbian community, as well as in many other communties, such portals are implemented using a Wiki.

To generate initial interest, it is important that the portal is visually interesting, gives the users a taste of what you are about and is picked up by google when searching for relevant keywords.

To retain interest, it is important to demonstrate substance and provide really useful information. This is something that often needs to grow and be cultivated over time. Understanding your audience (or audiences) and what they want is key to achieving that.

So what can or should the front-page of the portal contain?

• Re-use the one sentence or one paragraph version of what you are about and link to a longer version
• A mascot makes an immediate impact
• A news section (which is up-to-date)
• A statement of where you need help and how you can get involved
• Screenshots or videos of your software (if you have any)
• And links to other resources (i.e. your landing page)
• A calendar if you have meetings
• The portal should also link to documentation, areas of collaboration, plans, etc.

Rather than performing an analysis, I picked a few examples: check them out and let me and others know what you think by commenting to this post. The homescreen package, the wild ducks project and the persistent data package are all part of the Symbian community. I also picked out a few examples from other open source communities: the Eclipse e4 project, Apache Cocoon and Apache Mave.

If you are part of a large open source community, there are typically community managers or mentors that can help you with advice, contacts, good examples, etc. Make use of them! It will make your life easier.

Launching: initial advertising

At this point in time you understand your market, your audience, you probably have some code (or at least a project with some goals), a landing page and a website.  Now you need some real users and a community.

Step 1: Prepare!

One of the key lessons I have learned in the last two years is that preparation is everything!

Don’t go fully public until you are ready! If you do and you are not ready, people may come have a look, try something, see that you are not ready and disengage. Of course you can start a project before the code is ready, but you need to set expectations.

Getting some developer friends or team members to look over the landing page, the website portal and content and any other material you may have is a good idea. Take their feedback into account and fix what they find. Make use of community managers and mentors if you can!

Step 2: Communication

Remember that one paragraph description of your project/package that I suggested you create? That is the core of your communication. There are a fundamentally two ways how you can launch within an existing community: a press release or a story on a blog. There are a few things to consider: If you publish a story on a blog, not many others will pick it up (because it is not news any more). If you put together a press release, it goes to many bloggers and news outlets and a few of them will pick the story up. The purpose of the press release is that anybody with a newsblog has a concise description of what you have created and are about, spelled out so clearly that the author of the blog cannot get it wrong. In a nutshell, that is all a press release is.

If you have a mentor or community manager, get their help to launch. This person can help you with advice, contacts to the right blogs/news outlets, can help review, etc. Most of the time, all you need to do is ask.

Step 3: Build a bit of buzz

After getting a little coverage start submitting links to aggregators like Digg and Reddit. You could submit your own press release or blog, but press coverage of your project/package is considered more authentic than a link to your own blog or website and is thus likely to get rated higher.

You should also link to your project/package from Twitter, Facebook, LinkedIn and other social media. Your friends and connections are probably willing to spread the word just because they like you.

Keeping up the momentum

At this stage you will have some word about your project/package in the world and hopefully will have made connections with a few interested people. You will need to do this again and again and again … Remember: in today’s world you need to constantly remind people that you exist!

As this is yet another long blog post, I will cover how to keep yourself talked about and how to keep yourself motivated in another instalment.

Fact is that there are many open source projects out there today: this is also true in the Symbian community where we already have 140 packages and incubation projects. To get noticed you need to stand out, which means you need to use marketing techniques to connect your project or package to your users and contributors.

What is marketing?

The first piece of the puzzle is to understand what we mean by marketing. You may think marketing does not apply to you because you don’t sell your software or it is part of a solution which your marketing or sales department handles.

True, you may not sell the technology in your project/package for money, but you have a product and you want to attract customers in the widest sense. But you probably want your customers to invests their time, passion, code and feedback by contributing to your package or project (aka your product). This means that although no money changes hands, all the basic principles of marketing apply. To clarify the discussion I will use audience instead of customer and “product” instead of package or project.

• Research: Who is your audience? What do they want?
• Design: What does your “product” need to do to fit the needs of your audience
• Advertising: Making the world aware of your “product”
• Feedback: using feedback from your audience (and potential audience) to improve the first three.

Who is your audience (=market)?

The most important thing to find out when you start is to

• Know what you want to achieve (and whether you can actually do it)
• Identify your audience
• Find out what your audience wants
• See whether you can match what your audience wants, with what you want

The clearer you are about these, to more likely you are going to be successful. Let’s look at a few examples …

• Suppose you create an apache plugin to meet your needs as a website administrator, then your market might be other website administrators.  Your goal is to build a community of contributors around your plugin, such that you don’t have to maintain it alone forever. With some thinking and searching you can figure out who is your market and how to approach them.
• The wild ducks project aimed to prove that it is possible to build a phone from off-the shelf hardware components and the Symbian open source stack. The audience of the project are small companies who may want to experiment with commercially meaningful applications, services, and devices or researchers, hardware geeks and experimenters. As the project evolved, it became clear that there are other audiences: such as hardware vendors who were happy to invest time and money in developing hardware and software for the wild ducks hardware platform.
• The audience of many of the applications which are part of the Symbian platform will be their users. You should be able to identify these, but if you want them to contribute by writing code you are looking for users with the right programming skills. The challenge will be how to connect to users with programming skills.

One of the key take-aways is that there is no one-size fits all and that it is worth thinking hard about your audience.

What does your audience want?

When you have identified your audience, you need to get some clarity on what does your audience want? By thinking about your audience, you should be able to establish a few good assumptions.  Ultimately you will need to verify your assumptions and refine them by talking to individuals or companies. For example

• A number of Nokia device users wanted the Symbian^3 homescreen on older devices and the homescreen package has enabled and engaged those users in the homescreen backporting project. These users had some programming skills, but needed support, encouragment and documentation to get started, which the package has provided.
• The bug squad, is an entry level program for individuals with the goal to enable volunteers to become contributors to the platform. The motivation for most of the individuals in that program is to learn to develop for the Symbian platform and to get recognition. The bug squad has evolved over time to accomodate to those individuals need, through a process of listening and adapting the program.

What the examples show, is that there needs to be a good match between what your audience wants and what you want. And that you need to have a conversation with some people before you can be sure: the last two articles on this blog gave some hints as to how you may want to approach this.

Can you accomodate your audiences needs?

Fundamentally, you can only be successful if there is a good match between your and your audience’s needs. This is really important! Say your need is to get specific contributions to your product. But you have an audience which wants to contribute something else. If you cannot accomodate them, there will be frictions and problems.

There are two things you can do:

• Evolve what you want to achieve
• Be upfront and honest with your audience : in other words set expectations
  

There is nothing worse than raising wrong expectations and as a result wasting peoples time. An example, where I was in a situation where this happened was the Software Freedom Fighters project. We knew what we wanted (a version of the OS compiling with GCC 4.4.1), where there was an audience which wanted what we wanted. However there were a couple of problems:

• When the project started we assumed that the majority of our audience were motivated by kudos, when in reality the main driver was to get the changes into a real phone.
• The project was cross functional and relied on getting changes into other project’s codelines. When we started, we did not have up-front agreement to get the changes into their main codelines.

After building momentum quickly, it became apparent that there was a mismatch. We had set up a mechanism, where changes ended up in a development branch with no quick and agreed route to get the changes into the main codelines. As a result, feelings were hurt, conflict arose and some people were dissappointed and disengaged from the project. With considerable effort, we have been able to turn this round.  Understanding better what our audience wanted and ensuring that we could accomodate them upfront, would have avoided many problems. But in the end we were able to learn and adapt.

Getting noticed: standing out

As this post has become already somewhat long, I will cover how you advertise your project – in other words – how to get noticed and how to connect to your audience in the second part of this blog post.

When we launched the BugSquad we decided to start by ramping up by stages, ensuring we understood the challenges faced by contributors and we could address them with a short turn around. We assumed that our main communication channel to the technical community was our blog and that it would help us attract most of our contributor base.

image fom Flikr: Coz Baldwin

We announced the launch of the BugSquad via different channels at different times (weeks apart) , this allowed us to measure the success each communication (in terms of new joiners to our email list compare to clicks on the actual announcement). Here is my interpretation of the results:

Our Forums: Our forums are mainly read by technically minded people that are engaged on Symbian based projects and are able to contribute to platform initiatives. This has been by far the most efficient channel to communicate to code contributors ( for development and test).

Our Blog and Twitter accounts: By regularly posting in our blog, we have achieved good awareness of the Bugsquad with technical bloggers and internally at the Symbian Foundation. However, it is difficult to link to specific contributors joining the Bugsquad due to its usage. In a broad sense, the same applies to our Symbian twitter accounts.

Our Member Company News Letters: We targeted this channel when we wanted to increase the number of participants from member companies in the bugsquad. The result was a significant mount of interest that we had not manage to rally using the previous methods.

This knowledge has enabled us to ensure our message reaches the right audience. So, do you understand your communication channels? Do you know who is listening?