How we lost 54k GitHub stars

Gaining 54k GitHub stars

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

If youre unfamiliar with the project, its 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, weve hosted the project on GitHub.

Ive 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 GitHubs 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 GitHubs 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. Thats 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 projects repository private for a moment. And GitHub cascade-deleted our community that took 10 years to build.

What does it mean?

If youre a downstream maintainer or anyone previously watching httpie/httpie for notifications, for example, youll need to re-watch the repo. Incidentally, weve recently published a security release.

The same goes for stars. If youre one of those 54K people whove 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

Its 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 organizations 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.

GitHubs 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 organizations profile, my brain switched to auto-pilot mode.

I didnt realize at the moment theres 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.

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

But theres a confirmation, right

Theres a confirmation box. Its 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. Thats 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 Youre about to demolish a house. If there are any people inside, they will all die.

But it doesnt include anything specific to break you out of your auto-pilot mode if youve confused the address and think youre 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 Youre about to kill 55,000 people. That wouldve 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 repos settings to flip the switch. But GitHub didnt allow me to do thatfor an entire half an hour.

If youre wondering why so long, its because thats 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 doesnt 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. Heres 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 its 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, dont tell. Design confirmation dialogs in a dont-make-me-think fashion. When the user is about to destroy something, dont 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, heres 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 theyre not legally obliged to help us. The tone of our decade-long mutually-beneficial relationship is set by GitHubs 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.

Whats next?

We continue to hope GitHub/Microsoft change their machine-like attitude and restore the projects 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 youd 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 youd like to stay up-to-date, you can join our Discord community or follow @httpie.

Originally published on HTTPie blog.