DEV Community

Cover image for How we lost 54k GitHub stars
Jakub Roztocil for HTTPie

Posted on • Originally published at httpie.io

How we lost 54k GitHub stars

Gaining 54k GitHub stars

HTTPie for Terminal is celebrating 10 years since the first commit.

If you’re unfamiliar with the project, it’s an open-source CLI HTTP client. What makes HTTPie different is that we build it from the ground up to make API interaction from the terminal as human-friendly as possible.

Starting with the first public release, published on the 25th of February 2012 from a rainy Copenhagen, we’ve hosted the project on GitHub.

I’ve been a GitHub fan ever since I became a member a couple of years earlier (the type that wears Octocat-decorated t-shirts, no less). It was back in the day when GitHub’s about page proudly proclaimed they took $0.00 in VC funding and informed you about the number of delicious beers on tap in their SF office.

So GitHub was an obvious choice when I realized that the result of scratching my own API testing itch might be of interest to the wider developer community. And of interest it was.

I remember the rush of HTTPie becoming the top link on Hacker News for the first time and seeing the GitHub community build up. Over the years as we continued to improve the project it kept attracting widespread adoption. It became the most popular API tool on the platform, and the GitHub community grew to 54k stargazers and 1k+ watchers.

stars

There are 289M public repos so HTTPie was among the top 80 most popular public repos on GitHub overall; in the 99.99997203 percentile. In short, It was incredible to see this humble tool attract a community of that magnitude. And GitHub played an important role in that.

In the same way that we benefited from GitHub’s “social coding” features, GitHub benefited from our hosting this popular project on their platform. Over the past decade, possibly millions of developers visited our GitHub page. That’s helped reinforce GitHub (Microsoft) as a company that cares about open source and community. It was a symbiotic relationship.

Losing 54k GitHub stars

However, if you are one of our 55k stargazers and watchers, as of a few weeks ago you no longer are 💔

What happened?

Due to an unfortunate sequence of events, I accidentally made the project’s repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build.

stars2

What does it mean?

If you’re a downstream maintainer or anyone previously watching httpie/httpie for notifications, for example, you’ll need to re-watch the repo. Incidentally, we’ve recently published a security release.

The same goes for stars. If you’re one of those 54K people who’ve starred the repo any time in the past decade, the repo is no longer among your starred projects.

Why did you make the repo private‽

It’s a peculiarity of GitHub, to put it mildly, that making a repo private permanently deletes all watchers and stars. I was even aware of this, and I obviously had no intention to make httpie/httpie private. So, why then?

visibility

The proximate cause was that I thought I was inside a different repo; one with no content and zero stars. What I actually intended to do was to hide the HTTPie organization’s profile README, which I had created the week before but had no opportunity to populate.

What put me on the wrong path was an otherwise completely unrelated action: I had just done the same (i.e., hidden an empty README) on my personal profile by making jakubroztocil/jakubroztocil private.

GitHub’s conceptual model treats users and organizations as very similar entities when it comes to profiles and repos. In this context, and since I just wanted to repeat the same benign action on our organization’s profile, my brain switched to auto-pilot mode.

I didn’t realize at the moment there’s an inconsistency in the naming of this special repo containing profile READMEs and that it differs for users and organizations: name/name vs. name/.github.

That’s why I proceeded to make httpie/httpie private instead of httpie/.github without realizing my mistake.

But there’s a confirmation, right‽

There’s a confirmation box. It’s designed to stop users in a situation like mine from doing something stupid. It tells you that “You will permanently lose all stars and watchers of this repository.” That’s pretty scary.

The problem is that the box looks exactly the same for repos with no commits and stars and for repos with a decade-long history and 55k stargazers and watchers. And it says “Warning: this is a potentially destructive action.”

To paraphrase, the box tells you “You’re about to demolish a house. If there are any people inside, they will all die”.

But it doesn’t include anything specific to break you out of your auto-pilot mode if you’ve confused the address and think you’re looking at an empty house.

A 54k-star question: Which one of these two dialogs is safe to confirm and which one deletes a 10-year-old community?

confirm

The dialog should be more contextual and, paraphrasing again, it should say “You’re about to kill 55,000 people.” That would’ve certainly made me pause.

So you made it private, just flip the switch!

You can imagine my confusion when I went back to the organization page and not only could I still see the empty README but our most popular repo was nowhere to be found. After a moment I realized what happened. So I went back to the repo’s settings to flip the switch. But GitHub didn’t allow me to do that—for an entire half an hour.

delete

If you’re wondering why so long, it’s because 🥁 that’s how long it took GitHub to cascade-delete our decade of stargazers and watchers. And there was no way to stop the process. All I could do was start writing to GitHub support, refresh the page and wait for the number of stars to reach zero before I could make it public again.

Why doesn’t GitHub restore it‽

GitHub obviously has backups. And it is indeed possible to undo the damage done by accidentally making a repo private. The GitHub team themselves accidentally made the GitHub Desktop app repo private once. And they restored everything for themselves within hours. Here’s the former GitHub CEO explaining the situation:

tweet

In our case, however, they refuse to do that, citing undesirable side effects and the cost of resources. We even offered GitHub financial compensation for any resources required. But, sadly, they declined. They have other priorities than resurrecting the community of one of the oldest and most popular community projects on their platform.

So the answer to the question is, unfortunately, the following: GitHub will restore a repo damaged by making it private. But only if it’s one of their own projects, not a community one. The latter gets a tweet, at best.

Lessons learned

One should never let a good crisis go to waste. Our options are limited, but there are at least a few lessons learned that might be valuable to share.

Lesson #1: UI/UX design

Show, don’t tell. Design confirmation dialogs in a don’t-make-me-think fashion. When the user is about to destroy something, don’t describe that as a potential scenario in abstract words that the user needs to convert to mental images and put values on. Especially when cascade-deleting as a side effect of the primary action. For example, here’s how we approach that in HTTPie for Desktop:

delete2

And, of course, the dialog should reflect the severity of the side-effect. It should be quiet when there are no side effects at all. Otherwise, we risk desensitizing the user by wasting their limited attention capital:

delete3

Lesson #2: Database design

Use soft-deletes. People are human and they make mistakes. For hard-deletes, delay the process.

soft

Lesson #3: Relationship with GitHub

It was a human error on our side and GitHub made it clear they’re not legally obliged to help us. The tone of our decade-long mutually-beneficial relationship is set by GitHub’s Terms of Service. Thinking there was more to it was naive.

After all, GitHub has a history of taking controversial actions that go against the spirit of open source and community and then reverting them only based on public outrage. And Microsoft (which now owns GitHub), despite its newly-found affection for open source, has not always had exactly a great reputation.

What’s next?

We continue to hope GitHub/Microsoft change their machine-like attitude and restore the project’s community one day. They still have all the data and the means to do that. We also hope they improve the UI and database design to prevent this from happening to other teams in the future.

In the meantime, you can help us by sharing this story and re-watching/starring the repo.

As for me, I will probably take a break from wearing Octocat-decorated t-shirts.

Epilogue

Despite our GitHub stars turning into dust, HTTPie has never been doing better. What started as a side project has recently become a company and our team is growing HTTPie into an API development platform (one as delightful as you’d expect from HTTPie). The private beta of HTTPie for Web & Desktop has been receiving great feedback, and we cannot wait to launch it to the public in the upcoming weeks.

If you’d like to stay up-to-date, you can join our Discord community or follow @httpie.


Originally published on HTTPie blog.

Discussion (12)

Collapse
benjaminwolkchen profile image
Benjamin • Edited on

That sucks. I know it's difficult for big projects, but maybe it is time to consider using alternative - more humane - code hosting services. For example, Codeberg, which is a community focused non-profit.

Or, maybe self-host. GitLab and Gitea have come a long way. It's time to stop relying on commercial entities to host your free code.

Collapse
grantholle profile image
Grant

That's a bummer, but it'll be all right. Your commit history, issues and PR's are all there still. People equate "stars" with "likes", but I think that's actually not its purpose (or original purpose). It's like a bookmark for you to easily find it later under your profile. It's sad to me that people equate it with popularity and ask people to star it, as if it gives it a better reputation.

OSS maintainers asking for stars has sort of become YouTube creators asking, "Be sure to slap that like button and subscribe. Hit that bell to be notified of new videos!"

You've built a small empire and done something very few have been able to do. Keep building and you'll get the attention you deserve. Don't sweat the stars. You're already a star in our hearts

Collapse
robole profile image
Rob OLeary • Edited on

Nice writeup. Its a bummer when something like this happens. It looks like you are back to 12.5k stars, so you bounced back quite well!

Maybe, its a sign to change to another host in the long-run...

Collapse
zerolife profile image
Andrew Abraham

Man, that sucks. I could only imagine how long those 30 minutes must have felt watching the stars disintegrate before you.

Glad to see the project is already back up to over 12k stars.
Its a great tool, especially for people who like to live in the terminal...

Collapse
sinewalker profile image
Mike Lockhart

These are great points about the UI for destructive changes. I've created an issue for the GitLab dev team, to surface project and group details when making access changes. In GitLab's case, flipping a project private/public doesn't lose the stars: the project just becomes invisible, and not listed in the users' Starred projects tab until it's made public again.

But for destructive actions the GitLab UI doesn't offer any confirmation or information about potential impacts either. For instance under GitLab's Advanced project settings there are options to Archive, Transfer, or Delete, but with only general warnings, nothing to say "X project members and Y stars will be impacted", or for a Group "X public projects in this group will be made private by the new group's settings" (equally risky would be private projects made public by accident).

Collapse
moopet profile image
Ben Sinclair

I think you're right in everything except thinking that Github should be more helpful to you since you were a higher-profile project.

It should be a better interface for everyone - I can imagine the same situation where you sent them an email and they replied "ok", and fixed it for you but made some kind of time-and-effort value judgement where they wouldn't do the same for other projects. That's a corporate cloud distopia.

Collapse
iamrommel profile image
Rommel C. Manalo

I tweet this long time ago, that everything that Microsoft touches turns to shit. Its like "Hands of Midas" but in opposite way.

Collapse
eolivarese profile image
Ernesto Olivares

Same thing happened to me in Aws. I deleted an entire ECS cluster instead a service because two delete buttons were in the same page.

Collapse
gktim profile image
gkTim

Didn’t know the project before this post. Nice tool! Good Post! Gave a Star. Continue the good work. Thx for your effort!

Collapse
ismaestro profile image
Ismael Ramos • Edited on

@jakubroztocil @sinewalker @moopet is it me, or github implemented your solution because of this?

screenshot

Collapse
hseritt profile image
Harlin Seritt

Fuck github. Looking for an alternative now.

Collapse
tnir profile image
T "@tnir" N

But it is the better than others. Any alternative you prefer?