Distilling market noise into market sense

VisionMobile is the leading research company in the app economy and mobile business models. Our research and workshops help clients compete and win in their rapidly changing industries.

Open Source community building: a guide to getting it right

[Everyone - from carriers to OEMs - is busy building developer communities. But many have failed and more have seen disappointing results. Guest author Dave Neary looks at what lessons history can teach us on community building and the key DO's and DON'Ts.]

Open Source community building: a guide to getting it right

Community development in open source software is not just for geeks in sandals nor for niche Linux companies any more. It’s mainstream and it’s here to stay.

The recent analysis of companies contributing code to the Linux kernel shows that large companies including Novell, IBM, Intel, Nokia and Texas Instruments are getting serious about engaging in community development. Organisations such as the LiMo Foundation are encouraging their members to work with community projects “upstream”, that is, with the community rather than in isolation,  to avoid missing out on millions of dollars worth of “unleveraged potential” (PDF link).

A diverse developer community is critically important to the long term viability of free and open source projects. And yet companies often have difficulty growing communities around their projects, or have trouble influencing the direction of the maintainers of community projects like the Linux kernel or GNOME. Sun Microsystems and AOL are prominent examples of companies which went full speed into community development, but were challenged (to say the least) in cultivating a mutually beneficial relationship with community developers. There are many more examples – but often we never even hear about companies who tentatively engage in community development, and retreat with their tail between their legs, writing off substantial investments in community development. Xara, for example, released part of their flagship software Xara Xtreme for Linux as open source in 2005, before silently dropping all investment in the community project in late 2006.

What can go wrong? What are the most common, and the most deadly errors which companies make in their community engagement strategies? And how can you avoid them? Avoiding these does not guarantee success, but failing to avoid them may be sufficient to guarantee failure.

Where to begin?
The easiest and gravest error that companies make is to sprint headlong into free/open source development with unrealistic expectations.

The history of free & open source software development is filled with stories of companies who are disappointed with their first experiences in community development. The technical director who does not understand why community projects do not accept features his team has spent months developing, or the management team that expects substantial contributions from outside the company to arrive overnight when they release software they’ve developed. Chris Grams once described the Tom Sawyer model of community engagement – companies who expect other people to do their job for them. Make sure you don’t fall into that trap.

Doing community software development well takes time, even when you get everything right. And there are a lot of things you can get wrong.

So where to begin? Before you start community development, you should have thought about what you want to get out of it. Is Open Source a way to grow the brand and broaden distribution of your product, with the goal of generating leads? Do you need to grow an ecosystem of developers building on top of your platform? Do you want to include an existing project into your product to reduce costs, but customise it to fit your needs? Each of these goals, and any of the other reasons people develop software in the open, require specific strategies and tools tailored to the situation to succeed. Indeed, how you measure success will change depending on your goals.

The two common situations company find themselves in are collaborating with an existing open source community, or growing a community around a piece of software that you are releasing.

Joining a community
When joining an existing community, building trust and reputation takes time. The first step to working productively with a community is to understand the structure of that community. Who are its leaders, what are its priorities? If the culture of a project does not align with your business objectives, that may affect your decision to engage with it in the first place.

If you find that you can work with the project, and that the general goals are aligned (or at least, not misaligned) with yours, then the hard work can start. For example, Hewlett-Packard backed Linux early, at the expense of promoting its own proprietary Unix, HPUX. Ten years on, HP now ships close to 40% of all Linux servers. In contrast, Sun Microsystems decided to create an independent community around Solaris in 2005, releasing OpenSolaris under an Open Source approved licence which is incompatible with the GPL (the licence of the Linux kernel). The Sun sponsored project failed to create a substantial independent developer community from its launch until the acquisition of Sun by Oracle and subsequent closing of the OpenSolaris project in 2010.

Once you make the decision to collaborate, and you have chosen the project you want to work with, the first and most important decision is who will work on the project. This consideration often does not get the attention it requires from top management. The engineers who will be working on the project on your behalf will be representing your company. It will be their job to build trust with project maintainers, navigate the project’s roadmap process to ensure that their work is accepted upstream, and ensure your business objectives are met.

The choice of the people who will work with the community is particularly important; as Stormy Peters, former Executive Director of the GNOME Foundation, once wrote, companies are not people. In other words, companies can never be members of a software development community, although their employees may. Companies can be valuable institutional partners for projects, but to quote the Beatles and Karl Fogel, money can’t buy you love (or community support).

So now you have some engineers working with the community. What next? Havoc Pennington wrote some excellent advice in 1999 for engineers working with community projects. The one-line summary might be: “when in Rome, do as the Romans do”.

Often communities will have documented their norms – many projects, including the Linux kernel and modules in the GNOME project, have “HACKING” files under source control documenting expectations for contributions, and mailing list policies. For most communities, these can be summarised as “go with the flow, don’t rock the boat”. Miguel de Icaza, founder of the GNOME project and vice president of developer platforms at Novell, has written an article explaining the reasoning behind these policies.

One temptation which you should avoid at all costs is to leverage the trust which one contributor has gained to channel contributions from others into the project. This will only promote Shy Developer Syndrome in your team.

By all means, have your senior community guy mentor others in the team and help them through the process, but avoid making that mentor a gatekeeper, shielding the rest of your team from the community. Attempting this will always backfire when your gatekeeper moves on or when the community finds out that he’s committing the work of others and circumventing community norms.

Growing a community
Looking at the second scenario; growing a community. If you do decide to release software under a free software OSI approved licence, your first choice will be whether to set the project up as a community project or not, and to what level.

Simon Phipps has written about the different types of communities which can grow around a free software project. He describes communities of core codevelopers, non-core developers who work on add-ons, integrators who distribute and configure the software, but don’t necessarily modify it, and finally users of the software. Each of these communities have different needs, and require different approaches.

If you want to grow a community around your project, there are a few best practices you should follow:

- Control: If you opt for rules ensuring that you decide what code will be added to your product’s core, you will lose many of the benefits of community projects. Some examples of rules which come from a desire to maintain control are a requirement to assign copyright for all contributions to the core product to you, or ensuring that only employees can commit directly to the main branch of your core product. There are many good reasons to maintain ownership of the core, but this decision will severely handicap community contributions. This does not prevent you from developing other types of community, however, such as a community of add-on developers or integrators.

- Barriers to entry: Barriers that contributors have to overcome can come in different shapes: using unusual tools, requiring convoluted processes for bug reporting, feature requests  or patch acceptation, or legal forms you may ask people to sign before contributing.

- Tools and infrastructure: Ensure that you provide your users with the opportunity to distribute their work and connect with other users – whether this be through a forge for modules, or through the use of Gitorious of Bazaar for source control. Contributing in your project should be seen as a social experience.

- Community processes: Create a just environment – no-one likes to be considered a second class citizen. Document processes for gaining access to key resources like bug moderator permissions, commit access to the master branch, or editor access for the project website.

- Budget appropriately: Commit the appropriate resources – building a community takes time and effort, and that means investment – primarily of human resources.
Having one guy who is the community manager dealing with the community and a team of 10 developers behind the corporate walls isn’t going to cut it. As Josh Berkus of PostgreSQL said in his “How to Kill your community” presentation, if your nascent community feels neglected, it will just go away.

Launching a new project is like launching a new product – except that acquiring a new community developer takes much longer, and is much more difficult and costly than acquiring a new user. In the same way that companies track SAC for new product launches, tracking the Developer Acquisition Cost (DAC) for your project is a key metric in evaluating whether you are doing the right things to grow your community.

Developers have lots of projects to choose from, and they tend to gravitate towards projects where co-development is the norm. So you have to be thinking about the contributor experience, and the value proposition to external contributors, all the time.

A clear and compelling vision, with lots of opportunities to contribute, and low barriers to collaboration, can help reduce the acquisition cost of community contributors, and similarly reduce the cost of acquiring new users and paying customers.

Avoid common anti-patterns
If Best Practices are behaviours that should be adopted, community anti-patterns are best practices gone wrong. If the reasons behind a “best practice” are misunderstood, you can end up imitating behaviour without getting the desired result, much like the Pacific cargo cults, building airstrips and hoping that planes land. Like seasoning, adding too much can ruin the dish.

In general: when you see the following patterns happening, you should work to counter-act them, both in the communities you participate in, and in your corporate citizen behaviour within those projects. Each of these patterns are common and tempting, because they represent best practices applied in inappropriate circumstances. And each of them results in a net reduction of community health.

Some common anti-patterns you should avoid are:

1. Command & Control – communities are partnerships. Companies are used to controlling the products they work on. Attempting to transfer this control to a project when you want to grow a developer community will result in a lukewarm response from people who don’t want to be second class citizens. Similarly, engaging with a community project where you will have no control over decisions is challenging. Exchange control for influence.

2. Water cooler – when your team gets too much work done in private, your community will not understand your motives and priorities. By working on mailing lists or other publicly readable and archived forums, you allow people outside your company to get up to speed on how you work.

3. Bikeshed – A “bikeshed” discussion is a very long discussion to make a relatively minor decision. When you feel like the community is dragging you down, know when to move from talking to doing.

4. Black hole – It can be tempting to hire developers who have already gained reputation and skills in projects you build on. Beware when hiring developers from the community – it may be that the community will be worse off. Ensure that working in the community is part of the job description.

5. Cookie licker – Picture a child who has had enough cookies, but wants to save the last one for later. So they take it off the plate and lick it, to ensure no-one else will eat it. The same phenomenon exists for community projects – prominent community members reserve key features on the roadmap for themselves, potentially depriving others of good opportunities to contribute. Beware of over-committing, and leave space for community contributions in project roadmaps. Be clear on what you will and will not do.

Happy Community Gardening
Community software development can be a powerful accelerator of adoption and development for your products, and can be a hugely rewarding experience. Working with existing community projects can save you time and money, allowing you to get to market faster, with a better product, than is otherwise possible. The old dilemma of “build or buy” has definitively changed, to “build, buy or share”.

Whether you’re developing for Android, MeeGo , Linaro or Qt, understanding community development is important. After embracing open development practices, investing resources wisely, and growing your reputation over time, you can cultivate healthy give-and-take relationships, where everyone ends up a winner. The key to success is considering communities as partners in your product development.

By avoiding the common pitfalls, and making the appropriate investment of time and effort, you will reap the rewards. Like the gardener tending his plants, with the right raw materials, tools and resources, a thousand flowers will bloom.

- Dave

[Dave Neary is the docmaster at maemo.org and a long-standing member of the GNOME Foundation. He has worked in the IT industry for more than 10 years, leading software projects and organising open source communities. He's passionate about technology and free software in particular.]

  • http://www.opensourcestrategies.com/ Open Source Strategi

    I really like your article — it is very thorough and well-thought out, but I must respectfully disagree with you on a fundamental point:

    The true measure of the community around any technology is not how many contribute directly to its development, but how many people build on top of it.

    This was true all along, even when communities of hackers were developing on the Apple ][, and it's especially true now in the age of cloud computing with open API's. Think about the iPhone, facebook, or salesforce — they're not open source, don't allow contributors, but can anyone really say they don't have community?

    I think it's time open source developers recognize this and adapt to it. Otherwise, an antiquated notion of communities will lead us to develop software in antiquated fashion and become increasingly irrelevant.

  • http://www.neary-consulting.com Dave Neary

    Thanks for the feedback!

    I did point out that there are different types of communities, and that it's possible to grow communities of application developers or users or integrators without a community of core application codevelopers.

    That said, I do think that a diverse core developer base is really important for open source projects, and participating in a community which already has a diverse core developer base is one of the key challenges many companies face.

    Thanks again!

    Dave.

  • Mark McLoughlin

    Very nice, thoughtful article Dave.

    I liked the way you avoided dwelling too much on the anti-patterns. It's so much easier to explain the anti-patterns than the best practices, but it can end up feeling very negative.

    One thing worth discussing might be the role that Product Management types can have in a project. How the skills traditionally used to collate product requirements, prioritise those requirements and maintain a high-level view of the direction of the product can be applied to building consensus around community goals and helping developers make design trade-offs. It's really only a subtle shift, but a big challenge because of the attitude shift and commitment to building trust and respect required.

    Just a random thought.

    Cheers,
    Mark.

  • http://www.neary-consulting.com Dave Neary

    Thanks Mark.

    Indeed, the role of release managers in community projects is underestimated, and this is somewhere where companies generally do things better. Just having someone to document agreed goals, and track outstanding tasks associated with those goals leads to much clearer communication between community members, as well as with people outside the core developers. It also makes it easy to know when to release, which is a great added bonus.

    Dave.

  • Anon

    "Gitorious of Bazaar"? Did you mean "Git or Bazaar"?

  • http://www.neary-consulting.com Dave Neary

    @Anon: Thanks for catching that – I may have intended "gitorious or bazaar", "git or bazaar" is better.

  • Weibin Yao

    Hi Dave, I have translated your excellent article to Simplified Chinese. Thanks for your hard work. The url is here: http://yaoweibin2008.blog.163.com/blog/static/110

  • http://kevin.kevin-media.com Kevin MORGAN

    Thank you for your hard work, Dave.

  • http://keimform.de/ StefanMz

    Hi, I paraphrazed your Community Anti-Pattern talk in German here: http://www.keimform.de/2011/community-anti-patter

  • http://www.dataroket.com James Fox

    This is a great article. DataRoket is a data integration engine and data repository. We are going to open source the connectors and data visualization pieces AND offer a free version of the engine as well. Frankly with that then few would need to buy the enterprise version.

    We have been trying to make up a strategy on how to do this best and this article helped a lot!

    Thanks!

    James Fox

    jfox@dataroket.com

  • opensourcejedi

    Thanks for the great article. I ran across this blog this morning and I think it might have something to do with why some of those project didn't work. would like to hear your honest feedback. Thanks
    http://quist.co/post/5004683561/why-engineers-dis

  • http://twitter.com/grindMark @grindMark

    Fantastic post. I'm a member of a SaaS developers think tank, not exactly open source but I see a lot of value in the guidelines you laid out here. I've emailed links to the rest of the crew to get their feedback as well.

  • http://www.freezer-reviews.com Belo

    I see the dilemma of Command & Control – just how much latitude do you pass on to the community and how much control does the company retain. It will of course vary from project to project but any baseline rules?

    • http://www.neary-consulting.com Dave Neary

      Hi!

      The basic rule I tell people is that no-one can make you do something that you don't want to do. Don't feel obliged to assign resources to something just because someone from a mailing list wants it, if it's not in your interests. But likewise, try not to set the agenda for the project so strictly that others who are not 100% aligned have no opportunity to contribute.

      Let me give an example: Let's say you're building an application which encrypts testimony of human rights abuses (http://www.martus.org). Obviously security is vital for you. Now let's say someone wants to have a password recovery feature, so that if someone loses their key or password they will still be able to get at all the records they have stored in the application. That feature goes against the basic reason for having the software – if someone else recovers your password, they could expose people who have testified to you, and put their lives in danger. So to this feature request you could politely and firmly say "no, this will not happen". Now let's say that a journalist wants to use the program to record interview notes, and also wants to protect his sources. He would like to add a feature which is useful for journalists, but not for human rights workers. In that case, the feature might get added to the roadmap, but you can say "If someone does this, that's great, but I don't have any resources for it, so it's not going to be me".

      In short, give others the opportunity to act, even when it's not directly in your best interests, as long as it's not in conflict with your best interests.

      Dave.

  • Chad

    Thanks for the list of guidelines on building an opensource community!

    Thanks Dave!

    Chad
    Indianapolis Website Design

  • Tommy

    I'm a member of a SaaS developers think tank, not exactly open source but I see a lot of value in the guidelines you laid out here. I've emailed links to the rest of the crew to get their feedback as well.

VISIONMOBILE BLOG

Distilling market noise into market sense

The 3 key Apple Watch features that nobody talks about. Yet.

apple-watch-09

If Apple wants to create a new, large product category out of smart watches, it must empower developers to discover…

Continue reading ...

Uber API launch validates the “Gurley scenario”

Uber API

[With the release of Uber’s API, their ploy to achieve world domination has just gotten a lot more probable. Uber…

Continue reading ...

Will developers stop playing the app lottery?

illu

[How long will developers be loyal to ecosystems that seemingly set them up for failure? The odds are clearly stacked…

Continue reading ...

VISIONMOBILE STRATEGY

Workshops & research on Developer-centric Business Models

Apps for connected cars? Your mileage may vary

Automotive-report_illustration_web

Car makers are now entering unfamiliar territory as some of their latest product innovations have nothing to do with driving.…

Continue reading ...

M2M Ecosystem Recipe

M2M-Ecosystem

M2M is rapidly approaching a tipping point. Lower technological barriers pave the way for new entrants in the market. As…

Continue reading ...

Mobile Innovation Economics

profit recipe

Mobile Innovation Economics is a strategy workshop focused on business models and asymmetric competition of mobile ecosystems. Mobile ecosystems are…

Continue reading ...

VISIONMOBILE RESEARCH

Research on the app economy and developer ecosystems

App Profits and Costs

AppProfits

This research report examines the critical success factors for a profitable app, and how business and technology choices, such as…

Continue reading ...

Developer Segmentation 2013

Developer Segmentation 2013

The Developer Segmentation 2013 report delivers a needs-based segmentation model that actually works, with extensive profiling of the eight principle…

Continue reading ...

App Economy Forecasts 2013-2016

App Economy Forecasts

This report investigates the relative sizes of the app economy: developer population by region and platform, distribution of revenues, revenue…

Continue reading ...