The Basic Structures of Open Source Communities
An open source project and open source based company is nothing without a strong community. This post explores structural models and failure modes that can come up in building your community.
An open source project (or an open source based company) is nothing without a strong community. The community drives its adoption and builds the future market for your company.
Community and “community led growth” is a hot topic these days. Many companies have realized how critical having a strong community is for a healthy product and ecosystem.
Figma followed and defined a community led growth model all the way from stealth to enterprise.
As Claire Butler will tell you, community was core to the company’s GTM strategy early on — even while still in stealth. As Senior Director of Marketing, Butler joined Figma as one of the first ten employees and the company’s first business hire. She began shaping the company’s bottoms-up growth strategy and laying the track for a vibrant community before the product was even publicly available.
However, many don’t know how to go about building a community. As mentioned in the article on Figma’s community led growth (please read it, it’s fantastic).
When it comes to building community, folks tend to treat it as an afterthought, such as an online user group or a few in-person events to tack on later, after they’ve found product/market fit and built up a strong user base.
I recently read a paper discussing the communication patterns and structure of open source projects. The article has some relevant takeaways for those building open source projects, companies, and communities. However, it’s also quite academic.
The second half of this post proposes a simpler model for community. I share some common pitfalls that founders, early employees, or community builders may want to consider.
If you like this topic and would like to hear more, please let me know in the comments below or you can reply right to this email! I’d love to hear your feedback and other topics that you’d like me to cover either in depth or at surface level.
The Academic Model for a Healthy Open Source Community Structure
As in the case of all communities, there’s a hierarchy. This hierarchy describes the way in which different members of the community contribute and participate to that broader community. The academic model I found is titled: Exploring the Impact of Socio-Technical Core-Periphery Structures in Open Source Software Development.
Here’s how they characterize the onion-model for open source.
The paper is fairly dry, but the key structure they define is as follows:
Project Leaders: The Project Leader is generally the person responsible for starting the Open Source project. This is the person responsible for the vision and overall direction of the project.
Core Developers: Core Developers or Core Members are responsible for guiding and coordinating the development of Open Source projects. They have been with the project for a long time (occasionally since the project’s inception) and have made significant contribution to the system. In some communities they may be called as Maintainers.
Contributing Developers: Also known as peripheral developers, occasionally contribute new features and functionality to the system. Frequently, the core developers review their code before inclusion in the code base. By displaying interest and capability, the peripheral developers can move to the core.
Active Users: Contribute by testing new releases, posting bug reports, writing documentation and by answering the questions of passive users.
Bug Reporters: Discover and report bugs. They might not be fixing bugs as they generally do not read the source code. They can be considered the equivalent to testers in commercial software development.
Passive users: Generally just use the system like any other commercial system. They may be using Open Source because of the quality and the possibility of changing the software when required.
This model is a reasonable start and maybe most academically accurate. It defines some critical levels and structures thinking around those different levels.
However, it’s not quite as practical - how should you think about building a community? Should you model your community in this way? Should you as a community builder frame your own community in this way?
Some shortcomings of this model
While the onion model makes sense in the most general and clearly defined, I’m just not sure that it applies well to the real world.
(a) Distinctions without a difference
An active users and a bug reporters are two distinct users in the model that don’t matter in the real life. This distinction will not likely help you understand the health of your community. As a growing company, I find it hard to believe that you’re going to be optimizing for one or the other.
(b) Communities are networks, not onions
Members of a community all interact with one another - regardless of “layer”. Active users interact with passive users. Contributing developer influence those that are not yet part of your community. The onion’s layers do not capture this interaction.
(c) Growth and changes over time
Communities are not static. They drift. External factors might change them (the larger market or environment). Onions are just … hierarchical layers.
Let’s now explore a model that you can use to better understand your community - modeling your community as an ecosystem.
A Practical Model for an OSS Community in an Open Source Based Business
To make my point about the aforementioned model being a bit too academic and rigid. I want you to consider a marine coastal ecosystem.
Not unlike the one described in this wikipedia article.
What I love about this model for thinking about community is that it captures the full lifecycle. It forces you to think about the “grey area” between different maturity levels. You have to think about the environment for each group that will help them flourish. Work with me because there’s truth here.1
Let’s add in some more domain specific labels to fill this model out a bit more.
Now let’s define each of the stages.
🙋🏻♀️Novices
The youngest members of the community are, of course, the noobs. They’re just getting started. They may be excited to learn and share what they’re working on - they're bright eyed and bushy tailed. At the end of the day, however, they need protection from the outside world. They need a safe space to ask “dumb” questions, to learn and to probe understanding.
They need a space to grow up (in the seagrass) and a place to learn more about what they can do as part of your community.
You'll find these users in your forums, your community events, webinars. They're lurking to see if it’s worth joining and contributing. Notice, for noobs to flourish, you’ve got to have the right environment.
🧑🏾🎤Juveniles
Juveniles have grown from bright eyed and bushy tailed to some level of maturity with your tool. They might be sharing posts on their own and exploring more and more possibilities. They might be kicking tires with some basic contributors or reporting bugs. They are seeking to define their place in the community and want the status associated with that.
👩🏻💻Champions
Champions have seen success and may have done so repeatedly. They’re maturing themselves and maturing others as well. Champions file bug reports, write talks, and give presentations because they want the project to be better. They are the implicit leaders in the community - pushing for improvements.
These are folks that others look up to, akin to a Lighthouse Customer.
👵🏻Mature Contributors
These are folks that have been around the block. They know your tool. They’re members of the community (they might even be the original leaders). They drive changes in the community. You will find them presenting keynotes at your conference. They leading large changes in your project. This might even be you!
Some Failure Modes for Community Ecosystems
Now you don’t just walk up and build a community. There are several failure modes that I have seen that are worth mentioning. These failures crop up in particular with technical products and founders. While they might not be top of mind for you as a founder or early employee, they're critically important to consider.
🌴Not providing good habitat for growth
A community is a living organism. It consists of folks at different lifecycle stages. As a community leader, you must foster growth at all levels. You must balance your finite resources and ensure that you're actually helping people. Define clear ways of engaging with different users. Bring the different maturity levels together at times but focus on helping people go from stage to stage.
Example: Define status symbols for those that achieve a certain stage. If someone contributes a lot - can you think of a creative way of rewarding them? Of giving them status in the community?
🌊Too many young that don’t survive
This is one of most common failure modes for technical founders and products. Technical people typically don't care about the most novice or juvenile members. Most can't put themselves in the younger community member's shoes.
Moreover, users won't read the manual.
As a community leader, it is critical to provide opportunities for even the most novice members of the community to contribute and provide a simple path to learn. If your novice users can't figure out how to use your tool, you're in trouble.
Example: A lack of user friendly content. A lack of getting started content and landing pages to support that.
🤮Pollution - Too many changes before you’re ready to build a community
Building a community is hard because you need to set expectations. You must excite users with the possibility, while simultaneously setting expectations about reality.
If you're not ready to launch a 1.0, do not launch a 1.0. If you’re still scoping out your project, don’t pretend to be mature and production ready.2
Do not set expectations poorly and upset your users. Be yourself and understand that good things will come if you’re honest, upfront. Bring the community along for the journey.
Example: A 1.0 release that should really be a 0.3 release - don’t pretend that it’s ready for production.
🎣Overfishing - trying to sell to every single member of the community
This is a later stage issue (e.g., when you’ve successfully built out a project and monetized it). if users cannot independently succeed with your open source tool, you will fail at building community. People will quit.
Overfishing happens when the amount that you seek to take from your community (say with sales) is greater than the capacity of the community itself (or the carrying capacity).
I've got thoughts and stories in this area, if you'd like to discuss - let me know!
Example: Sales growth targets of 200%. However, your community growth is only 20%. Your board will be unhappy and your users will be too.
🎯Lack of target metrics for growth
You’ve got to be optimizing for something. This could be page views, it could be user flows, it could be drop off rates, it could be landing page conversion. Pick metrics to optimize and optimize them. Start simple, start with what you have and make it better.
Example: Trying to target top line numbers instead of picking more controllable and meaningful metrics.
🤨Lack of clarity of what it means to be part of your community
Another common failure mode is that there isn’t a clear objective around your community. What does your product stand for? How are people supposed to connect with it? Where do the people you want to speak to gather? Where do they meet?
Some Notable Books on the Topic
You cannot be everything to everyone and trying to be will lead you to fail. Here are two books I’ve read recently about community building.
The Art of Gathering is fantastic because it clearly articulates around purpose for why you’re bringing people together and the art of defining that.
Tribes is a personal favorite because Seth Godin… gets “it”. He provides clear guidance on how to think about community and brand building and I recommend the following book to anyone interested in building community.
Conclusion
Communities are hard and open source communities are no easier. As a founder or early employee, you need to think about how you want to bring people together. What objectives do you have with your community? Why should someone join it? What value do they get from that? Is it status? Is it career advancement?
Be empathetic and put yourself in the shoes of the members of your community - take a stand for what you believe in and build!
The community models above and books should get you started down the right path of building a strong and vibrant open source community!
Let me know your thoughts and questions over email or with comments below👇!
References & Links
Other posts from product of data in this domain…
Books
Blogs
On the topic of instrumentation…
https://www.productplan.com/glossary/aarrr-framework/
https://review.firstround.com/the-5-phases-of-figmas-community-led-growth-from-stealth-to-enterprise
Podcasts
One thing to note, while this is modeled for an “open source based business”, it’s not specific to open source.
We can have a discussion about what it means to be ready. There might never be a perfect time. Please understand the spirit of this, do not treat it as a law.