This is a good rant, but utterly fails to address the 900 pound gorilla in the room - funding. Open source does not run on magical rainbows farted by unicorns. It runs on money.

The Python community for instance has recently come to realize that the Python Package Repository it relies on extensively could easily run out of rocket fuel and crash, leading to some serious breakage across large swaths of the Python ecosystem.

In the case of PyPI, private companies, my employer among them, have chipped in to keep PyPI rolling, but what if that hadn’t happened? The entirety of Python-dom could have sank beneath the waves.

There are multiple solutions to this problem. One of them is, as github did, to start a for pay company to fund all the open source goodness.

Rage against the machine all you want, but at the end of the day if you’re not offering an alternative solution that scales to match, it’s just empty fist shaking.

Scuttlebot is built on SSB, which is a content-addressable (by Sha) distributed database, where all entries are signed by a private key, and your local replica only copies records published by a key it follows.

1.1 Github is centralized in US. People chose to put their software there–nothing keeping them from using another service. With git as the lingua franca of open-source, and Github as the public-facing archive, well yeah not using Github makes you look like a hermit. Similar things were said about not knowing English, German, Latin, Mandarin, and so forth at various times and places.

1.2 Github is proprietary as only as SaaS can be, also we have to use the bug tracker. Well, yes, the cloud is only somebody else’s computer after all–and using something other than the Github issue tracker is standard practice at various orgs (Bugzilla, Jira, etc.). If projects want, they can separate it out.

1.3 Github is becoming a standard workflow. I’ll grudgingly accept having standardized practices somewhere in our industry. It’s good for job mobility, it’s good for customers, it benefits everyone.

2.1.1 Github falls over occasionally. Uptime is hard…but it’s these folks doing it for free/cheap. Besides, you goobers, git is totally capable of offline mode. If you are worried about permanent unavailability, backups.

2.1.2 Stupid webshit is codependent, and doing it at Github. If free software folks don’t want to vendor their relevant deps and take care that those don’t bitrot or go offline, that’s their problem. The better example of Github doing nasty things isn’t npmgate, it’s what happened to the trolly “C plus equality” project.

2.2 Sourceforge did bad things. Spot on, same problems face Github.

2.3.1 Free Software supports different degrees of proprietary in software. Okay I guess? This section seemed kinda pointless to me.

2.3.2 Github supports non-resilient workflows. We don’t have to use their bug tracker, we don’t have to use their PR mechanisms, we don’t have to fork repos to do PRs, etc. None of this is Github’s fault–it’s developers purposefully deciding to do things in a way that isn’t futureproof.

2.4 Github’s growth made git a standard tool, but maybe we should reinvent wheels. This whole section is “we already have a good solution but what about the losers?”. If they didn’t suck they wouldn’t have lost–and in some use cases, they are still used. If people choose to use the easy tool, that isn’t the tool’s fault and the tool doesn’t owe anything to the things it beat out.

3 Free Software developers are..lazy, I guess? This is a problem with developers, not Github–which, for its part, has introduced fixes to most of the gripes in the letter referenced.

This whole rambling essay would’ve been better if it was about how Free Software proponents have lost their way and failed to deliver compelling alternatives to walled-gardens. As it is, it just seems to conjure to mind this sketch.

Maybe blurring the line with social networks is a side effect of trying to make collaboration better…

IIRC, they added emojis reaction to messages to prevent people putting “+1”-only messages to tell they are really eager to see a new feature implemented.

GitHub is a good answer to what people ask, and I am OK with what people ask for. I do not ask the same thing (just GIT server + gitweb or alike) but still have an account as I find all I need with GitHub, and it is required to comment on issues.

Those things don’t annoy me, I actually like to know if someone follows me, it’s good for my ego. I don’t have any crazy big projects though, may after a certain point the notifications become too frequent? I’m sure you can turn them off or ignore them though?

On the one hand, I like encouraging diversity, and have intermittently either used Bitbucket or run my own hosting tool. But on the other hand, I really don’t think this is the kind of lock lock-in threat I’d normally be worried about. The repositories themselves are trivial to move off with full history, and there are honestly even tools that can bring over PRs, issues, and so on. (Gitea, for example, can automatically mirror full GitHub projects.) This isn’t the first time we’ve had this kind of issue, either; shops I’ve been in the past, we’ve had NuGet/PyPI/Bintray mirrors we kept locally to protect upstream explosions, and those all have turnkey replacements.

If you want to worry about something more concrete, I’d be keeping a closer eye on things like Gitter/Slack/Travis that are much harder to quickly move off, and borderline impossible to move off while maintaining full history.

I think this started sliding off the rails when suggesting that it’s a bad thing for someone to switch jobs and still be familiar with the tools in use. Even if you use plain git, it’ll be uniform. Maybe every time you install git the command line arguments can be randomized? Maybe even an improvement…

I try not to post negative things on this site, but I’m a bit confused as to why this post has so many upvotes, so I’ll try to write a rebuttal. I think this is a (mostly) absurd post.

Today many dependency maintenance tools, as npm for javascript, Bundler for Ruby or even pip for Python can access an application source code directly from Github. Free Software projects getting more and more linked and codependents, if one component is down, all the developing process stop.

Firstly, even if those package managers were to remove GitHub support today, the alternative is putting things in the public gem server or into npmjs.com itself, which still creates a central point of failure. The points about “legal demands” to GitHub apply just as readily to the actual npm and rubygems servers, and what’s more, it seems incredibly unlikely a company will attempt to DMCA something like leftpad. And even if they do, which again, could happen to any of the possible code sources that these package managers support, it’s obnoxious but also trivial to repoint dependencies to a code server.

It’s true, as the author lists in 2.1.1, GitHub does end up being a larger target for DDOS attacks, since an outage could affect more package managers. However, considering they also make substantial profits unlike most package manager websites, I’d argue this gives them more than enough resources to defend themselves from this increased risk. GitHub has withstood DDOS attacks at a nation-level scale from the Chinese government. Would you trust Rubygems to do the same?

Those on the side of the viral Free Software will have trouble to use a proprietary software as this last one shouldn’t even exist.

Section 2.3.1 repeatedly mentions that GitHub isn’t Free Software, but doesn’t actually list any reason why this is bad. Nobody is forcing GPL projects to move their projects to GitHub. I’d also argue that thanks to its lightweight nature, migrating away from GitHub if you find they are “endangering privacy, corrupting for profit our uses and restrain our freedom” is not terribly difficult.

Very popular, it grew fast until it was closed overnight, with only a few weeks for its users to extract their data. It was only a to-do list. The same situation with Github would be tremendously difficult to manage for several projects if they even have the ability to deal with it.

This is a issues-to-CSV export script, and this shows how easy exporting a PR to a diff or patch file is. Exporting all of this is completely trivial, and considering how many thousands of programmers are on this website, even in the event where users had only “two weeks” to migrate away their data (already an absurd and unrealistic situation) there would be plenty of tools to do so.

A new Free Software project is now a Git repository on Github with README.md added as a quick description. All the other solutions are ostracized? How?

I think this is the one fair point of the entire article that I agree with. I think it’s indisputable open source projects are more popular if they’re hosted on GitHub. That said — with the sheer number of open source projects that one must use today, it’s absurd to expect users to create new accounts and learn new tools for every single project that they use.

I think people with strong feelings towards proprietary software can completely sidestep the “Github threat” by using Git as it was intended—in a decentralized manner.

That said, I think the market would respond positively to a privately funded centralized version control system. I would imagine GitHub’s PRs/Reviews/Issues/etc baked in at the SCM level would be a success.

It seems very difficult now to encourage potential contributors into learning a new source control manager AND a new forge for every project they want to contribute. Which was a basic requirement a few years ago.

Are we really trying to return to that time? It was frustrating and confusing to download open-source projects from SF let alone actually contribute back to them. It’s easy to correlate the explosion in open-source interest and development, especially by companies, to GitHub’s initial hockey-stick growth of users.

(in 2 years, this is the only comment of yours that you haven’t deleted? Seriously?)

Unless you’re going to back up your accusations with links to things, calling them “facts” is rubbish. “SJW” as a blanket term is pretty bankrupt, so you have to be more specific about what policies you are disliking. Also, please learn how to hyphenate.