Remember that sinking feeling when you opened star-history.com and saw the error? The tool that helped you judge every open-source project at a glance was dying. GitHub had deprecated the API it relied on. The panic was real. Developers everywhere felt the ground shift.
But then, almost as quickly, a new version appeared. star-history.dera.page. The same charts, the same data. Relief washed over the community. “We’re saved!” But here’s the truth: that revival isn’t a continuation. It’s a workaround. And it’s a wake-up call.
Every tool you love that runs on someone else’s API is a rental, not a possession.
GitHub made stars culturally important. They became the quick trust signal for every open-source library. Then GitHub quietly restricted the easy way to track their history. The original project posted a blog explaining it could no longer function. The new project found a constrained path—a hack. It’s not the same as before. It’s living on borrowed land.
If you build a tool on GitHub’s API, your tool’s existence depends on GitHub’s generosity. And generosity in tech is always one deprecation notice away from being revoked.
The star-history.com team didn’t fail. They got evicted. The new project didn’t restore what was lost—they just found a back door. Stop treating platform APIs as infrastructure. They’re not. They’re privileges.
Think about your own workflow. How many tools do you rely on that are essentially scrapers or wrappers around someone else’s API? Every one of them is a ticking time bomb. The moment the platform decides to lock down, your tool dies. No amount of community enthusiasm can code around a policy decision.
The real story isn’t about a tool going down. It’s about the entire open-source ecosystem’s dependency on closed platforms. We cheer for ‘revivals’ while ignoring the fact that the original tool was never truly ours.
Next time you rely on a tool that sits on someone else’s API, ask yourself: Can this be revived, or is it just a workaround waiting to break? Because the day you can’t star-history a repository is the day you realize you never really owned anything.
FAQ
Q: Isn't the revival proof that the community can adapt?
A: Adaptation is fine, but it's a band-aid. The underlying dependency remains. The workaround is more fragile and could break again. The real fix is to build on open protocols, not proprietary APIs.
Q: What should I do differently?
A: Before adopting a tool, check its dependencies. If it relies on a single platform's API, assume it could break. Have backup plans, and support tools that use open standards or self-hosted options.
Q: Why is this a big deal? APIs change all the time.
A: True, but the difference is that GitHub deliberately made stars a trust signal, then restricted access to that history. It's not a technical limitation; it's a policy decision. That's a power imbalance you can't code around.