1. 21

  2. 28

    I don’t quite know where to start with this article. In general, I agree with the sentiment that we should be promoting more competition to the increasing default choice of “GitHub or GitLab”. And there are some good options appearing!

    But at the same time, part of my job is giving developers in a company the tools they need and versions of those tools that they enjoy using: and I think we need to accept that GitHub has been winning out because it offers UI and workflow advantages that other options have traditionally not. Likewise, because GitLab is also called out in the article: GitLab has been a good alternative because the team took lessons from what GitHub offered and put their own spin on it.

    I know that some people don’t like the PR workflow that GitHub pushes, and I’m keen to entertain arguments for and against. We should have that discussion and I know members of the lobste.rs community have some Opinions on this :)

    But my issue with this article (and the reason I’m writing a long, barely focused rant) is that I don’t think this article offers any real arguments. The binary choice of Git{Hub,Lab} is a straw man in this piece and, for me at least, hard-to-quantify statements like “we have lost our soul” aren’t enough to knock it down.

    1. 6

      Right. The basic premise of the article is a fine hill, but there are externalities when it comes to entry-level, collaborative development that are harder elsewhere then in social systems like GitHub and GitLab.

    2. 21

      A mostly-imaginary threshold. It’s in your head. Think about it.. those with skills & time, who can wholesomely contribute, will highly likely to already have email and perhaps XMPP (Movim) or IRC.

      Dismissing someone else’s reasoning as being based on an imaginary threshold and then responding with an imaginary counterproposal? This is all so wishy-washy and ignores real psychology (people have activation energies; barriers to contribution aren’t binary, the easier you make contributing the more likely you will get any/more contributions) in favour of ideological thinking.

      No-one (here, at least) is jumping up and down saying using GitHub has no downsides, but this essay thoroughly ignores reality.

      1. 4

        Exactly. The article says:

        If one wishes to participate in a project, really, truly, wishing to participate, the buttons will not be a barrier. In fact, from my brief time on Github and Gitlab, all I can attribute to the glossy interfaces was the drive-by comments, without any follow-through or interaction. So it’s a good filter rather than a bad barrier.

        No one starts as an active contributor to a project. They are a bit interested and then they file an issue. If they see good engagement, they will transition to a more active role. This paragraph tells me that this person is probably not great at engaging people in issue discussions so, yes, he’s filtering out a load of people but he’s probably the reason that they don’t become engaged contributors.

        From my personal experience, as someone who hates the idea of centralised platforms and resisted GitHub for a long time, projects that I’ve moved to GitHub have seen a steady trickle of new contributors who go from issue report to small PR to substantial PR (and, when I’m really lucky, take over as maintainer and let me go and work on something else).

        1. 3

          That’s my experience also. People don’t just up and decide your project is worth hours of their time; they’ll dip a toe in first and feel out what participating in your project is like first-hand.

          Similarly, for all the people who are saying that they don’t like or use or care about its “social networking” features — when a prospective new user (and future contributor or maintainer!) is searching for a library to use in some situation, they’ll look at the one with one stale issue and three stars, and the one with tens to hundreds of ongoing issues and PRs and stars, and decide which one’s worth their precious time accordingly. It’s not about an ego-stoking popularity contest, it’s just a good indicator of project health.

      2. 10

        What about us who just want a simple, convenient place to stash our random code and blog entries?

        1. 5

          You don’t need anything more than git for that.

          1. 10

            Sure, but self-hosting git doesn’t give me backups, or a web front-end, or easy links to random code snippets I’ve written.

            A Github profile is almost de rigeur when asking for an invite on this site.

            Github provides a lot of value. It’s why it’s popular.

            1. 3

              self-hosting git doesn’t give me backups

              If you’re talking about self-hosting on a server and pushing there (as opposed to just a local repo), then you kind of have backups, since you already have two copies of your code/posts, each on a different machine. I’d similarly count GitHub as a single copy, regardless of their own backups. If you’re talking about a local repo, then it should be backed up with all the other data on your computer… as long as you backup your computer drive. :)

              web front-end, or easy links to random code snippets I’ve written

              That’s a legitimate point, if you appreciate the front-end and prefer it to cgit, which is a matter of personal opinion.

              1. 13

                Yeah. I don’t want to be a sysadmin just to host some code.

        2. 9

          I think the big unmentioned aspect is the fact that it’s a social network. Network effects are real and significant for collaborative systems. It takes time to learn GitLab, sourcehut et al and this imposes switching costs that keep people wherever they are - “source gravity” as a form of “data gravity”. GitHub also pays a growing number of developers rent (I’m on the payroll). But I don’t host anything of a private nature on GitHub, and I’ve worked on GH alternatives because I ultimately see collaborative systems that pay people as the beginnings of a two-sided market that may further commoditize engineering labor and result in a monopsony or oligopsony where everyone works for a small number of platforms that strip workers of their individual qualities in a bid to drive their compensation into the ground. This is a real systemic threat and we need to be wary of things that seem like they could further undermine our labor security.

          1. 7

            Network effects are real and significant for collaborative systems.

            The takeaway for me is that since git is distributed, it’s easy to accept contributions from GitHub users via a mirror while keeping the canonical repo somewhere better.

            Since moving the Fennel programming language off GitHub we’ve gotten a few issue reports and patches thru the GitHub mirror we left up, but honestly the majority of new contributors (granted the sample size here is very small; maybe 3 of 5) have preferred to use SourceHut.

            1. 5

              If we’re talking company or project context, I am not buying the social network thing.

              I know so many people who don’t use stars, don’t follow people, don’t fiddle with their “profile page” - they just enjoy? or at least use it host git repos, participate in discussions in issues and maybe use the wiki. That’s what you do with every other code hosting platform as well. I use it just like our local GitLab at work. 0% like a social network.

              The only thing that is really nice that you don’t need a 67th account somewhere, you can just participate

              1. 2

                That’s fine that you don’t use it that way, but unless you don’t use open source code at work, you are still significantly influenced by the network effects from those who are. The fact is, a lot of software only becomes popular due to its discoverability, which the GH network can significantly amplify. Software that becomes popular is often the software that receives more contribution over time, and the fact that it became popular significantly increases the chances that you, someone who does not discover it in this way, will discover it nevertheless indirectly through someone who did.

                1. 2

                  I still disagree. I don’t discover stuff on Github, I discover stuff in package repositories or via word of mouth, or blog posts. Now you could argue that SOMEONE down the line will discover it on Github, that is true, but it worked fine before Github with Sourceforge and Freshmeat and what not, so I concede your point that it must be discovered to be used, but the “social network” is only one method of discoverability and if a project is hosted elsewhere than Github it doesn’t mean its not discoverable.

                  1. 4

                    Wow, you and I have very different experiences. When my coworkers are looking for software, libraries, whatever, their search often starts and ends with Github. If it’s not at least mirrored on Github, they won’t find it at all.

                    1. 3

                      Sourceforge, Freshmeat, the campfire in a cave where a group huddled around, the lump of mold on a fruit, etc… are all information networks with propagation proportional to the userbase. You can start your own, and new ones will replace the previous hubs eventually, but there are significant trade-offs that will be made. The trade-offs may appeal to some subset that may grow or shrink over time, but to reject any network at all will result in the end of the family tree for any organism that requires others to reproduce. Such isolation surely brings some people peace, but for an article posted on the internet of all places to claim that we don’t need (big network) seems a bit ironic to me.

              2. 5

                TLDR - real contributors will contribute anyways, continuous integration is a harmful distraction, GitHub is the Facebook/Twitter of VCS.

                1. 5

                  The underestimated aspect here is that GitHub is a social network. Projects get social proof from stars. People may say they don’t care, but their lizard brains will react to popularity.

                  1. 1

                    I’m sorry to disappoint you here, but I just opened a random repo on Github that I had in my history and I spent nearly 10 seconds scanning the page for where the stars are displayed.

                    I usually go by number of contributors, last changed, total amount of commits, and then amount of issues and how they’re being handled. Stars don’t factor in this at all.

                    1. 1

                      Stars don’t factor in this at all.

                      They absolutely do to me! The fact that some single-maintainer projects get hundreds or thousands suggests many people do know where they are and use them for one purpose or another. Perhaps the takeaway is that huge networks are used in many different ways by different people.

                  2. 5

                    If one wishes to participate in a project, really, truly, wishing to participate, the buttons will not be a barrier.

                    When I just want to submit a minor patch for a problem I discovered, the whole process with a modern npm package hosted on Github takes 20 minutes from encountering a problem to submitting the pull request. I don’t “relly, trully” wish to participate in your project, but I can do a small enhancement if you let me. But if you prefer to gatekeep based on messengers I use, I’d really rather spend those 20 minutes elsewhere.

                    1. 4

                      Personally, I’d rather quickly email a minor patch rather than have to sign up to a Microsoft product in order to do so.

                      1. 8

                        I first began contributing to open-source projects in the early 2000s. It was never as simple as “quickly email a minor patch”. Lots of projects even then were on Sourceforge, or had Bugzilla instances or whatever and required you to sign up for an account, figure out the workflow for filing a new bug or feature request, how to generate and correctly format and attach the patch to meet the project’s standards, etc. etc.

                        And you’d have to endlessly follow up to make sure someone actually looked at it, find out the status, respond to any comments they made… I had a minor patch (literally just tweaking a dialog) that I submitted to GNOME in, I think, 2005 that bounced around multiple different bug trackers and required me to keep creating new accounts and figuring out the new place to follow it for years afterward.

                        Like it or not, GitHub and its competitors in that space today are a breath of fresh air compared to how things used to be, and that’s why they’ve become so popular and centralized so much of the open-source world onto their platforms.

                        1. 3

                          Will this email go through the CI pipeline in the next minute? Will you have a ready email template that maintainer created to help you through the bug report and PR process?

                          Or you will have to dig into their specific workflow, register to a couple of mailing list and go through the whole initiation process as if you’re really going to become one of the maintainers of this project?

                      2. 5

                        No true contributor will abandon the process after I put up all these roadblocks

                        1. 5

                          A number of commenters here keep focussing on stars. When we talk about network effect in this context, GitHub’s dependency graph and corresponding features in search and security are more relevant. GitHub’s popularity and utility go beyond shiny social media buttons (or CI for that matter).

                          1. 3

                            About CI:

                            This is not the answer you are looking for. I never bought into this and still stand by it.

                            Perhaps you don’t need Github CI, but in a company you’ll often need some kind of CI. Like Jenkins. It’s invaluable to have one place to look for build artefacts, this including binaries and symbol files. Now there is this one place that I can go to each time I get a coredump, to grab symbol files required to decode the addresses. It’s also this one place that keeps track of build numbers, tags the last commit used in the build, so that you can now always go back to this point and confirm what fixes were included (you could of course log the commit hash, but build number is more human-friendly).

                            Another matter is automatically verifying that no changes pushed to master break builds. That will usually be done by Gerrit combined with some other tool, but I’d say it still counts as CI. $PreviousJob had no code review and no automatic checking that builds succeed — it was painful.

                            1. 3

                              I agree with the sentiment that Github has become a social network, even more, people starting to use stars as a way of measuring the technical level of a given project, when in reality it only measures popularity.

                              That being said, GH does offer a single place where you can look for projects in a given language, samples of code, configurations, etc. This is only possible because it is centralized. I’ve even been using GH code search (which is not great in any way) when I need to deal with poorly documented APIs.

                              From a personal PoV, it is something that I don’t need to maintain myself. I can just use it and push my code there. Even Github Actions (the CI part) has become popular because it is just built-in into the service. It takes a few lines of YAML to go from 0 to running static analysis tools, checkers, and others in my PRs/commits. The funny part is that I enjoy these “benefits” on a personal, it is not just for less technical contributors, it’s mostly for me.

                              Can all of this be replicated outside of Github? Definitively possible, projects like drone.io, Gitlab, buildkite, phabricator, gitea, gogs.io, Jenkins, and many others make it possible. But it is just a lot less convenient game not having to host/maintain all of this.

                              1. 3

                                GH does offer a single place where you can look for projects in a given language

                                I’m the lead developer of the Fennel programming language.

                                Most Fennel projects are not found on GitHub, because GitHub does not syntax-highlight them correctly. GitHub are not interested in adding this, because they require a certain number of projects to be hosted on GitHub before they will consider adding syntax highlighting.

                                However, the lack of syntax highlighting drives everyone away from GitHub and on to other hosting sites that actually do support Fennel! So I don’t think we’ll ever reach that threshold they require.

                              2. 3

                                I use github because I don’t value not using github.

                                1. 3

                                  I really, really value the feed, topics, and explore parts of GitHub. It lets me navigate around projects and discover what people are building, discover new tools, and existing projects that align with my use case.

                                  I’m yet to find this sort of network effect anywhere else, hell even GitLab as an alternative of GitHub isn’t as rich here. It makes me think if we moved to a more i-dont-need-github approach of self hosting, will we end up with a Git source aggregator to enable project discovery?