TL;DR
- My team and I recently launched an open source tool for developers
- This was my first time promoting an open source tool. It was hard to find meaningful early-tage growth advice, so I had to get creative.
- We've quickly grown to more than 1.5k stars in a short time. I've compiled a detailed list of growth tactics that worked to bring us traffic and stars
- I’m sharing it all here so that others can apply these tactics and grow their own projects
Launching an open source project for the first time
Anyone involved in marketing knows that no two days are the same. You are constantly facing new challenges and unique situations.
And so it was a few months back when I was tasked with promoting a new open source project that we built, called Preevy.
I’ve spent years leading go to market efforts at various companies for dozens of products, but this was my first time doing so for an open source developer tool. Don't get me wrong - the devs on my team are seasoned OSS pros. But as the head of marketing, I was the open source newbie facing a learning curve.
I looked at my lack of open source marketing experience as both an advantage and a disadvantage.
On the one hand, I had a lot of catching up to do in a short period of time. On the other hand, it's always good when you can eliminate any preconceived notions of to how things "should" be done. I was free to research, question and develop a creative strategy with an open mind.
Writing the post I wish I found 6 months ago
Google quickly dampened my initial wave of enthusiasm. I looked for good advice to accelerate my learning, but most of the early-stage, open source growth content was shallow at best. I read articles promising to show me “How to get your first 1k Github stars” but was repeatedly left without the clear, tactical direction I was looking for.
The next couple of months became a whirlwind of research and experimentation to figure out what works and what doesn't.
And today, 12 weeks after launching Preevy, the project has 1.5k GitHub stars, and we’re seeing a week-over-week increase in repository traffic, forks and contributions.
There are several repeatable actions that have been effective in growing our traffic and our star count. In retrospect, some of them were buried in those generic "How to" articles, but most of them were not. Many of the creative steps we took (and continue to take) are lessons we learned the old-fashioned way.
So in the spirit of true open source, I've outlined some of our most effective tactics in one place. It’s the kind of resource I wish I had found 6 months ago, and hopefully you will find this outline helpful as you launch and growing your own open source projects.
Focusing specifically on traffic GitHub stars
To be clear - my specific focus is to show you how I got traffic and GitHub stars for my project.
I won’t be focusing on other (important) aspects of open source growth such as: converting visitors to active users, encouraging contributions to the project, best practices for repo maintenance, building a community around your project, or deciding what to build in the first place.
These are all worthy topics, but for another time.
For now, I only care about stars.
Why are GitHub stars so important?
The underlying assumption here is that GitHub stars have value. But what exactly are they valuable for?
Increasing your star count has several benefits clear and present benefits:
- It focuses the team's efforts and motivates everyone to rally around a single cause and a single metric that is constantly increasing
- Stars = credibility and trustworthiness in the eyes of potential users and contributors
- Your pool of stargazers can teach you a lot about your target audience
- Stars can help you reach GitHub trending status and a TON of visibility. (there are several factors that go into trending, but stars is an important one).
So if you’re trying to promote your GitHub library, you should be thinking about how you can get more people to star it, especially in the first couple of months after you go live.
So without further ado, let's take a deep dive into the key growth levers that worked for me and my team.
Prerequisites: Basic repo health
The first thing I focused on was making sure our repository was set up for success.
Those generic articles spend a lot of time on this, and like with any good cliche - there's a lot of truth to it. So we established a baseline for repo health that included:
- A clear description of what the tool does
- A Readme that is both informative and aesthetically pleasing (screenshot/GIF at the top, clearly structured, use of some emojis to mix it up a bit). I also upgraded the social card that appeared when the repo is linked on social.
- A dedicated docs site with relevant technical information and how-to guides for people who want to use it
I don't have a lot of wisdom to add here. Just make a best effort at communicating clearly in your documentation (without any fluff) and don't be afraid to iterate as needed.
Once we covered the basics for Preevy, we set our sights on brining attention to the tool we had built.
From a bird's eye view, our GTM strategy had two "phases":
- Get our first 100 stars artificially
- Maintain natural growth from 100 stars and beyond
The first 100 stars - artificial growth
We wanted to get our first 100 stars quickly, so we started close to home. I assumed that between all of us on the team, we could find 100 relevant, first-degree connections willing to click a button and congratulate us on launching a new project.
Here are the main actions that worked for us in this phase:
Kick-off message to friends and family
We started simple. I composed a message announcing that we’ve just launched our first open source project, and asking people please check it out and show us support by leaving us a star. The message was simple and friendly, but also direct.
Don't just reply with a thumbs up. Go to GitHub and give me a star (please).
Each team member sent it out to people in their network: Relevant friends and family members, via email, Whatsapp, LinkedIn and Twitter DMs.
Ask the neighbors in our shared office space
Our company office is in a shared workspace. Which means there are dozens of other startups and active GitHub accounts within a few meters of my desk.
So I swallowed my pride, printed a QR code (to make it easy for others to open our repo on their device) and made a few causal rounds around the floor asking people if they could do us a quick favor and show us some GitHub-love. The vast majority of people were happy to help.
My non-scientific assessment is that early morning had the best conversion rates, while people were still small-talking over coffee and before they got focused on their more serious daily tasks.
Show it off (for free) at conferences
It just so happened that I attended a local tech conference shortly after Preevy launched. So I adapted the shared office space strategy to the conference showroom floor. I walked around and tried to use my smalltalk opportunities to get a few more stars from the developers walking around.
First launch announcements on social media
Once we had a few dozen stars, I posted about our launch on our social channels.
I wanted new visitors to the repository to see that at least a few dozen people had already been there and liked what we are doing.
Pretty soon, we celebrated our first 100 stars milestone, and we were ready to move into phase 2.
Beyond the first 100
I probably could have used the above tactics alone to get us to 500 stars or more, but it would have been inefficient, and regardless - I wasn’t interested in this approach. My phase 1 focus was only on the 100-star threshold so as to establish the minimal credibility needed to convert future traffic.
Our first 100 stars were decidedly artificial. And I wanted all the rest to be authentic and organic.
Organic stargazers tell you a lot about who is interested in your tool. Analyzing a growing list of stargazers gives you product and marketing insights that you need to move forward effectively. So it was important to me that our list of stargazers grow naturally, as soon as possible.
Here’s what worked for us as we moved into growth phase 2:
Content creation
Content creation and distribution was a big part of our strategy (and this continues to be the case). This topic alone deserves a dedicated blog post or two, but we’ll summarize the key elements here.
As far as content creation, we set out to create an ongoing flow of blog posts. These posts fell into one of four categories:
- Present the tool directly - We wrote a number of posts that talk about Preevy directly. What it is, why we built it, who we think can benefit from it. These can be very effective when they are written in an authentic, human way
- Present the tool indirectly as part of a larger project - We wrote a number of “How-to” posts that show how to build a cool project, including Preevy as part of the stack
- Listicles - We put together a few list-based articles that had an open source angle to them. “5 Projects that will help you learn [some framework]” or “10 new open source repositories you need to know about in 2023” or something similar. We included Preevy in the list when relevant, but not every time.
- Building in public - Open source is about sharing with others. So we wrote several posts explaining how we solved an interesting problem or how we achieved a relevant milestone (like this post, for example)
Each post had clear section headings. We added a TL;DR at the top and emojis/GIFs to keep it friendly and fun to read. We mentioned explicitly that we are building Preevy and we’d appreciate it if people could check it out and star the repository. We phrased this in-line request in different ways (sometimes more directly than others), but we always found a way to put it in the body of the article as a clear call to action.
Content distribution
Writing content is great, but it won't help you if you don’t have a good plan for distributing it to the relevant people. Here’s how we distributed our Preevy content:
- Dev-centric blogging platforms - We published our content on dev-centric blogging platforms like Dev.to, Hashnode, Hackernoon, and Medium. These are the main platforms we’ve been using, but there are others you might consider as well. When doing this, be mindful of any platform-specific tags you can use to better position your content (for example, DevTo has a #showdev tag that can help show your new tool off to other developers). Also note that on platforms like Dev.to, you can create a company blog with a fixed call to action that appears on the right side of any article you publish there. This helps to get more people clicking through from your content to your GitHub repository.
Here's one of our posts trending on Dev.to:
- Reddit and social media - Once the content was published on the above platforms, we promoted it on social media and in relevant subreddits. We did not drive traffic to our company blog (we’ll get to that in a minute). Rather, we intentionally directed people to the articles hosted on these outside blogging platforms. We did this because each of these blogging platforms has a built-in trending algorithm that boosts high-performing posts. By driving traffic to these links, we got the platform algorithms to work for us and get our posts many more views in a short period of time.
- Our company blog - Don’t worry. We didn’t forget about our own site. We also published all content on our company blog. After all, SEO is still a thing, and so it’s good to have all that relevant content hosted on the company domain. As extra credit, we also managed to get our blog approved as a content source by dev-centric content aggregators like daily.dev. This helps us to distribute the content posted on our company’s blog, in addition to the content published on those external blogging sites.
Github Lists and Topics
There are tons of great lists on GitHub (often called “Awesome Lists”) where maintainers aggregate tools, projects and resources with a particular focus. We found several lists relevant to our tool, and opened a pull request to suggest Preevy as an addition.
Note that in some cases, you’ll need to make minor adjustments to your project or documentation to meet the list membership requirements. But this could be worth it if it's a popular list that has a lot of visitors.
In addition to “Lists” which are privately maintained, GitHub also maintains “Topics”. Open source projects can be submitted for inclusion under a relevant topic, but only by someone who is not connected to the project in an official way. So if you have friends or early adopters of your tool who love what you’re doing, you might consider asking them for a favor and having them submit your project to a few of these GitHub "Topics".
We’ve used both Lists and Topics to promote Preevy.
Other Sites and Newsletters
We found a number of sites and newsletters focused on promoting open source tools. We used these resources to promote Preevy. Here are two examples that were effective for us:
- GitHub20K - Add your library here for free (maintained by @nevodavid )
- Console.dev - Submit your tool for free, or pay to sponsor a newsletter
Relevant communities and dark social
We joined a bunch of communities. We wanted to be a part of relevant conversations, and promote our tool and our content in a more natural way. These communities exist on platforms such as: Slack, Discord, Reddit, Whatsapp, LinkedIn and Facebook. To find communities relevant to you, just spend a few minutes searching, or ask others in your industry to guide you towards the communities that are worth joining.
We noticed that each community has its own rules, nuances and opportunities. For example, on a particular Slack or Discord server, there might be a channel dedicated to showing off new tools or promoting new content you’ve written. Similarly, many subreddits have one day per week where you can self-promote something you’ve built and get feedback. Once you've found some communities, make friends and play by the rules.
Paid ads campaigns
Once we generated a decent amount of organic traffic, we ran some small, paid ad campaigns. We used three advertising platforms:
- Ethical Ads (a dev-focused advertising platform)
- Reddit (with a focus on specific, technical subreddits)
- Twitter (with a focus on specific, relevant keywords)
These campaigns brought us traffic, and they also allowed us to test our messaging and learn more about what attracted people to our repository. We used these results to further optimize our content and our future ad campaigns.
Influencers
Influencer marketing can be very effective in any industry, and open source/developer tools is no different. The trick is to the right people with the right audience.
We actively searched for those people in our industry, developed relationships and ran some collaborative experiments. The majority of them were successful (a few were not, which was expected).
Each influencer knows their audience and their style. Be clear about your campaign objectives and work with them to create the content and campaigns that work best (co-created posts, product reviews, shout-outs on social or whatever else you all have in mind).
Podcasts and promotions
I’ll keep this one brief because it’s pretty self-explanatory. If you can find other people to promote you on their podcasts, webinars, conferences, or by allowing you to publish a guest blog to their site, it can help you get a lot of traffic quickly.
We were able to do this a couple of times for Preevy so far, and we’re already working on more of these opportunities.
Use cases and testimonials
Because I’m active on dev-centric blogging platforms, I kept an eye out for dev bloggers who were experienced and well-versed in our space. I looked for high-performing articles and reached out to the authors to ask them if they wanted to try Preevy and write about it.
Some wanted to be paid (rightfully so), and some (surprisingly) did not.
Some wanted to ghostwrite for us (without using their name) and some wanted to publish content in their own name on their own pages.
It took us some time to find the right people, but once we did, all of the above arrangements worked for us.
Hackernews
We used Hackernews to promote Preevy in two ways:
- Post the GitHub repository under the “Show HN” tag - Hackernews can be a great place to share your new project with other technical folks. It helps to get others to upvote and comment soon after posting (just don’t share the direct link to your post!). We added a first comment where our CTO explained what we built and inviting others to try it. I don’t know if this comment helped, but I saw a lot of other open source projects doing the same. And while I can’t say for sure, it seems like HN is friendlier to GitHub repository links as opposed to some branded URL. So with a bit of coordination, HN could give you a potent dose of traffic.
- Post content - We’ve tried posting some of our content on HN. Success is hit or miss, and HN will not even accept posts from some external blogging platforms. But it’s free to try and the potential upside is huge.
Social media retargeting
From the moment we formally announced the Preevy launch, we had organic social media activity running in the background. We'll save the detailed social media strategy for another post, but suffice it to say that the account was active and the content was varied.
As more people engaged with the content, I began retargeting as many of them as possible by inviting them to try/star Preevy for themselves.
I had Twitter DM template that I would send them, thanking them for linking our recent post and asking if they’d be willing to star the Preevy repo.
It took time, but lots of people were happy to help.
Shamelessly promote other people and projects
When I outlined my approach to “content creation” above, I mentioned that one types of content we’ve produced are listicles of other relevant projects or tools. One of the reasons this content is so effective is that is enables us to shamelessly promote other people.
Open source is not a zero-sum game. There’s enough traffic and enough GitHub stars to go around. And by genuinely promoting other people, companies and projects, you can get them to promote you in return. it’s almost like a “forced” collaboration and it’s often a win-win.
So for example, when we wrote listicles that included other open source projects, we tagged these companies/maintainers on Twitter when we promoted the article. Many time, they would like and retweet, adding a lot more reach to our content. This approach can be applied in many different ways, but it’s potent enough to deserve a dedicated mention in our list of open source GTM actions.
My (crazy) Github retargeting experiment
Once we reached a few hundred stargazers, I analyzed the modest audience I had built. I developed an experimental, multi-part playbook for promoting Preevy in a more targeted way to people who were more likely to be interested in it. Here’s a quick summary of what I came up with:
- I used tools (such at this one and this one) to see what other repos our stargazers were starring most frequently. The stargazers of these "other" commonly starred repos became an expanded pool of potential stargazers for Preevy
- I looked through the stargazers in these other repos and identified people who had publicly exposed email addresses in their GitHub profiles. To me, this was a clue that they didn’t mind being contacted via email
- I further identified the people who I thought were most relevant and followed them on GitHub
- Then, I reached out to these folks via email, told them I had just followed them and introduced myself and my project in case they were interested to check it out.
The last two steps were just my personal spin. You can probably do without them. The main idea is to use your pool of authentic stargazers to point you in the direction of a wider pool of similar users who might be interested in what you have to offer.
As a bonus, you can also look at what those most commonly starred repositories are doing to market their tools, and try some of it yourself.
Celebrate milestones!
We took every opportunity to celebrate a milestone in our Preevy growth journey. Every hundred star milestone got a celebratory GIF and a set of posts to drive as much positive attention to the repository as possible.
And when we missed celebrating 700, we celebrated 735 instead (because it’s good to be different sometimes).
And when we hit the 1k star milestone, we kicked off a celebratory giveaway (which is actually still open until the end of this week). To enter, people need to star the repo, follow us on Twitter and retweet/tag 3 friends.
Other ideas to consider
These are the ideas that worked best for us to far, that can easily be applied to other projects. We had tons of other ideas that didn't work as well, or that worked but were very specific to what we were building.
We have a bunch of experiments still to consider and in the spirit of open source, I'll share a couple of them here for your consideration:
- Translate the readme into multiple languages - At the moment, the Preevy readme is in English. But I’ve noticed that in the GitHub trending lists, you can filter by spoken language. I wonder if translating our readme into other languages will create a larger surface area for the repository to hit those trending lists with more frequency
- Product Hunt - We’ll soon be launching Preevy on Product Hunt. It’s a great place to launch new products and tools and we’re looking forward to leveraging it’s reach to bring a lot more attention to what we’re building.
In conclusion
I hope our experience in starting to grow Preevy can help you grow your own project - by borrowing some of these ideas or by thinking of new ideas on your own.
I'd be thrilled to get additional open source growth suggestions in the comments!
And if you've made it this far, and are willing to leave Preevy a star I'd really appreciate it! https://github.com/livecycle/preevy 🙏 🙏
Top comments (12)
Fantastic practical guide!
Not sure if you are using any back office tools but for Excalibur.js we use Common Room and it's been helpful to understand our community makeup.
For releases, we also create short video overviews since we only publish occassionally, and we plaster on all the external contributors to thank them. In the release notes, we tag them, so they see it and hopefully share it as well.
One tactic we've played with and started to find some traction was live streaming of building in public with tech surrounding our tool (web gamedev, in our case). So for example, Aseprite is a pixel graphics editor that's commonly used for gamedev and Erik did a livestream implementing native support for it in the engine. He had a lot of live viewers and engagement, but we also noticed that straight posting the 4-5h long streams doesn't really engage anyone on YT -- which I think makes sense. We are thinking of editing all those down into short bite-sized videos instead, or repurposing them into an overview of the tech/subject instead.
Like you said, it's all about ideas and experimentation and seeing what works/what doesn't.
Good luck with Preevy, deployment previews are awesome!
Thanks @kamranayub! Appreciate the kind feedback and the creative additions. We've actually been thinking about livestreaming "office hours", similar to what you're describing. I'm defintely interested to trade notes if you're open to it!
⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️
The real star is you @zevir
Great post and acheivements!
Thank you for mentioning GitHub20k!
Thanks for all your help along the way!
Definitely the most comprehensive guide I've ever read about stars. Except maybe Hawking's "A brief history of time", that would be more comprehensive, but good luck getting past the first chapter.
Well, I might be able to use this for marketing my repo. Still, this is overwhelming for me so I might have to start off small.
@ruralnative - for sure. Start small. Focus on the first 100-200 stars and see what works for you. If I can be helpful LMK. Can you share your repo/project?
Yeah, it is unfinished though and is still in progress. But I have two: Handsy Mobile App (github.com/RuralNative/Handsy-Sign...) and a reference guide for learning AI from scratch until you can build a hand sign detection model with MediaPipe (github.com/RuralNative/AI-Hand-Rec...)
such an insightful playbook. thank you, @zevir 🙏
my key takeaways:
looking forward to your launch on Product Hunt!
spoiler alert: when launched Documenso, the number of GitHub stars skyrocketed (+300%). enjoy!
That's awesome post.