4 lessons in building a successful open-source community in 2016
It’s not just the role of the community that is changing in software, says Guillaume Laforge, but the way in which open-source communities are grown. The Groovy pioneer shares his advice on how to manage a positive developer community.
Recently I wrote about some community lessons following the double in Groovy downloads after it joined the Apache Foundation. I tried to talk about some of the lessons we’ve learned while working to build and support the Restlet developer community in the past six months.
It’s not an easy thing to build a community that is vibrant and growing and helpful to members. Change is a constant. Open source is now common and widely accepted. The very best talent commonly works on open source projects. The youngest engineers are comfortable being part of worldwide communities.
The tools for communicating have changed so much that building a successful open source community now, as opposed to maybe even just 5 years ago, has changed significantly.
What are the most important lessons in building a successful open source community in 2016?
1. Add your personality to the community
I add my personality to the communities I join. We all do, and we’re all different. This is great and gives each community a unique and interesting vibe.
Certainly there are different ways to organize and motivate a group of people. Linus Torvalds is known for being very direct, and, at times, quick and harsh with his criticism of community contributions. He has a communication style that works well for him. Linux growth is an incredible success story, so clearly there is room for different styles. Personally, this is not the style I recommend and endorse for most community leaders. Linus and Linux are special in many ways. It would be tricky for most people to emulate his style.
My own philosophy is to be nice. The best way to insure future growth is to be welcoming and open. I think the personality of the people is a key feature of a community. The best communities are international and inter-generational. On top of that, most developers participating are not getting paid. Why act like a boss? I try to be nice in all my communications with community members, new and old, and I believe if you are nice, others will be nice back to you. Furthermore, once adopted by the new community, they will in turn be nice and friendly towards newcomers. It’s a positive feedback loop.
As I often say, you gather the community you deserve: if you’re not friendly, welcoming, and helpful, your community won’t be either, and could attract bad behaving members. Be nice!
2. Use communication tools that developers want to use
One of the things that a community needs is a solid method of communication. It would be possible to force all communications through a central bug-tracking system or maybe a support email address. This might be appealing to the organizers.
In the past, the most popular tools were mailing lists, forums and IRC. Today, you’ll run into young engineers accustomed to communicating in ways that you haven’t heard of. Instead of mandating the correct mode, I believe multiple options allow for better communications.
For Apache Groovy, we stick to mailing lists. Emails are archived, so it lets developers answer asynchronously as they see fit, no matter which timezone they are in. In addition to that, we also communicate through JIRA for tickets opened by our users, as well as via Github comments when pull requests are submitted. We’re even looking at launching a Slack channel.
In my first six months at Restlet, I moved the Restlet Framework discussions to a new Google Groups mailing list. I also started to write a free weekly newsletter about the API industry. We rely on Github for our issue tracker, and for discussions around pull request contributions. Lots of questions are also coming on Stack Overflow, and in the past couple of months, we’ve updated our procedures to be very proactive to reply as rapidly as possible.
Different community members digest information different ways. See what’s appropriate for your community.
But one final note: be careful not to have too many channels open at the same time. You will be diluting the quality of support and the help you provide to your community if your team is spread too thin across too many channels. If you open up a new channel, be sure to have the available bandwidth to support it.
3. Broaden community appeal by accepting all developers
Whether you believe it or not, your community will have connections to different levels of development. You may think your project is a front end UI widget, but its connections to the back end will matter. Its use on mobile will matter. In some cases, this may be more apparent to the community than to you.
One very clear example of this was how I used to think of Apache Groovy as a back end language. Only after it started to be used more widely on mobile devices did I realize that it could be much more. This was not my image of the strengths of the language. The community found interesting uses for the language on mobile devices and are continuing to expand its use cases. I find this remarkable, and a sign that the community is engaged and energetic. It’s exciting to see Apache Groovy move in directions I did not anticipate.
In a similar way, API development and design were primarily done by back end developers. After working with the Restlet community, I realize that more people care about API development, including some of the people focused on mobile development. It’s important to keep an eye out for this.
4. Work with other open source communities – connect people, ideas, and technology
You might think your technology is geared towards a particular audience, or for a particular use case. But sometimes, you will be surprised to see in which directions the members of your community are bringing the project forward! Apache Groovy is used in different contexts, for advanced business rules, for scripting and task automation, as a test and build language. Over the years, a full ecosystem grew around the programming language, building new frameworks and libraries leveraging the language. One area we had not necessarily envisioned at the beginning of the project was the importance mobile would have: we’ve had a lot of interest for Groovy on Android devices, and that’s why we’ve developed support for Groovy on Android.
Another example: The Restlet community is active with the Linux Foundation’s Open API Initiative (OAI) and works with SmartBear and founding members 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal to define an open API definition language. Restlet also works with other open source and open specification groups around API Blueprint, RAML, WADL and many other projects.
By cooperating with other communities, even some that are competitors, we make the entire ecosystem stronger and bring more benefits to our own community.
Hopefully, you can apply these guidelines to help your favorite open source community in 2016. If you have any questions, feel free to drop me a line at Restlet at any time. Remember, communities require structure, but not too much. If you listen, they’ll tell you a lot.