How To Engage More Developers With Open Source Projects

Fix: Developer Chasm To Engage More Devs With My Open Source Project

Wish I could push that git commit to move beyond initial developer engagement. A 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 the initial developer engagement stage to the category leader stage with community-led growth. I learned from my developer community-building work and developer relations consultant work for open-source projects.

A quick note if you’re hearing the term “Developer Relations” for the first time.

What Is the Source of My Learning? 

The source of my learning for the topic is my experience as a 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
• Five insights to fix the 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

Public repositories on GitHub [Data Source: GitHub, Nov 8, 2022]

• 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 an Open Source Project Is Easy

1. 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 software for the majority of common developer needs. There are 43M public repositories on GitHub as of now, 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.

2. 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 minutes to actually do it.

3. 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.

4. Engage More Developers: Hard

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 for 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. 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

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, 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, the 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,

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 failed 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 tech product.

On the other hand, this post will provide a more detailed view of how to solve this challenge with DevRel strategies and tactics independent of product decisions. What can your Developer Relations team do to leap from this 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, and they will come.” Do products that have been improving at a great speed also struggle with the same challenge of getting stuck after engaging those initial users? In my experience, yes. Even the projects that are improving quickly also face the same challenge. And this turns into a loop where it is even difficult for products to improve without continuous engagement and feedback from users. So engaging more developers beyond that initial engagement makes or breaks the project. What can open-source maintainers do about it?

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 came up with: 

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 often than not, 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 work on (or not let 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 the 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 examples 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 of the project’s growth

Example 2: # Of Support Messages

Increase the 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 250 `1:1` interviews within 2 quarters

We chose this metric to aim for the key business goals:

• Get verified talented developers in the community, controlling the community diversity and the needed characteristics of the members
• 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

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, especially 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 past failures. Anyway, 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 multiple viral engagements. 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 a 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 that can result in better outcomes despite following these best practices. But what has always resulted in a better outcome is the process of refining 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) cares for different kinds of problems, and the developer cares for different kinds of problems, not just related to technical problems 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.

This is why keeping the DevRel function separate from Sales is key to nailing both types of communications. Start thinking for this developer audience from the ground up, and 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 an 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, and 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 in handy later.
• Answers: Answer those questions on internet forums. The activity of answering those questions will bring you one step closer to how your audience thinks and why they think that way. It will help you think on a deeper level about your developer audience's 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 with your target developer audience is getting better. You’ll soon start seeing the impact of these improvements on the growth/engagement metrics.

3. Engage With Developers 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 and 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 have too narrow a focus, e.g., if they have a search product, they usually focus only on search-related communities; if their target audience is backend engineers, 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 Rick and Morty? Some developers don’t even 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. That’s what happened: the post went viral, and we got a huge number of GitHub stars from that activity. I had to think outside the box to come up with a communication for that community that would be relevant to everyone in that community and would 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 and 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, “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 and z features.” I bet that more people will engage with your second communication. Being authentic is never outdated and is 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 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 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 with proprietary alternatives. This openness encourages a sense of community and shared ownership. There is a reason why developers trust open source more than proprietary software — transparency. Transparency builds trust. It starts with showing your code in public; irrespective of whether it is 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 is that not everyone has the time to go through the complete code (and the later revisions) to make an objective judgment 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 from becoming more transparent also stop you from 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” and distributed that content well such that 75% of the first-page search engine results were 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 telling developers about your product, you’ll struggle to get any meaningful adoption or scaling 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 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 bit by creating 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 aspects of developer engagement for open-source projects. We also discussed an approach to overcome the challenge of getting stuck after initial engagement. These insights may help you grow your open-source project, become a better DevRel Engineer, or just get one step closer to becoming a top Developer Advocate (a DevRel expert).

In summary, how to engage more developers with your OSS:

1. Focus on one metric
2. Simplify the communication
3. Engage wherever they are
4. Obsess with transparency, ask for help
5. Scale with developer education content