You hit 50 stars, wrote the post, got some nice comments. Now you are at 100 and the draft in front of you is the same post with a bigger number. The problem is not that open source milestone posts are boring. The problem is that the easy version of the second one reports the number again instead of the change.
This post gives you a simple rule for the next one and a template you can copy.
The best milestone posts say out loud that they won't repeat themselves
A good recent example is nyaomaru's "is-kit Reached 100 Stars ⭐🎉 Here's What Changed Since 50" on dev.to, which showed 45 comments on 13 November 2026. Near the top the author writes: "I could write the same story again. But that would be boring." and then sets a different job for the post.
Look at the section headings and you will see what that job is:
- what 50 stars meant (one short look back, not a retelling)
- a new use case that became first-class
- an API that "got much more serious"
- the library becoming stricter
- the author using it in their other projects
- a guard that ran into a type bug in Effect
- what 100 stars means now
Almost every heading is a change. The number gets its own section at the start and at the end; the sections in between are about what changed.
The strongest section is the bug. A refinement from the library hit an edge case in Effect's types, and the fix went upstream into Effect itself. The author's line about it is the reason the whole post works: "That is exactly the kind of edge case that appears when libraries start meeting each other in real code." A star count can't tell a reader that your library now gets used next to other libraries. A bug report can.
Why the number is the weakest part of your post
GitHub's own docs describe a star as two things: a bookmark ("Starring makes it easy to find a repository or topic again later") and a thank-you ("shows appreciation to the repository maintainer for their work"). Neither tells a reader whether your project got better.
Stars do matter for discovery, since "many of GitHub's repository rankings depend on the number of stars a repository has". That's exactly why the number is tempting as a headline. But your reader already saw it on the repo page. What they can't see there is:
- which APIs changed, and why
- which design call you reversed
- what a real user hit that you didn't expect
- what is harder now, on purpose
Another dev.to post, "From 0 to 1,000 GitHub Stars in 10 Weeks: What Actually Worked", has the same strength even though the title leads with the number. Two of its headings are decisions ("Ship fast, ship broken", "Build an extension point early"), and its best line is about users, not stars: the community added Redis, ClickHouse, CSV and a Hacker News plugin, and "It turned users into builders."
A template for your next open source milestone post
Copy this, delete the lines you have nothing real for, and don't pad the rest.
# <project> reached <N> stars. Here's what changed since <last milestone> ## Last time, in one paragraph What the last post said, so readers can skip it. ## What changed in the code - New API / feature, and the problem it answers - Something you made stricter or removed, and why ## What real usage taught you - A bug or edge case someone hit (link the issue or PR) - Where the project now runs that you didn't plan for ## What is still missing One honest gap, and whether you want help with it. ## What <N> means to you Two or three lines. This is the only place the number gets to be the point. Three checks before you publish:
- Delete every sentence that was also true at the last milestone. If it was true then, it was in the last post.
- Link the evidence. An issue, a PR, a changelog entry. The is-kit post can point to the upstream fix; that link does more than any number.
- End on the reader. Near the end, the is-kit post says "the goal was never to build a library that only looks nice in its own README". That line is about people using the code, which is the thing your readers care about.
FAQ
Should I still put the star count in the title?
It's fine as a hook, both example posts do it. Just don't let it be the content.
What if nothing big changed between milestones?
Then write a short post, or skip it. A small honest delta beats a long rerun.
Is it okay to thank people by name?
Yes, and link what they did (issue, PR, plugin). That is a change worth reporting.
Where do I post it?
Wherever your users already read. On dev.to, tags like #opensource and #showdev fit.
What did you change since your last milestone that a star count would never show? Tell us in the comments.
Disclosure: this post comes from the Mantis team account, published under the Stickly organization; Stickly is built by our founder, Tarun Kumar. It's an engagement widget that lets SaaS founders reward their own users with product credits for in-product actions such as onboarding steps, invites and feedback. If that's useful to you, it's at stickly.live.
