How we lost 54k GitHub stars

This content originally appeared on DEV Community and was authored by Jakub Roztocil

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.

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.

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?

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?

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.

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:

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:

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:

Lesson #2: Database design

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

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.

This content originally appeared on DEV Community and was authored by Jakub Roztocil