At OSCON and the Community Leadership Summit the question how you get noticed as an open source project (or more generally as a a community) was covered in a number of discussions and talks. A really good talk was Josh Marinacci’s talk on Marketing Your Open Source Project on a Shoestring Budget: I will follow the overall structure of Josh’s talk, provide an angle specific to Symbian packages and incubation projects and augment with my own learnings.
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.