Fix: developer chasm to engage more devs with my Open Source project
Wish I could push that `git commit` to move beyond the average initial developer engagement.
Developer Chasm means getting stuck with Open Source community growth after initial engagement
In this article, I will share the insights that helped me successfully move Open Source projects from initial developer engagement stage to the category leader stage with community-led growth. Learned from my experience in building developer communities and working as a Developer Relations Consultant for Open Source projects.
A quick note if you’re hearing this term “Developer Relations” for the first time
Developer Relations or DevRel meaning: A work function that covers the strategies and tactics for building and nurturing a developer community
How I ended up writing this post?
I was brimming with a smile when I received the invitation to speak on this topic (“engaging more developers with Open Source projects”) at Linux Foundation Summit 2022. I was excited and thankful to get the opportunity to meet Open Source project authors/teams, and that too in the best possible location for any conference — Lake Tahoe, California. Due to Covid pandemic situation, it was after such a long time that I was going to attend an offline event. But that smile didn’t last very long because I was not going there. Due to long waiting periods for US VISA resulted in canceling my travel plans. It would have been a disappointment to miss such a great opportunity but the Linux Foundation Summit team was kind enough to let me present remotely. Anyways, I presented that talk from my home. Here’s the recording of the talk.
If there’s a recording, why this blog post?
You’ll see that I took shortcuts covering some topics in the talk in order to keep it concise, matching the limited time I was given for the talk. So the video is a quick version of everything I wanted to share, and this blog post is a more detailed discussion on the topic with some added after-thoughts. I feel it does more justice to the job of sharing knowledge on this topic.
What is the source of my learning?
I have more than a decade of experience in diverse roles such as — Developer Relations Specialist for Open-Source projects, building Invide (a remote developers community), organizing Git Commit Show (a global developer conference), and of course — being a developer myself. You’ll find me quoting examples from these experiences.
What will we cover in this blog?
- What’s not a problem for Open Source projects today
- What is the challenge Open-Source projects face — Developer Chasm
- Case studies of solving Developer Chasm
- 5 insights to fix Developer Chasm
Disclaimer: The data mentioned in the post is from Nov 8, 2022. I didn’t update it as the conclusions are still the same.
What’s not a problem for Open Source software today
Open-Source has already won over proprietary
70–90% of modern codebase is the Open-Source code — Jim Zemlin, Linux Foundation
One estimate comes from the Linux Foundation, which found that in 2020, Open-Source software accounted for 70–90% of the code in any given piece of modern software. This means that the vast majority of software that we use today, from web browsers to operating systems to mobile apps, is built on open source code.
Open-Source is raining
- Total public repos — 43M
- Created in 2022–12M (27% of total)
As of today (Nov 8, 2022), there are more than 43 million public repositories on GitHub. A significant number of these public repositories can be counted as Open-Source software (we will come back to those numbers later in this post). The key data point to notice is that 12M new public repositories were created this year itself. That’s a huge 27% of the total public repositories. A big number. And we love that, don’t we?
Starting Open-Source project is easy
✅ Build a useful software [Easy]
If you compare the efforts it takes to build a web app or an automation system in 2023 vs 2000, it would seem pretty easy to build software these days. There’s already a huge ecosystem of useful open-source softwares for the majority of common developer needs. There are 43M public repositories on GitHub as of now and out of which a huge 6.1M are MIT licensed, and 2.2M are Apache 2.0 licensed. The tech education is available in abundance over YouTube and blog content. The support is quite easily available on GitHub, Stack Overflow, Reddit, Discord, etc. DevOps tools and cloud services further make it easier to test and iterate faster.
So making a software that takes the existing system one step further is not hard. If you have an idea and average programming skills, you just need to get started, and code it.
✅ Make it Open Source [Easy]
Even before you take the first step to build something, you can publish the first commit easily on GitHub or any other source code hosting platform. Git has matured so much that you don’t need to think about how you will deal with source version control. Many licenses have been standardized to cover various cases of ownership and distribution rights for your code. So it is only a matter of making the decision to Open-Source and a couple of mins to actually do it.
✅ Engage some early users [Easy]
It is not rare to see that projects get decent early engagement as long as there’s a need. This year itself, there have been 7000 new Open-Source GitHub repositories that received more than 100 stars. That’s a decent amount of engagement for a new project where some early adopters are considering the product to explore further, asking questions, reporting issues, etc.
😕 Engage more developers [Extremely Hard]
When you go beyond that first release and first 100 GitHub stars, the challenges start appearing in making it a bigger project. Starting is easy, making it meaningfully big is hard.
Is it true? Let’s discuss that with some data.
The problem Open-Source projects face today — The Developer Chasm
To understand that, let’s first understand how many devs engage with an open-source project. We will take the count of GitHub stars as a proxy to the number of developers considering exploring the project.
Out of 12M repositories created this year, 7000 projects have 100+ stars and only 55 projects have 5000+ stars. It means for every 128 projects that have 100+ stars, there’s only one that has 5000+ stars. Or in other words
For every 128 Open Source projects that were able to engage 100 developers, there’s only one that was able to engage 5000+ developers
Some more stats that showcase the exponential difficulty in getting GitHub stars (proxy to developer engagement) for public repositories:
- This year, by now (Nov 8, 2022), 12M new GitHub repositories have been created
- Out of which 70k had 10+ stars ⭐
- 1/10th of those 70k i.e. 7k had 100+ stars ⭐
- Only less than 1/14th of these 7k i.e. 500 had 1k+ stars ⭐
- 55 received 5k+ stars ⭐
- And only 15 new GitHub repositories received 10k+ stars this year ⭐
The problem — “Developer Chasm”: Getting stuck after initial engagement
From the stats, presented in the previous section, we can conclude that:
It is exponentially harder to engage more developers with your Open Source project beyond the initial engagement
From my experience as a developer, startup founder and DevRel consultant for Open Source projects, I have seen this pattern everywhere. You create initial versions of your Open Source project, share it with some friends and communities, you get some decent engagement and feedback, and probably do some more iterations of product and developer engagement strategies. And then you’re stuck there, it looks like you’ve been slowed down by an uphill path right after a smooth ride on a plain highway. You wonder how to engage more developers with your project in order to make it a category leader. This is the challenge this post aims to solve.
And that’s the problem we aim to solve in this post from a DevRel perspective. I say this “from a DevRel perspective” because this problem has been well documented from other angles but not from the angle of DevRel. For example, a book “Crossing the chasm by Geoffrey A. Moore” mentions the same challenge as “the chasm” using this popular graph:
The key concept mentioned in the book:
The chasm is the gap between the Early Adopters and the Early Majority. This is the point in the technology adoption lifecycle where a new technology must prove its value to a larger audience in order to achieve mainstream success. Companies that are unable to cross the chasm often fail to achieve their business goals.
As in our case, we’re focused on Open Source product adoption by developers,
Let’s refer this challenge of moving from early adopter to early majority phase as— “developer chasm”
You see that innovators section in the graph, that’s your audience who engaged with you when you first shared about your project publicly. And then you attempted to attract early adopters and either fail to do so OR found it hard to move to the next phase, the magical phase of “early majority”. The book spills the wisdom on strategy about how to solve this from a broad perspective with key ideas such as:
- Repositioning the product
- Finding the winning niche category
- Building relationships
A must read book. Great advice for any kind of tech product.
On the other hand, this post is a more zoomed-in view on how to solve this challenge with DevRel strategies and tactics independent of product decisions. What is it that your Developer Relations team can do to make the leap out of developer chasm?
Is it even possible for a DevRel person to solve the Developer Chasm?
More than often, you’ll find people labeling success as luck, being in the right place at the right time. Some people will say “build a great product, they will come”. Do products that have been improving at a great speed also struggle with the same challenge (getting stuck after engaging those initial users)? In my experience, yes. Even the projects that are improving quickly also face the same challenge. Without continuous engagement and feedback from users, it is even more difficult for motivated teams to improve the product. And that creates a negative loop, your product does not improve the way it should because you don’t have a decent developer engagement and you don’t get users because your project is not improving enough. You feel like being in a sunken place.
Engaging more developers beyond that initial engagement makes or breaks the project. Is it even possible to get out of this sunken place, the chasm?
Yes, it is possible to fix developer chasm. Some of the following anecdotes will help you see it through.
Case Study #1: Open-Source project that rose like a Phoenix
I was lucky enough to work on this Open-Source project that had become stagnant after the initial growth. The competitor(in blue) also had a similar story — after the first huge growth, it was not growing at a rate that the team would be excited about. But within two quarters, a series of decisions and activities led our project to experience that hockey stick growth beating the competition that had been around for some time. It reached that 10k stars mark quickly.
The learning: It is possible to solve that challenge of growing beyond first initial adoption.
Case Study #2: Community that engaged 15k experienced developers
In 2016, I started building an invite-only community of remote developers. As with other projects, initial adoption was great. 100s of experienced joined our chat channel but then, it stopped moving beyond that initial growth. Fast forward to 2.5 years later, we had engaged more than 15k experienced developers.
What made all these things possible? When I think about that, these are the points I come down to
1. Start with the decision to focus on one metric
Solve one problem at a time
If you have focus, half the battle is won already. More than often, I find Open Source project authors/teams making this mistake especially in the Developer Relations team, they want to do everything at once and many times working on (or not letting go of) projects just because of FOMO (fear of missing out). It’s important to remember that you can’t improve everything at once. So, start by focusing on one problem at a time. Once you have made some progress on that problem, you can then move on to the next one. I have seen the benefits of focusing on one metric and downsides of having multiple metrics to focus on.
Before, we dive into how to choose the right metric, let’s take a look at some of the example of the metrics I had chosen in my Developer Relations projects
Metric example 1: # of GitHub stars
Get to the 5k GitHub stars mark within 2 quarters
We chose this metric to aim for the key business goals:
- Break out of stagnant growth period
- Build better public/investor perception about the project’s growth
Example 2: # of support messages
Increase number of new support messages by 20% within a quarter
We chose this metric to aim for the key business goals:
- Increase community engagement
- Understand the community use cases, needs and the challenges
Example 3: # of interviews
Conduct 250x `1:1` interviews within 2 quarters
We chose this metric to aim for the key business goals:
- Grow the number of verified talented devs in the community for diverse skill sets
- Understand their needs/aspirations
How to choose the right metrics?
Start by asking:
- What matters the most right now?
- What will matter in the coming 6 months or a year?
Then come up with a list of different metrics that can reflect the goal progress and check which ones are:
- Aligned with the business goal
- Simple to understand
- Easy to track
Remember deciding the metrics is an art and experience helps
Some examples of metrics to choose from:
- GitHub stars
- GitHub repo traffic
- # of new slack/discord members
- Followers on social channels
- Comments on social channels
- GitHub forks
Beware of metrics such as:
- Docker pulls — Inaccurate data specially due to CI/CD and automation pulls which are not in small numbers
- Telemetry sourced metrics— Privacy concerns are not easy to tackle and this leads to incomplete data. And no, don’t think about defaulting to opt-in, you do not want to piss off your community
2. Simplify the communication
I was working with this Open Source projects’ team which had tried to engage developers on Reddit in the past but it did not work well for them. When I proposed to do this again, the team was reluctant to do so because of the past failures. Anyways, I started doing it, posting and analyzing one post at a time, and slowly the engagement on my Reddit posts started improving. Eventually this led to viral engagements multiple times. What change did I make that started giving better results on the same channel? The communication. Let’s take a look at the communication before and after
Before simplifying
One of the early posts. No engagement at all.
After simplifying
One of the later posts with decent engagement. Look at those numbers of upvotes and even more valuable than that — the % of people who viewed and upvoted: 96% (as compared to the prev. one which had 57% upvote rate only).
Why did it work way better than the earlier communication? While looking at the change, you might be tempted to make a conclusion — it is a simpler message, it is easy to understand for a broader audience, it showcases the value upfront, etc. While all those arguments are true, I still believe there’s no magic formula for communication which can result in better outcomes despite following these best practices. But what has always resulted in a better outcome is the process to refine the communication. Starting from wherever you are and taking the next steps to make it simpler and more interesting.
How to make your communication simpler and more interesting for developers?
Before you start working on this, one thing that needs to be understood is that the business pitch and the developer pitch are different. The way you communicate to each of them is not just slightly different but a totally different way of looking at the communication. The person taking care of the business (e.g. CXOs, execs) care for different kinds of problems, the developer cares for different kinds of problems, not just related to the technical problem but problems in life in general as well. They could be the same person acting like both but nonetheless, you should consider them two different personas to serve. Which is why keeping the DevRel function separate from Sales is key to nail both types of communications. Start thinking for this developer audience from the ground up, start thinking about the problems they face in their lives. Your content will usually solve those developer problems or at least show that you care about them. But how do you go about figuring out those problems and what does the process of refining this communication look like?
The process to refine the communication I like to call, the funky
QUAKE — Question Understand Answer, Keyword Experiment
Sometimes I like to call it DevQuake, as in earthquake. See I haven’t been sharp at naming things whether it is a variable in programming or an abbreviation to remember a process, open to ideas :)
Questions: Start with looking at the questions people are already asking on StackOverflow, Reddit, developer communities, events, anywhere you believe they will be asking questions. Usually these questions will be in the form of “how to do/fix/create X”. There are many more types of questions that you’ll discover along the way. Soak that information in.
Understand: From these questions, understand different problems or confusion they have. Not only the problem your product solves but also pay attention to all adjacent problems indirectly related to the key problem you solve, related to your category. Read between the lines. Note it down. This research will come handy later.
Answers: Answer those questions on internet forums. The activity of answering those questions will bring one step closer to how your audience thinks and why they think that way. It will help you think on a deeper level of your developer audience needs and behavior.
Keywords: Understand the keywords/style your early adopters use. Understand how they describe their problems, what keywords they use to explain their problem or expected solution, what keywords do they already understand, what knowledge do they already have about your category, etc. But mainly, it is about the “Keywords”.
Experiments: Experiment with new communication angles and then listen. It could be in the form of an educational post, it could be a simple question you might have, it could be an ask for help/feedback, it could be a celebration of a problem/solution, it could be something topical, it could be something inspirational, it could be a long rant, it could be in any form — text, image, video, etc. It could be the same communication but to a different kind of audience, etc. The bottomline is to be bold in experimenting with new angles.
If you keep following this for some time, you’ll see that your communication is getting better with your target developer audience. You’ll soon start seeing the impact of these improvements on the growth/engagement metrics.
3. Engage with developer wherever they are
I find many DevRel folks waiting for targeted developers to join their product community and only then they help them out. This is not a good strategy in my opinion and leaves room for competition to engage those people who either don’t know about your community or don’t feel the need to join your community. Instead, go out, engage with developers on external communities/forums asking questions related to the problems your product solves. This will build your reputation as an expert and bring those people to engage with your community.
Learning: “Don’t wait for them to come to your community, have conversations with devs outside your community as well”
Another limiting belief I see is related to how you decide on the external communities/forums where you decide to engage. Most of the time, I see that Open Source authors or their DevRel team has too narrow focus e.g.. if they have a search product, they usually focus only on search related communities; if their target audience is backend engineer, they focus only on backend engineer related communities. This leaves a lot of missed opportunities to engage developers. Instead, you should be thinking about a holistic picture of all the different things your target developer audience might be interested in. Aren’t there backend developers who love Chess or love Rick and Morty? Even some developers wouldn’t take part in a backend developer community but they will participate in a Chess community.
Learning: “A developer is more than just a developer, a human being with varied interests. engage with them wherever they are.”
Example: Think outside the box
I engaged developers for a search related product in a data visualization community. These two things do not seem connected but I asked a simple question — are there some developers who love data visualization, the answer is yes. Of course, not all data visualization lovers are developers but if my post goes viral, will it engage some of those developers who are part of this community? The answer is yes. And that’s what happened, the post went viral and there was a huge no. of GitHub stars we got from that activity. I had to think outside the box to come up with a communication for that community which will be relevant for everyone in that community as well as it will attract our target developer audience.
When engaging with external communities (e.g. HN, SubReddits, Meetups, etc.), you need to keep some things in mind so you do not end up pissing your target developers off. Be someone who adds value, not the one who keeps spamming everywhere. And there are some principles that I follow to make sure I am the former one:
- Understand first, then try to be understood. First understand that community, why people come here, what do they like, what kind of content do they engage more with, etc. Although, there are some hacks but it still takes time to do that, you gotta do that, there’s no other alternative.
- No more than one team member in a community. When you have more than one team member in an external community, you will end up coordinating to make your post look good. You will end up spamming when you both are in sync with what the other person is doing. All of this is not good for your project and you’ll piss some people off and do more harm than good. The solution is simple — one community, one person.
- Be the first one to start the conversation. The ego will kill your project. I have seen many DevRel folks, who try to play hard balls to make a perception about their project/team. It is useless and does the opposite. Have the humility to be the first one to start the conversations. As simple as that.
- Notice what they say, what keywords they use. We have discussed that before. Keep your eyes and ears open.
- Individuals over teams. Developers in communities hate people who say “we did this”, “we are so cool”, and so on. Instead think from an individual perspective, and communicate your authentic thoughts from that angle, people will be able to relate to that. For example, I never say that “we released a new version of our project, it has these cool x, y, z features”, I would rather say — “I have been working on this project for x months and I’m excited that the new version goes out today with features I contributed such as y, z features”. I bet that more people will engage with your second communication. Being authentic is never outdated and a key to communication that makes an impact.
4. The mindset: Obsess with transparency and ask for help
“It is a common false belief that in order to build your authority, you should not expose your vulnerability or ask for help”
– Pradeep Sharma
Case Study: Turning a PR disaster into an opportunity
Imagine you’re launching your Open Source project’s key release after months of hard work. You’re showcasing it in front of an audience of 200+ people in a professional live event. All of a sudden, someone hacks the event and starts playing a racist music and drawing vulgar sketches and you have to end the event there. This is a major PR disaster and disappointment for the team. It pisses off your team, the contributors, the investors, and everyone else who was attending the event. But later when you approach this with humility, authenticity and transparency, not hiding your vulnerable side, accepting your failures, and asking for help, this becomes one of the important reasons behind your exponential community growth. Here’s the link to this full story.
So what is the learning here? The mindset.
The mindset of the Open Source project owners can be a slow poison that kills the project silently or it can be a weapon that drives growth.
One mindset is to showcase only stuff that makes you look good and one mindset is to showcase everything irrespective of how it makes you look, for the sake of transparency. If I had tried to hide our PR failure, I wouldn’t have built the trust with the community.
Why obsess with transparency
If you’re running an Open Source project and don’t obsess with transparency, you’ll never build the needed trust in the community (whether internal or external community) to drive your project beyond that first level of engagement.
Transparency is the key DNA element of any Open Source project. This DNA makes it competitive to proprietary alternatives. This openness encourages a sense of community and shared ownership. There is a reason why developers trust Open Source more than the proprietary software — transparency. Transparency builds trust. It starts with showing your code in public, irrespective of it being good or bad, you put it out there for everyone to see. But this transparency should not end there, it needs to be reflected in every aspect of running an Open Source project, including the DevRel function. One key reason being, not everyone has the time to go through the complete code (and the later revisions) to make a judgment objectively about how much they can trust your project. They will use the transparency you show in your communication to measure how much they can trust you.
I am talking about genuine transparency, not the one where you share all good things and when something bad happens, you go silent. You are not doing anything unfair by going silent in that moment but you’ll never earn the trust of the community this way.
The way I measure transparency — how many times in a year do you share the news that you don’t need to in order to look good.
Why ask for help
There’s a sureshot way to not get any contributors for your Open Source project — do not ask for help. If you don’t ask, they won’t come. But the same feelings that stop you becoming more transparent also stop you asking for help when you should — fear of looking bad.
Asking for help is not a sign of weakness, but a strength. No one person has all the answers, and the beauty of Open Source lies in its collective intelligence. By asking for help boldly, you can tap into the knowledge and wisdom of the community. Asking for help empowers them with an opportunity to step up and take responsibility, fostering a sense of ownership and engagement.
Transparency and the willingness to ask for help are not just nice-to-have qualities in open source projects; they are essential.
Key points to remember
- Transparency is not about “sharing all the good news”
- Vulnerability builds emotional connection
- Why would someone help if you don’t need it
5. Scale developer education with content
Case Study: Turning the project to be synonymous to category
I was working on this project which wanted to be the leader in the “Neural Search” product category. I turned that Open Source project to be synonymous with Neural Search. What I did was this — I wrote one blog post and one video educating about the category of the product “Neural Search”, distributed that content well such that 75% of the first page search engine results was my content. If you as a developer were to research what “Neural Search” is and how to go about implementing it, you’re likely reading/watching my content. This content engages more developers with that Open Source project even after 2 years.
There were some more decisions involved in this overall achievement, let’s understand them.
Developers don’t like to be sold. They are the smartest people to detect BS on the internet. You telling them about your product is a form of BS for them, it has little impact on their decision making. If you’re banking on you telling developers about your product, you’ll struggle in getting any meaningful adoption or scale up your developer engagement.
Developers will always do their own research and make a judgment from there. But once their research reaches the conclusion that your product is actually a good choice for their use case, it will bring more users. Because they will share about their genuine research outcomes with their colleagues, their future employers, users on internet forums, etc. And that’s what other developers will see as non-BS content.
It is a slow process, and you can speed it up a little by creating a non-BS content yourself. But what is non-BS content? Educate your developer audience that can help them with their research. But what should you educate your developer audience about? Common answer I hear — about my product. It is the wrong answer. By teaching developers about your product, you may get some users if you’re lucky but you’ll never get meaningful adoption and will never be the category leader.
Instead, do this
- Pick the category that you want to lead
- Educate your targeted dev audience about this category
- Retarget that developer audience (whom you taught about your category) and educate them about your open-source project now
Conclusion
We discussed the good and worrisome things related to developer engagement for Open Source projects. We discussed the approach to overcome the challenge of getting stuck after initial engagement. These insights may help you to grow your Open Source project or become a better DevRel Engineer or just help you get one step closer to becoming one of the top Developer Advocate (a DevRel expert).
In summary, how to engage more developers with your OSS:
- Focus on one metric
- Simplify the communication
- Engage wherever they are
- Obsess with transparency, ask for help
- Scale with developer education content
P.S. I am also writing a book — Developer Relations Playbook. Although it is a work in progress, if you still want to read it, message me. I am open to DevRel consultant roles as well.
