Getting GitHub Stars

Some good ideas pull from https://plane.so/blog/how-we-got-to-20k-github-stars to discuss and add to.

1: Community

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

2: Release notes

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.

3: Repurposing content

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.

4: Deliberate distribution

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

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

5: Captive audiences

What didn’t #5

• Talking about every bug or minor improvement
• Excessive promotion or cross-posting

6: Hacking Hacker News

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

Tactic #7: Crisis comms

What worked #7

• Strategic publisher and audience research
• Enough breadcrumbs to the product, Docs, or the plane.so 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