Channels ▼
RSS

Database

Building and Maintaining an Open-Source Community: How to Get Developer Attention


There are many useful open-source technologies out there. With all of this competition, it's critical to make it clear why your particular open-source offering should be considered, and for which needs. That's the reality any builder of an open-source community needs to adopt right from the start: While participation by developers in an active, viable open-source community will undoubtedly improve their projects, as well as your product's evolution, getting a community up and running can be a challenge.

At Actuate, we've managed to establish value for developers in our open-source BIRT community, and in our commercial products built on BIRT. Today, our community is 3.5-million BIRT developers strong. So here are our thoughts on how to build your own.

What is the right way to start this process?

First, from a business model standpoint, the kind of license you select for your open-source project is a big factor. There are different types of open-source licenses — some are very permissive and some are very restrictive, and developers pay a lot of attention to this aspect now. There is also a lot of knowledge out there on what each license exposes you to. See, for example:

http://choosealicense.com/licenses/

http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses

http://blog.codinghorror.com/pick-a-license-any-license/

Second, simply because it is an open-source project doesn't mean that you can expect developers to simply flock to it. The project must provide clear value to a developer. This means being very explicit about your software's design, the APIs, the openness, and the applicability of your software as it relates to the developers' needs. Not only that, but you must also provide concise, easy-to-follow documentation on how to get started. If these paramount requirements aren't met, the grass on your competitor's side of the fence starts to look greener and greener and developers will move on.

The third element you need to get right is the structure and organization of your proposed open-source community. To build up the community, you need to establish trust. The trust aspect comes from transparency and clarity about what's offered free and what's not. Also, make sure everyone knows who is behind the project. This not only helps with the trust factor, but also ties you to the open-source product, letting developers know where they need to go when they want more (for example, your commercial product line). Clearly detailing the process for committers and how to participate is also a must. Also, signpost how the development, quality assurance, and the release process is working, clearly delineating the various milestones and the roadmap.

"Open source" generally means freely acquired software. Of course, that doesn't mean it's cost-free to the developer. The fact that they are engaging means that they are investing time — which, as we all know, equals money. So, they need to be able to find exactly what they need to know quickly and easily across all aspects of your toolset and your open-source project.

If you think about it, that is why open-source projects organizations such as the Apache Software Foundation and Eclipse have been so successful. Anyone who gets involved in these projects knows exactly how the structure works, what the governance process is, and (if they are going to spend any time participating in these projects at any level) how their time is going to be utilized.

Now it's started — build it out

Next, start thinking about how to get developers excited and involved. Having developers on board as your evangelists is a big element of that effort. A good open-source community evangelist is someone who understands how developers work, is passionate about the open-source toolset (not just the commercial product), believes in the project, and is constantly spreading the word through meetups, blogging, helping people on forums, presenting at tradeshows, and so on.

It perhaps goes without saying that, in order to support the evangelists and the growing number of community members, you need a great online resource. Your website must be able to explain to developers what this project can do for them, quickly, cleanly, and in the "language" of the developer. Because developers also like to get their hands dirty, make it easy to get the core code for them to play with in addition to the IDE and the APIs. Meanwhile, any learning resources you have — tutorials or examples — also need to be readily available.

A great example of success with this is Drupal. Part of the reason it has been one of the most successful open-source projects is that people have built so many online resources and code examples — so that as soon as anyone starts a Drupal build, they don't have to recreate the whole thing from scratch because the community contributes so much.

Once developers have started to use your open-source software, you should expect that community members will run into the same sort of issues that anyone runs into with software: bugs and undocumented features. When this happens, they will likely want some help. The best source will be the community itself — other developers. Over time, if your project is successful, more-experienced community members will be ready to answer questions for newcomers. However, to get there, you need to nurture the fledgling community with experienced internal people of your own. This is very important. The community help will come if you get it started. If you simply let it ride, without initial and continuing internal support, your community is likely to flop. Besides, you'll always want to have internal folks in the community surrounding your project, as that's how you learn how your project is being used, allowing you to be proactive in the direction you head.

Beware the "newer is better" syndrome

As long as your project is new, there is a fit in the market, and you've provided a clear explanation of the benefits, you will have lots of people interested in learning and talking about your technology. However, once the newness wears off, interest is likely to wane. In technology, as new things come along, naturally, interest will shift and everybody will start pursuing the next latest-and-greatest technologies. So how do you continue to stay relevant?

We've found that a great method to help a project avoid becoming yesterday's news is to collaborate with other open-source developer communities. For example, the Hadoop following (through Cloudera, Hortonworks, and others) is growing rapidly. Seek out participation in those communities — through meetups or working with their community managers — so you can have shared events, cross-postings, and some interesting use cases that you can share. You are effectively piggy-backing on their momentum; and why not? Chances are both groups can only benefit. Your project gets the continued exposure to new eyes, while theirs gains access to your established community. By the way, this doesn't just apply to new technology — any other relevant technologies that help expand your ecosystem are worth looking at.

In our case, we've been going to Java meetups, inviting partners to our meetups (Cloudera, for instance), and being invited to other meetups. We really encourage you to continue to keep expanding your community by reaching out to others. This is a social world — even for the entrenched developer.

The second option to prevent decline in engagement with developers is to present new compelling use cases with your technology. The evangelist team should be responsible for idea generation here, constantly looking at new spaces and technologies whether it is Raspberry Pi, data sensors, or new tools for data. For example, the Internet of Things (IoT) is a hot topic right now, so we've partnered with EuroTech and Eclipse to showcase the use of BIRT in an IoT context. These use cases can be blogged, presented, or posted on iClips and Google as videos.

Beyond evangelism: Advocates, gamification, and hackathons

Advocacy is another tool that should be in your arsenal. We have a select list of people invited to an advocacy club: The idea is to provide incentive for contributions with the goal of making the community more vibrant — whether it is doing a product review or writing a blog or giving feedback on the open-source project or the commercial product trials. Advocates, when you have really good ones, are just a single Tweet or a blog post away from getting your community major attention. These are developers who will speak of the value they find in the technology, which is very important and credible. Look for them — and look after them!

A flip-side to this is what we call gamification — finding fun ways to motivate developers to participate in your community. In our gamification efforts, we keep the interest alive through challenges and rewards; so if you answer a question or submit some code examples, you can earn digital badges that we publicize on a digital leader board. It really works, and developers get very competitive! We have sponsored hackathons as well. These are a great way to build support around your community.

The best way to look at all of this is contained in one word: experimentation. Nothing you can do today is guaranteed to work six months from now, so you just have to keep on working with the market and seeing what really motivates and speaks to developers.

The importance of support for the concept

Most open-source projects have some sort of a commercial entity either behind them or very closely affiliated with them. From the beginning, your executive sponsor needs to have very clear objectives as to how the community is going to affect its business. The community manager's job is to help the executive sponsor understand this plan, and its value, and — at the same time — ensure your community serves the needs of your developers.

One benefit, that you may not have thought about in any great detail, is how your now-successful open-source community can help act as a kind of free-form research and development lab. An actively engaged community provides on-going feedback that can help you and your developer team improve features and other aspects of your software.

At Actuate, a participating developer wrote a MongoDB extension before we'd even seen the need for one. That's a key aspect of a healthy open-source community — it can help you understand user requirements and drive the product in the direction the market needs.

Finally, an active open-source community enables the adoption of your products. You have people talking about the work, showing examples of success, providing peer-to-peer support, all of which allows new developers to come on-board and be up and running successfully and quickly.

It's worked for us with BIRT — and there's no reason it can't work for you. Good luck!

Four Ways to Make Your Open-Source Community Fly

1: Be very clear in your instructions within your forum responses. Developers are often spread thin across many projects or rarely focus on a single technology; so don't assume they know the basics of your technology. Your software isn't necessarily the biggest thing in their world.

2: Respond quickly to their questions, like with needing clear instructions to get started with your toolset. A lack of response is a brick wall in their application development process and can force them to move on to a new technology even if it's not until the next application. Also, developers talk to other developers, and you want them saying positive things about their experiences with you.

3: Don't push marketing lingo and commercial products on them. They'll move to the next project in the blink of an eye. Developers are self-serve consumers. They'll come to you when they need your technology.

4: Developers like to feel like recognized for their craft. Reward them with prizes, thanks, and recognition on the site. Make developers feel important to your community — and they'll keep coming back.


Michael Williams is a committer on the BIRT Project, and he is also BIRT Product Evangelist & Forums Manager at reporting and business analytics software specialist Actuate Corporation, which sponsors open-source BIRT and offers commercial BIRT-based software to a community of more than 3.5 million BIRT developers around the world. Michael is on Twitter as @mwilliams_birt.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video