Open Source is kinda like a Kardashian.
I can only imagine the life of Kim Kardashian and her cohort of Instagram-royalty brethren … a life where everyone is watching what they do … where everywhere smells like fresh paint … and where small decisions net significant interest. Sadly, I don’t have the hair to be a Kardashian.
Open Source has a similar problem to Kim. Open Source has become such a widely recognized way of building software that now the world is watching. Open Source now powers data centers, mobile devices, electrical grids, kid’s toys, and more.
The logical conclusion therefore is that this explosion of growth in Open Source means that the mechanics of building a successful Open Source project are clear and well understood.
Unfortunately, Open Source is a complicated web of technology, community, economics, digital rights, and more.
So where do we start? Well, based on my 23 years of experience in community, I recommend you start with these five critical principles for building the best Open Source communities.
1. Differentiate your community audiences
One of the biggest mistakes Open Source projects make is that they conflate different audiences.
I broadly break technical developer communities into two types:
Inner Developer Communities: developers who want to contribute to Open Source projects. Here you need to build an environment where everyone is on a level playing field and can contribute code to a shared Open Source project.
Outer Developer Communities: developers who want to build a plugin, extension, or integration for an Open Source (or non-Open Source) project. These developers generally don’t care about how the core project is built, they just want a killer SDK, documentation, and community support. They want to ship their plugin/extension/integration quickly and easily.
It is essential to NOT conflate these audiences … yet many projects do. So, think about which of these two audiences is most critical to you and your project.
For most companies building Open Source, their priority is Outer Developers as that is where the broadest impact can be felt in the market.
This is for good reason. As a general rule, Inner Developer Communities are complex beasts to set up and maintain and they require a delicate balance of technical and social integration.
However, Outer Developer Communities are much easier. You primarily focus on delivering an amazing developer flow with integrated SDKs/libraries, great docs, and more.
Start with either Inner or Outer and then build out from there.
2. Take the misery out of code contributions
Let’s now take a moment to zone in on Inner Developer Communities. Want to know another key mistake that many Open Source projects make?
They fail to do EVERYTHING THEY CAN to reduce the friction for developers to contribute their very first code contribution to their project.
I see this all the time: poor documentation, badly commented code, long and bureaucratic code review, and grumpy, snarky maintainers who require perfection in every pull request...
Ugh.
The first time someone contributes to your project is an opportunity for an amazing first impression.
It is an opportunity to make their experience simple and elegant to follow, to shower them with kindness and encouragement, and to give them a genuine reason to be proud when that first pull request gets merged in.
The way in which you build this rock-solid first experience is to do the following:
- Put your brain into Incognito Mode and forget everything that you know about your project.
- Pick a simple task to work on and start creating a pull request to submit. Don’t assume anything. Question everything.
- At every step of the process ask yourself, “Is this part intuitive?” For example, if you need to know what a method does in a source file, is it easy to figure that out? For everything that is non-intuitive, note it down.
- When you have completed and merged in your pull request, prioritize all the things you noted down, and start fixing them.
- Now watch a new community member go through the same process and ask them for their feedback (and ask them to be blunt). Take notes where it was unintuitive for them and go fix them.
This will dramatically improve your new developer onboarding experience.
3. Build code that people actually want
A lot of Open Source projects operate like heavy metal bands.
So, I have a heavy metal band called Baron Carta where I write all the music and I write whatever I want.
If I think something sounds cool, I write it. I don’t care what anyone else thinks … I use my own musical tastes as the test strip for what fans of Baron Carta will like too.
We don’t have that luxury in Open Source.
If you only scratch your own itches, you will only make software that you love. We need to flip the bit and truly understand what our audience wants, especially the non-vocal ones.
Funnily enough, the solution to this problem is a very powerful way to engage with your community: to survey them.
I recommend you survey your users regularly and follow Rahul Vohra’s excellent Product Market Fit Engine. It will not only ensure your Open Source software is always evolving, but your users will love to be included in the process.
4. Resist governance until absolutely necessary
There is a misnomer in many tech circles that to be a “real” or “professional” Open Source project, you need to have a comprehensive governance function in place.
This kind of governance usually manifests in Technical Steering Committees replete with weighty charters, board elections, complicated online meetings, and a hefty amount of inside baseball muttered from the cheap seats.
Here’s the secret though: this is only necessary for a tiny fraction of Open Source projects.
You see, the most wonderful time in the lifecycle of an Open Source project is the first six months.
In that magical period of time, the only focus is on cutting code, building relationships, and keeping things simple and productive. It is like an artist working on their easel with no distractions.
You want to stretch out this ideal time as long as conceivably possible.
Eventually though, and as more people join, you reach the limits of organic 1-on-1 engagement with your contributors.
Governance is usually only necessary when a very large number of people, companies, and sources of investment want to influence a project, especially when it includes multiple competing companies.
Oh, and a bonus tip: don’t set up your own foundation … it is a nightmare. Host your project in another general purpose Open Source foundation where they already have all the infrastructure and management up and running. Trust me, you will thank me.
5. Create a real culture for real people
When I think back over the most memorable and impactful Open Source projects I have seen and been a part of … they had remarkably dynamic, welcoming, and fun cultures.
So much of the Enterprise world is stuffy and boring—packed with crowded Powerpoint decks, overused buzzwords, and a competition to be the smartest in the room.
It doesn’t have to be this way.
Your developers, your users, and the people watching the game unfold—they are all people with diverse backgrounds, interests, and perspectives. You should encourage them to let their flags fly.
Focus your community not just on building great code: creating an Open Source community means creating an environment where the personalities of your members bubble to the surface.
This is essential. One of the biggest challenges communities face is that cultural and workflow norms set in, and then an “old guard” forms that never wants to change. This can be a death-knell for a community.
Instead, create a culture where your community is encouraged to kill their darlings. A culture where creativity, new ideas, and new forms of working are encouraged.
When you create a culture where people feel creatively fulfilled, you create an environment where innovation flows naturally … and these are by far the most impactful and enjoyable Open Source projects.
In summary
Hopefully this blog post has provided some good ideas for starting your Open Source community, which in turn will help make your open source project a success. Good luck, and my door is always open. Drop me a note if I can help with anything.
Jono Bacon is a leading community strategy and execution consultant, author of People Powered, and creator of the Community Experience Masterclass and the Community Ignition Workshop.
For more tips, connect with 1000+ community and DevRel leaders in the Uncommon community. If you’re interested in a solution to help activate the power of your community, check out Common Room. You can get started for free or request a demo to see the platform in action.
