1. 38

  2. 37

    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.

    1. 12

      For militant decentralisation, https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256 seems like a cool solution. No internet required.

      1. 1

        You can overwrite other people’s master branch with that?

        1. 3

          Don’t know, I’ve never used it. http://scuttlebot.io/apis/community/git-ssb.html#usage says “You can only push to SSB git repos that you created, not ones created by other users”, but I’m guessing there’s more to the story :)

          1. 3

            Only if they give you the key.

            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.

        2. 15

          My disagreements by section:

          • 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.

          1. 8

            Another GitHub aspect I dislike is that it turns into a “social coding” platform, where people “share much more than code”. It feels like a social network, and I do not want a git + facebook mix.

            1. 7

              Wow, I’ve not seen anything like it becoming facebookey. Do you have some examples on this?

              1. 13
                • automatic feed of what other users liked (on the home page while connected),
                • on-site notifications,
                • “like buttons” for projects (stars),
                • “react with emoji” buttons on comments,
                • emojis everywhere
                • rich user profile pages
                • follow users, projects

                It seems it only lacks the private messaging. There are already in-github-issue blogs.

                1. 13

                  I actually like the stars, which I use for bookmarking. I regularly get the latest releases of starred repositories with a script.

                  Not a fan of emojis though.

                  1. 3

                    Those darn subset of unicode!

                    1. 1

                      Thank you, this is useful. :)

                    2. 13

                      I consciously don’t reply to all, as much of it - IMHO - is very much up to taste.

                      automatic feed of what other users liked (on the home page while connected),

                      I know quite a few people using that for discovery.

                      on-site notifications,

                      I like them, because they don’t drop down my inbox. I use both them and the (really well implemented) emails.

                      “react with emoji” buttons on comments,

                      They are literally a wanted feature. Before having them, issues were full of people posting “+1”, “no”, etc., which trashed everyones email inbox.

                      It seems it only lacks the private messaging. There are already in-github-issue blogs.

                      Fun fact: they used to have that. It was killed off in… 2010something?

                      1. 3

                        much of it - IMHO - is very much up to taste

                        Yes. :-)

                        Most of these features happen to be convenient.

                        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.

                        1. 1

                          It was killed off in… 2010something?

                          Pretty close: April 2012. No-one wanted another inbox to check.

                          1. 1

                            Ah, the fork queue… good old times.

                        2. [Comment removed by author]

                          1. 1

                            You are right, we need these features. This makes the platform evolve as they are added, and makes using GitHub as a social network possible.

                            As long as it is possible to use GitHub without the “social” features in the way, then I have no problem with it. :)

                          2. 2

                            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?

                            1. 2

                              turn them off or ignore them

                              Yes, exactly. So this is no big trouble fortunately. I can mostly ignore the platform and work as if I got commits through e-mail an a mailing list.

                      2. 7

                        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.

                        1. 9

                          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…

                          1. 5

                            I thought they already were ;-)

                          2. 3

                            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.

                            1. 3

                              GitHub: De-Decentralized Git.

                              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.

                              1. 5

                                PRs are actually a feature of git, with review intended to take place on the project’s main discussion area (usually a mailing list, but could be anything)

                                1. 3

                                  PRs are actually a feature of git

                                  TIL!! https://git-scm.com/docs/git-request-pull

                              2. 1

                                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.

                                1. -5

                                  The fact that GitHub has turned into a SJW centered company does take into consideration how important a diversity of ideas is.

                                  I’ve read inquiries within GitHub comments of SJWs attempting to smear the reputation of developers who simply believe in different political viewpoints or ways of life.

                                  My ability to put up with trash talking SJWs within the Open Source community is running out quickly.

                                  1. 13

                                    (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.

                                    1. 5


                                      Would you be specific? What actions has Github the company taken that offend you? Whose reputation has been smeared?

                                      I nearly stopped reading your comment because inflammatory short-hand like this doesn’t carry much information about the subject but allows me to ascribe some information about you. Now I’m curious.