Submitted Content
By Michael Williams
It’s increasingly difficult to get developers interested in projects because so many technologies out there are jostling for their time. With all this competition, developers are able to be selective about which technologies they choose to learn and use to achieve their design goals.
The best way independent software makers can create open source traction is by building a community; a place where a variety of developers can meet to discuss the technology and how they’re using it, share their work, help each other solve problems, and access new developer-built add-ons.
If this is done effectively, the advantages are manifold. In addition to keeping developers engaged by helping them feel supported, a thriving online coding community’s feedback is invaluable for the team behind the open source project as a way to improve and enhance both its features and those of any commercial product based on it.
The community also supports the adoption of your commercial products. Since you’re sponsoring this open source community; as needs arise beyond what open source can fulfil, it’s easy to find where to go to get more. Also, developers talk to each other about what works for them, so what they say carries a lot of weight with fellow coders. Once they find the value in your technology—open source and commercial—they’ll likely spread the word.
Engaging developers in an open source project, however, requires getting everything right at the same time, and over time.
Initiating Great Activity
Here are the main things you have to get right.
The Rules of Engagement
The type of license you select for your open source project is key. Some are restrictive. Some are more liberal. A lot of knowledge is available on the Web to help you reach an informed decision about the one that works best for your target developers. Try, for example, choosealicense.com/licenses and blog.codinghorror.com/pick-a-license-any-license.
What’s in it for Me, the Developer?
Don’t expect coders to rush to your project simply because it is open source. Developers are motivated by pride, peer recognition, and technology. They are not interested in furthering the cause of the marketers, and certainly not any “product development plan” of a vendor. Unless they are inspired to explore the software themselves, they will go elsewhere. The application has to have a tangible value to what they are working on, and provide time- and cost-saving benefits to their development work.
Establish Gold-Level Trust
To build a long-term open source community, you have to establish trust, and that trust stems from transparency. Developers want to know who you are and what is involved in the project before they get involved. Open source users need to be clear on how their time will be used and of the outcomes. To create the right environment to nurture this, you must make transparent communication at all times a non-negotiable value.
Waving the Flag
Evangelism is a core part of firing up developers to grow a community. The first job of any community manager or evangelist is to support those developers who are using your software, especially in the beginning. Beyond that, what makes good community evangelists? They are people that passionately believe in a project and bang the drum, softly, through different mechanisms—from forums to meet ups to larger industry events. You’ll find many of these folks in your developer community as well; finding them and opening a line of communication with them can be invaluable for your community.
Get into It
The majority of developers like to get their hands dirty. They want to take stuff apart and see if it can do X or Y. Any pro-coding resource you can get in front of them—whether tutorials, examples, YouTube clips or APIs—is a good thing. Set up an infrastructure where your open source support team can get technical help and share experiences—such as forums and workshops. Be sure to nurture your early adopters and give them the support they need. They aren’t just the backbone of your community; they are the community you want to keep growing.
Getting Management on Board
You may well stumble if you do not have the backing of an internal executive sponsor that is is invested in and understands the value of an open source community. The community knows this. Most open source initiatives have some sort of a commercial entity either behind them that is backing the project, and ultimately it needs to make money in order to continue backing it. It’s a two-way street. If the executive team doesn’t see value in the open source code project, resources applied to it will dry up—and so will developer interest.
The best way to convince the business? By gently fostering community growth—and tracking that to map the correlation between the community and the number of developers utilizing the open source, freemium, and commercial versions of the software.
Who says Lady Gaga is the Only Game in Town?
You will have lots of interest at the beginning. But being the latest and greatest never lasts for long. You have enure sure that you remain relevant. You want to make the “15 minutes of fame” window open much wider.
A great way to avoid being last year’s news is to build out your network and start collaborating with other open source communities. Participate through Meetups—for instance, search “BIRT” at meetups.com—or make contact with community managers so that you can host shared events, do cross posting on each other’s forums, etc. That way you stay at the top of the relevance chart.
Another way to avoid losing developer attention is to roll out compelling use cases on the open source, freemium, and commercial technologies. Get them on blogs and into other social media outlets like Google+, which many developers follow; get your customers talking to the trade press and sharing experiences at industry conferences.
Don’t Touch That Dial
Long term, the industry moves on. The Internet of Things, for example, is hot right now, but for how long? You need to be sensitive to these shifts as developers stay attuned to these trends and whether or not they affect them; for instance, Big Data was buzzy long before it became meaningful to the work developers were actually doing. It is critical to continually reach out to the open source world and keep them updated on what is happening.
These are all the big picture ways of making your open source code project meaningful for developers. There are also ways to incentivize individuals, like with gamification—awarding badges/rewards, etc.—for innovations, add-ons, and plugins, to your basic open source code project. An advocacy club is another great approach: to incentivize your developers to contribute more to the project will ultimately make the community more dynamic.
Lean In
In sum, to keep an open source developer community thriving, you have to work at it. Just because you have launched a community doesn’t mean you can sit back—you need to continually engage your developers as individuals, and continually re-evaluate to make sure what you are offering is still valuable. If you support your developers, they will support you.
Remember, Rome wasn’t built in a day – but I’m sure you’ll agree it was worth all the time it took. SW
Michael Williams is BIRT product evangelist and forums manager at reporting and business analytics software specialist Actuate Corporation, which founded and evolves open source BIRT, a top level project of the Eclipse Foundation, and the basis of their commercial offerings: BIRT Designer Pro, BIRT iHub, and BIRT iHub F-Type. Follow Williams on Twitter @mwilliams_birt or visit his blog blogs.actuate.com/author/mwilliams
Sep2014, Software Magazine SWM3004
