Open source community can be a tricky business, but today I want to share a quick example of the kind of open source community engagement I try to encourage more generally, and with clients. This one comes from a client of mine, Zeppelin, who builds tools for decentralized systems and smart contracts.
They launched their community earlier this year and have been seeing some fabulous growth. One component they have built is called Ethernaut which is a wargame for learning smart contracts.
Well, a few days back this post appeared in their community:
@martriay works for the company and is my primary point of contact for leading their community development. Clearly the company is busy with other projects but wants Ethernaut to keep moving forward, and the community expressed an interest in helping.
When @martriay asked if people would be interested, a number of hands went up:
Given the community interest, he followed through on his promise and kicked off a new topic:
Here he tagged the individual people who had expressed interest (so it appears in their forum notifications), and provided some pragmatic next steps for ways in which the community can play a practical role.
Importantly, @martriay also made it clear that the community are welcome to come up with their own creative ideas for how to participate (instead of forcing them into a specific box of tasks). This is critical: communities thrive when they are a creative meeting of minds, but with a clear method for how people practically work together.
What followed was a discussion for different ideas for tasks and where people would like to participate:
Here @martriay continued to be responsive, playing a supporting role to help those interested community members get started (such as opening up and adding to the project’s board in GitHub.)
This is another subtle, but important point: here @martriay is working to encourage participation but to try to consolidate these contributions into the same “view”, and provide an opportunity for some community members (namely, @scammi and @paulinablaszk) to play a key role as contributors:
As things stand right now, a clear list of work assignments is forming, all based on this creative discussion and input:
Part of why I think this is a good example is that it demonstrates (a) what is possible when a company is open to contributions, (b) how the community can play a key role in adding additional value to a shared project, (c) the importance of facilitation, and (d) how this energy can be consolidated into a central way of working.
If we peel away the covers, there are 5 key principles operating here.
#1. Be Open to Contributions
When companies are building open source projects, there is typically a line drawn in the sand between where the community can contribute and influence a project and where they can’t. Some companies will be reluctant for contributions, even for projects that are unmaintained, often due to various fears (liability, trademark issues, losing control, etc.)
Ethernaut is a great candidate for community contribution: the company has other pressing priorities, and the community loves Ethernaut. Being open to contributions demonstrates (a) the maturity of the company, and (b) that the community is a valuable relationship to the company.
#2. Foster Creativity
Community members don’t want to be walled into a box. They don’t want to be given a limited set of tasks. They are not task-rabbits.
Community members want to use their creativity to explore ways to make a project better. They want to express ideas, and have an open dialog about which of those ideas have legs and which don’t.
The very best open source projects have an open, creative environment, but a clear method in which work gets done, reviewed, and integrated. As you try to build a simple, clear workflow, don’t gut this creative input.
#3. Openly Facilitate Contributor Success
Few open source communities with a primary single commercial sponsor operate entirely autonomously. You will always need someone from the company to help facilitate the overall success of your community contributors.
Doing this well requires open engagement in the community, helping to foster their creativity, and working to zone in on specific tasks that are assigned to specific individuals. If you don’t have this you will likely get a lot of, “Wouldn’t it be cool if…” ideas, but no pragmatic results.
#4. Simplify and Centralize Team Workflow
While you want to foster creativity, the way in which the team works should be as clear, simple, and as accessible as possible.
For many projects, they have an online repo (e.g. GitHub), an online issue tracker, and code contributions are made via pull requests. They will also have a central place where the project is discussed, such as a forum.
Design this workflow and keep it as simple as possible. To do this, build a clear onramp, and I always recommend a healthy dose of “muntzing.”
#5. Be Accessible and Engaging
Finally, the tone and way in which you engage with your contributors is enormously important. Your community members are not robots, and don’t want to be treated like robots.
They are human beings, so be human with them: be loose, engaging, and fun. Validate great contributions, provide friendly constructive criticism, make jokes, and smile both in-person and online. It sounds simple, but this is critical: build an environment people want to be a part of.
This is really important for two reasons:
- People like working in more social, fun, and engaging environments.
- Human beings mimic each other and especially their leaders. As such, if you are fun and engaging, they are likely to be so too.
So, that’s it. I just wanted to share this little example, primarily so it can illustrate what I mean when I talk about what good, collaborative, open source engagement looks like. If you have other examples, be sure to share them!
