How Plane, an open-source alternative to Jira, got to the #1 in project management on GitHub in less than a year
Our lessons from 0 to 20K GitHub stars in a year
CEO's desk
Vamsi Kurama
December 7, 2023
13 min read

On September 18 this year, we crossed 14K stars and stood at #1 on the list of open source project management tools on GitHub. Curiously, every chat over the last two months, be it with users who are switching over to Plane from Jira, Aha!, and Linear, other OSS companies that want to partner, or about offers to speak at OSS events, opens with surprise at our star-growth and echos what others have asked me online and offline.

“How did you do it?”

This post is a summary answer to that question, strictly from the privileged ring-side view I have had of our short journey of the last year. It covers what worked for us, where we failed, and what we have learnt about popularity in open source. Hopefully, it encourages other open source start-ups to avoid our mistakes if nothing else.

“But what are GitHub stars?”

GitHub stars are like Facebook Likes or Twitter Hearts for GitHub users, largely developers, with the added benefit of GitHub-native notifications from starred projects. For open source projects, especially new ones like ours, they are a good popularity indicator and thus, initial success with a core audience group.

Naturally, our claims of topping our category were met with hoots and shout-outs from our users and supporters, disbelief from industry watchers, and in one case, a jibe. We have continued at a faster clip since and just crossed 18K stars in October.

The more you know

We're not the fastest or the first to get to the coveted #1 position on GitHub. We have often tipped our hat to, Supabase, Appsmith, and Hopscotch for setting several precedences at GitHub success. Some GPT projects are skyrocketing to 100K stars as I write this!

If you are open-source on GitHub, ignoring star growth could be an expensive mistake.

Many in open source have voiced their disillusionment with GitHub stars, what with the trend of now buying them just as you can Likes and Hearts. I agree with the spirit of it, not the devaluation of stars.

To offer an analogy, you wouldn’t complain if your handle got 18K followers on X or Instagram or LinkedIn early on, but you wouldn’t make that your North Star metric. Similarly, the more stars, the better GitHub’s network effects, the more eyeballs on a project—gold in the early stages of open-source—but soon enough, you would want to switch tune to use cases, growth, and customers. More on that coming soon

Rolling out of the hangar

Plane tiptoed on to GitHub on November 19, 2022 to cheers and raised glasses from exactly five wide-eyed watchers, all of whom are still at Plane and cheer every release as they did the first one. It was a private repo, so you had to be invited to see the project. It was expectedly vanilla, offering issue management via cycles AKA sprints and modules AKA epics, in List and Kanban-style layouts. It was admittedly a tad bumpier than a country road for anyone who wanted to host Plane themselves, including us.

We weren’t ready to announce Plane anytime soon, but that meant, we had time to experiment with how we communicated value, talked about features, and wrote our private release notes in one-on-one e-mails, which later became winning tactic #2. But first, we needed committed users.

With Plane, you can manage tasks, track them by cycles, and even group them by modules. Share your work with clients or users, customize your workflows, and move work to the right.

Tactic #1: Community

Open source is a tribe and that tribe is demanding. It wants to know that your project is cool, serious about its existence, and is built for participation. To communicate all that consistently demands diligence that is tough for a very-early-stage start-up. While we could have gone all out with promoting Plane, we knew we weren’t ready to handle engagement at scale.

Much before we went on to GitHub, we promoted the project privately to our network of friends, friends of friends, and acquaintances who would find value with the tool. We sat down with all of them, got their feedback, heard their use cases, and continued cranking out updates for the top requests.

A very early blurb we sent out to a bunch that got trashed by just about everyone.
What worked #1
  • We crowdsourced ideas for comms, not just the product.
  • We asked them to outline their business goals, describe their troubles with other software, name our features, even opine on the logo.
  • We consistently kept them updated about our progress.
What didn’t #1
  • Automating updates and boilerplate responses
  • Delays with Support requests, especially from new users

At some point before the end of October, we felt the need to turn this cabal of tens of users into a community. We also wanted to time it to our go-live on GitHub. We set up Discord on November 19, 2022 and sent out twenty invites in total to our server. That server has already crossed the 2,500-member mark and counts 1,890 active members at the time of publishing.

Discord is geeky, fun, and packs features for at-scale community engagement, but we didn't bother with any of that. Our goal was to engage our earliest users with product muscle, turn them into fans, and have them spread the word. So we stuck to the basics, creating just one other channel—#feedback—apart from #general which is auto-created for each server. We pushed people early on to #feedback for complaints, requests, and demands—ahem—while keeping #general reserved for project management banter.

Soon enough, more users trickled in and started showing an interest in contributing to Plane. To an open-source start-up, this is a huge mile-marker and tells you you got the cool factor down pat*.*

offer-to-contribute-to-the-plane repo-discord
We weren’t ready to take contributions in January, but we opened that up, too soon after.

Also trickling in with these users were their requests for more—more features, more experience, more everything. Which was great, because it gave us ready opportunities to talk about their problems and send them personalized updates when we shipped new features and improvements.

We responded to every new request for a workaround, every bug report, and every new feature ask within minutes.

In return for this white-glove, hyper-personal engagement, we started actively asking for referrals. And they did. It wasn’t anything crazy, but we saw more than five users join our Discord every week.

What worked #2
  • Active comms, probing for the whys behind every request, and workarounds
  • Personal messages when a feature got shipped
  • Asking for referrals
What didn’t #2
  • Lengthy messages with unnecessary context
  • Shying away from sharing work in progress
  • Not creating a dedicated forum for Support early on

In hindsight, this was the game prep we needed before we went wide with our repo and promotions. It let us see challenges ahead of time, plan for them, and execute with intent.

First flight(s)

v0.1-dev in January was our first release and garnered encouraging inbound interest. Some of those were referrals, sure, but most of those were due to one of our early private experiments—well-crafted release notes.

Before there were release notes, though, there was our GitHub README, the About page of any project on GitHub. We had heard it worked for new users and some even called it nice.

Self-hosted options quickly followed the hero and the intro. For those who needed a little more, there were screenshots.

Apart from feature highlights and show-and-tell, it also had links to Docs and a way to reach out about security worries. We haven’t changed it. In fact, we drew heavily from our experience doing it up.

What worked #3
  • It didn’t push Plane into anyone’s face.
  • Short-and-sweet instructions for self-hosting came first.
  • There were links to destinations new users expect to see.
  • Using simple language, keeping in mind of the global audience
What didn’t #3
  • The full readme is a little too long.
  • We heard some folks saying it was too promotional—something we are still considering changing.

Tactic #2: Release notes

“Why craft release notes? Who does?” Allow me to answer with this craziness from Tumblr.

While none of our release notes are this mad—and probably never will—, they were great for three early goals.

  • Educate your existing users about a feature.
  • Engage them with whatever’s new and exciting.
  • Convert lurkers into users.

For an early-stage, resource-crunched start-up, few other marketing avenues come close to the ROI of well-done release notes. So, that’s what we did.

The one-on-one blurbs we had sent out in e-mail and LinkedIn + WhatsApp DMs helped us figure out a structure to our notes—excitement, education, and information in that order. For those looking to go deeper into a feature and public GitHub conversations leading up to the release, we linked each bullet to its own PR, GitHub lingo for open and closed roadmap items.

Forgive us the bluster and cut straight to Highlights. 🙂

Then we went about distributing them on Reddit and Twitter—winning tactic #4.

16 upvotes is no dance party, but it signaled to us there was interest.

New users trickled in with each release, courtesy GitHub notifications + popularity, and started talking to us. That led to more candid conversations about more use cases and more whys behind trying Plane. Combined with a quick walkthrough of our then-private roadmap, these conversations allowed us to build first-name relationships with early adopters.

Plane’s come far from this version.

The more we wrote ‘em notes, the better we got at structuring them for readability and show-and-tell. Soon enough, we were writing them like we would write a round-up on our blog.


Our next and current evolution included,

  • Features
    We turned Highlights into useful sections about new and exciting features that users were waiting for. Anyone not troubled by a bug could just focus on this and move on.
  • Visual aids
    Next, we made it easier to see value in the features we were building with screenshots and GIFs. For a UI-heavy product like ours, this was not just cool. It worked beautifully for user education, as evidenced in our how-to requests going down by about 50% for new releases.
Slide 1
  • Improvements
    Meant for existing and engaged users of the product, this section talked about a much-awaited workaround or micro-feature that improved user experience.
  • Bugs
    For the more technical audience and those that were blocked by a bug, this section focused on unexpected behaviour that we had killed.

Breaking up our release notes this way allowed us to spotlight areas for what users at different stages of product adoption cared about, which, if you think about it, is Product Marketing 101 in principle. Plus, it also let us push these notes straight from GitHub into a blog-page-like layout on our earliest version of our website. Anyone on that blah avatar of our site instead of on GitHub could now discover features, see our release cadence, and sign up.

Tactic #3: Repurposing content

“Yeah, sure! Content. Isn’t everyone and their grandma doing content? Like literally.”

Bear with me while we do some back-of-the-hand math.

  • We have had 12 releases so far.
  • In total, we have talked about,
    • 2 major features
    • 4 noteworthy improvements
    • 15 bugs squashed
  • Simplistically, that’s 21 unique things to talk about.
  • For just five experimental destinations where our audience hung out, that was 105 opportunities to show Plane off.

Of course, we didn’t have 105 things to talk about in January and you can’t talk about everything with everyone anyway, but you can see how it compounds over months. With a simple calendar on Notion—this was before Plane got its own calendar view of tasks—, we could talk about almost all of our product as it got built in different ways to different audiences on different social networks—all of this over and above one-and-done release notes.

What worked #4
  • Cycling posts through five destinations
  • Bringing older updates back up to the top of our users’ feeds
  • Figuring out destinations and networks that were working well
  • Doubling down on them and discarding others in the short-term
What didn’t #4
  • No variation in language or tone for different channels

Tactic #4: Deliberate distribution

The two networks we saw traction with for our early social posts were Reddit and Twitter.

While most marketers will tell you to step gingerly on Reddit, we left that advice to marketers. We are Redditors ourselves and we sort of get what works for other Redditors—transparency, humility, and value. Reddit also loves open source, so we knew Reddit could be one of our biggest sources of traffic and sign-ups, so planned for Reddit first.

Despite the humbling ten or fourteen upvotes we had seen thus far, we continued distributing our content consistently, experimenting with tone, style, formats, and even sub-reddits, Reddit destinations dedicated to topics. We had already seen r/selfhosted, an active and popular community of open-source buffs, show interest in Plane, so we continued engaging with users there, but we also moved into several other sub-reddits for,

  • Project management and agile because we are all about that life
  • Next.js because we have a bunch of it in our tech stack

In each one of these sub-reddits, Plane became a showcase for our philosophies, implementation, and vision, but most of all, audiences saw our consistency in not just putting up Plane updates but also in responding to questions, how-tos, feedback, and sometimes, criticism. Interest and sign-ups kept ticking up and to the right.

Looking back, that kind of consistency and careful engagement is everything in early-stage communication irrespective of the social network or channel you are on. It snowballs into a word-of-mouth engine that begins to run all on its own soon enough.

Back then, though, we were antsy for anything that caused a spike. Consistency and gradual upticks were okay, but we were looking to shoot past our local maxima.

Climbing up

The first hit came with primetime Reddit engagement—a hundred upvotes on one post—for our Github Sync feature.

While feedback flowed in in varying shades of constructive, uplifting, and occasionally, slices of humble pie, what also twinkled in were GitHub stars—all 300 of them from that post alone.

Those users also got into our Discord and engaged with us about new features, which turned into a conversational flywheel between them and existing users. Love, impatience, sometimes disappointment flowed through our Discord.

We doubled down on Reddit and continued to make those more upfront, readable, and engaging. The numbers showed us it was working.

Thanks to Ilya Lyamkin for the research, the screenshot, and the participation in a testy conversation.
What worked #5
  • Focusing on one channel before adding any other
  • Experimentation with formats, tones, and styles until we found our Reddit sweet spot
  • Direct access to a release on GitHub from its Reddit post
What didn’t #5
  • Talking about every bug or minor improvement
  • Excessive promotion or cross-posting

Coming off of our wins on Reddit, we added Twitter to the mix. Instead of just cross-posting from Reddit, we made our posts Twitter-native using threads copiously and adding to the regular product updates with community flexes like ↓.

Again, forgive the big words and cut straight to the heart of the share—40 countries. Which was nice.

Engagement per post was meh as you can see for yourself, but we knew from our Reddit experience Twitter gold was just around the corner. Even so, we started getting @mention alerts on Twitter and soon after that, on LinkedIn and Instagram. It wasn't fireworks, but it was a start. We could now measure our inbound interest in chunky percentages and a good 5% to 10% of our first wave of visitors strolled in from these mentions.

What worked #6
  • Always tagging contributors and other open-source projects
  • Linking metrics for releases when announcing them
  • Showing early previews of features in action, usually via a GIF
What didn’t #6
  • Automating tweets without careful, careful planning
  • Linking to our sites and resources a little too much without enough show-and-tell sometimes

Shooting for the stars

We still weren’t cooking with gas, though, so we started toying with the idea of making our first announcement—five months and seven releases from day 0.

Goal? Grow our total and daily active users by 50%. Tall order, we knew, but if you shoot for the stars, you maybe get to the stratosphere.

We brainstormed destinations and methods for our first ever announcement.

  • We could have reached out name publishers and journos who cover project management. The effort-to-probability-of-success ratio didn’t work in our favor back then.
  • We could have done it just on our site and distributed that on Reddit and Twitter. Sounded dumb.
  • At one point, sky-writing in San Francisco was proposed and weighed in on. Yep, seriously weighed in on. We dropped the idea like a hot potato when we saw what it would cost.

Tactic #5: Captive audiences

Until that point, I don’t think any of us had fully realized what had worked for us thus far, but in asking that question, we found the answer to be right in front of our eyes—working with communities. You, dear reader, probably got here much faster than us.

Vihar, my brother and co-founder, had experience working with techno-business publications on Medium. He started reaching out to those with the organic community and readership numbers to back their popularity. Our pitch was crafted to our strengths and aimed to make it attractive for Medium readers.

  • We had over 2K stars on GitHub at this time.
  • We had users calling us better than Jira, Monday, and Linear.
  • We were climbing engagements charts on Reddit and Twitter.

Of all those who replied with interest, we chose Better Programming for three reasons.

  • They had north of 200K subscribers.
  • Developers and technical audiences flock to them everyday.
  • Open source was a big theme for them.

They were also great collaborators for how to get the most eyeballs on our post and agreed to feature us on their home page.

Better Programming’s home page + Medium’s own distribution worked out pretty.

May the fourth was with us when we introduced Plane formally to the world in a post that is now our #1 source of traffic and is as strong a backlink as we could have hoped for then.

What worked #7
  • Strategic publisher and audience research
  • Enough breadcrumbs to the product, Docs, or the site
  • Lots of show-don’t-tell
What didn’t #7
  • Not planning for reviews and approvals
  • Going wide, not deep, with distribution
  • Almost-zero calls to action

Tactic #6: Hacking Hacker News

Hacker News, like Reddit, is frequented by discerning and vocal people who do not shy away from calling BS on, well, whatever’s BS. We had been lurkers on Hacker News, not contributors, but we knew we weren’t going to do more than just introduce ourselves. We were also not going to game upvotes so we could trend.

The first few times were a dud. In one particularly frustrating instance, maybe fourteen people saw the post, three upvoted, and one of them politely commented.

Our fifth try—yep, fifth—looked like ↓ and at the time it read, “Plane: Open source alternative to Atlassian’s Jira.”

We took off, largely riding on users complaining about how “crammy”, “janky’” and “sucky” Jira had become over the years and just how much room there was for a simpler, more intuitive, quickstart project management tool. For our part, we answered questions in near-real-time, talked about our roadmap, and discussed our vision for project management that desiloed goals, impact, and projects. The comments, the feedback, the banter were an eyeopener to the opportunity before us, but for now, we watched Plane soar on Hacker News.

We wonder if Atlassian saw this and cared at all. I would like to think they didn’t. 😛

What did it all end up in?

  • We trended on GitHub globally across categories. This is almost like trending globally on Twitter. There. I said it.
  • We got 7,000 GitHub stars from this one post. To put that in context, Hacker News was almost 3X more yieldy than all our previous efforts on Reddit and Twitter.
  • Big names on Twitter started talking about us.

Our GitHub page took a life of its own, getting hundreds of new users everyday over to The star growth was automatic and network effects, amongst other things like word-of-mouth, have kept us going past the 18K-mark.

What worked #8
  • Preparedness and timing
  • Experimenting with titles
  • Responding to questions with GitHub and Discord links
  • Consistent engagement — contributions to keep up the rank on hackernews page
  • Talking about the foundations— the tech stack, scale, performance and security.
  • Not taking potshots at competition
What didn’t #8
  • Engaging on off-topic competition and conversations
  • Defending the unavailability of features
  • Prioritising customer want vs customers want

Tactic #7: Crisis comms

Not so much crisis comms as much as defending our claims and our joy at topping a category.

I linked to a jibe at the beginning of this post, right around the 14K star mark, that's worth investigating. For those who missed it, it happened when we claimed the #1 popularity spot on GitHub.


  • An X user called our GitHub stars fake and likely paid for.
  • We responded with transparency about where they came from—you, our amazing, amazing community. 🙏🏾
  • Tweeps (Xeeps?) jumped in with research and data validating our claims. 🎉

A few things we took away from that episode.

  • We had broken an apparently significant ceiling.
  • Our authenticity garnered us support from the larger, non-Plane community.
  • We should have celebrated our differentiators and use cases Plane is good for, something we are still working on.
    I couldn’t be more thankful to Gergely Orosz who challenged us about our flexes and was kind enough to remove a tweet (xeet?) that we both agreed was suggestive.
What worked #9
  • Defending ourselves because we had a right to
  • Not soliciting defense from our users
  • Not treating it like, “Any publicity is good publicity”
What didn’t #9
  • Not showing proof in numbers
  • Being a little too brash about our defense
  • Being tone-deaf about differentiators and use cases

The path forward from here

Just the other day, I found this tweet from Prettier about a bounty they ran just so they can up their game. Note that the Prettier site runs off of Netlify. Guillermo Rauch doubled their original bounty. Guillermo is the chief at Vercel, a Netlify competitor.

Open source is wild country and the one sureshot way to stay top-of-mind here is an unrelenting commitment to open source, even from COSS start-ups like ours, scale-ups like Posthog, or whales like

Again, we are not the first and certainly not the fastest to get here. GitLab, MongoDB, and Snowflake have been-there-done-that for years. Alternatives to proprietary software like Supabase, a Firebase alternative, Medusa, a Shopify alternative, and NocoDB, an Airtable alternative are all upping the game for everyone, including other open source players.

We have been lucky a lot to have found early adopters, checked a few important boxes along the way, and stayed ears-to-the-ground with our community. Crossing 19K stars as of the writing of this post has been very motivating and it’s even led to a ROSS Index listing, but again, stars are just one metric.

Finding a path forward from GitHub stars to hard product metrics—adoption, retention, and referrals—that will spell a stronger PMF, especially when we launch pricing, will mean doubling down on everything we have done so far, experimenting with more—the idea of a bounty comes to mind 🙂—, and making your-feedback-is-our-roadmap our mantra.

So, we will go do just that. And we will talk about that, too. Stay tuned.

Join our Community of 6000+ Members.

Join the conversation, pitch your feature ideas, discover savvy solutions, and tap into the wisdom of a vibrant community of developers and Plane enthusiasts.

Questions? Comments? Concerns?
© 2023 Plane. All rights reserved.