The Ultimate Playbook for Getting More GitHub Stars

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

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 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 had found six 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 six months ago, and hopefully, you will find this outline helpful as you launch and grow 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 status and a TON of visibility. (there are several factors that go into trending, but stars are 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 the following:

• 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 was linked on social.
• A 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 the best effort to communicate 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 bringing attention to the tool we had built.

From a bird's eye view, our GTM strategy had two "phases":

1. Get our first 100 stars artificially
2. 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. This 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 small talk 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 were 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 were 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, and 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. Also note that on platforms like Dev.to and HackerNoon, 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.
• 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, 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 . This helps us to distribute the content posted on our company’s blog in addition to the content published on 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 .” 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:

• - Add your library here for free (maintained by @nevodavid )
• - 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 toward 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:

• (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 are no different. The trick is to find 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, and conferences or by allowing you to publish a guest blog to their site, it can help you get a lot of traffic quickly.

We have been 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 - 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 invited 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 URLs. 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 a 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 it 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 times, 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 as and ) 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 in checking 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 (because it’s good to be different sometimes).

And when we hit the 1k star milestone, (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 three friends.

Other ideas to consider

These are the ideas that worked best for us so far and 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 its 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!

---

Also published .