Sure, I know a lot of projects have been on GH since before MS bought it, but they’ve owned it for quite a while now, so we really should be seeing better migration out by now, no?

Codeberg is nonprofit which seems more in the spirit of the Linux ecosystem overall. GH is for-profit…

EDIT: All right, all right, I’ve gotten schooled. Thank you, O wise ones; I didn’t realize how much Microsoft literally depends on Linux, among other things. I will proceed to shut up.

  • Two main reasons: history and network effects.

    GitHub was an independent company for a decade that provided a vastly superior service to what it replaced, primarily SourceForge. And it was free for FOSS projects, while charging for closed ones.

    The improvements paid for by the closed source customers trickled out to everyone. So, it became the best place for FOSS developers, large and small. And as more people moved to GH, the more reason there was to move to it.

    Of course, it was constantly bleeding money and eventually had to do something. That ended up being selling to MS.

    There was a lot of trepidation about this, but for the first few years they not only kept their promise about supporting FOSS, but actually made it better by allowing small private repos to get many of the services that were previously gated for open FOSS or paid repos.

    And the alternatives were stil not as good, and just as importantly didn’t have the user networking that GH does.

    Now, some FOSS people are starting to look elsewhere, Codeberg, self-hosted Forgejo, and others. They have come a long way and are nearing feature parity, particularly for smallish projects. But the network effects of discovery and reputation are strong, and GH still provides a few more useful features.

    I’ve moved my private repos to self hosted Forgejo, but my public ones are still on GH as push mirrors. I’m not ready to give up the discoverability and Mac/Windows CI runners that I can get from GH for free. I hope to be able to some day, but not yet.

    • There was a lot of trepidation about this, but for the first few years they not only kept their promise about supporting FOSS, but actually made it better by allowing small private repos to get many of the services that were previously gated for open FOSS or paid repos.

      • They embraced! :D
      • They extended! :D
      • . . .aw, shit. :/

      I’ve only a basic understanding of using Git myself, but I think I’m gonna learn it with a self-hosted Forgejo for my Godot projects too.

      Then for the parts that don’t have feature parity, I won’t know what I’m missing, and I have no need for “iNdUsTrY sTaNdArD LeAdiNg oPtiMiZeD sYnErGyStiC wOrKfLoWs” or whatever hahaha.

      It does definitely present a conundrum if you want people to see your open source software though. Damn network effect. =\

      • The number one thing to remember about git is that you don’t need a full hosting service around it for basic functionality. If it’s just you, a single local repo will probably serve you just fine, maybe use a bare repo on your main machine or a Pi-level device if you like as a remote/backup. Just git init or git init --bare and you’re good to go. GitHub, Codeberg, Forgejo, and all the others exist to serve multi-contributor and/or public project-level needs.

        The number two thing to remember is that it is based around graph theory.

        • That’s some really helpful advice, thank you! 😃 I actually didn’t know you could just make any local folder a repo like that.

          Would a Forgejo instance still be helpful if I wanted to have “one point of truth” between multiple machines even if I’m the only dev? I already use Syncthing, but for some reason I feel like there’d be a lot of sync conflicts and stuff.

          The other main reason for wanting to learn Git, of course, is because it’s otherwise more difficult to try out changes to scripts and experiment, without finding yourself lost in the weeds and forgetting what worked last.

          My current “version control” is “copy the entire project folder before you do anything major.” 😂

          • BartyDeCanter ( BartyDeCanter@piefed.social ) 
            link
            fedilink
            English
            arrow-up
            2
            ·
            edit-2
            3か月前

            If you just want one point of truth, the minimal version is to create a bare repo somewhere that you have ssh access to or your local machine. Then you can clone/pull/push from it.

            A bare repo is a special kind of repo meant for exactly this, but can be a bit confusing at first. A normal repo contains all of your current working files and a special .git directory that holds all the files/blobs/history that git needs to work. A bare repo is just the .git as a top directory with bare=true in its config. So you can use it as a remote, but it never has a working set. They are usually named something like my_repo.git.

            Edit:

            Here’s a basic example for setting it all up in a fully local way:

            mkdir ~/bares  
            git init --bare ~/bares/my_repo.git  
            mkdir ~/code  
            git clone ~/bares/my_repo.git ~/code/my_repo  
            

            And then you have remotes as your main source of truth in ~/bares and your working copies in ~/code. If you want to access from another machine that has ssh access to the first, you can do:

            mkdir ~/code  
            git clone user@host:~/bares/my_repo.git ~/code/my_repo  
            

            And then use git pull/push to keep it all in sync. Don’t use Syncthing on a git repo, it eventually goes badly.

            • This was really informative, thank you so much for taking the time! Definitely bookmarking this. :)

              I was looking up further why you’d use a bare repo over a standard one. Somebody said for just sharing a repo between users, “snapshots just take up unnecessary space.”

              …But would that mean you can’t roll back history? Maybe I’m ignorant on the term snapshot in Git context lol.

              But yeah, I really appreciate the post and I think that’ll get me on the right foot, to actually developing games instead of setting up yet another tool and procrastinating what I want to actually be doing anyway. 😂

              Glad my instinct was correct about not using Syncthing for this purpose. XD

              • Happy to help! And yes, I have no idea what they’re talking about. If you don’t have snapshots (commits) you don’t have version control.

                Let me know when you get your game going, I’d love to check it out. I’m working on a few myself.

    • Bogus007 ( Bogus007@lemmy.zip ) 
      link
      fedilink
      arrow-up
      2
      ·
      3か月前

      Just to give some relevant information: Git, the major program behind GitHub, has been developed by Linus Torvals. The license allowed the free use of git until today. Some people took git and built a web application around - GitHub was born. Sure they added some features, but the engine was git! In 2018 these “creators” of GitHub sold their product to Microsoft. They gave a s**t on the community and what may happen afterwards.

    • Loren ( loreng@beehaw.org ) 
      link
      fedilink
      English
      arrow-up
      12
      ·
      3か月前

      It really is quite amazing how fast its gone completely to shit. The site is so fucking slow so much of the time. I’ve started moving my projects one-by-one to a Forgejo instance I control, the main hurdle is just updating actions workflows to work there.

      • In hindsight the period 2015-2022 was a kind of a golden age for Microsoft.
        They actually made (well, acquired) some good software, and even not-so-good stuff like Azure had a point of existing.

        Of course it all went downhill very quickly.

        • Loren ( loreng@beehaw.org ) 
          link
          fedilink
          English
          arrow-up
          2
          ·
          3か月前

          There was a brief time there where I thought even Xbox was doing pretty good shit. Backwards compatibility and the Xbox Adaptive Controller come to mind. With the latter especially, I feel like that was a lot of R&D for a relatively niche product. Nowadays, idk wtf they’re doing over there besides constantly fucking up.

    • MangoCats ( MangoCats@feddit.it ) 
      link
      fedilink
      English
      arrow-up
      3
      ·
      3か月前

      I use both (why not?, they’re both free and it’s trivial to add a remote) - I find github is a little quicker to respond, a little easier to work with, and much more well known when you ask someone to go there they’re not queasy about what they might be connecting to…

  • gwl [he/him] ( gwl@lemmy.blahaj.zone ) 
    link
    fedilink
    English
    arrow-up
    21
    ·
    edit-2
    3か月前

    Momentum and time and effort to migrate.

    And there’s automated workflows such as GitHub Actions and ci/cd integrations that don’t have 1-to-1 replacements, which would mean extra work (for quite strained teams of volunteers)

    • mat dave ( matdave@lemmy.ml ) 
      link
      fedilink
      English
      arrow-up
      4
      ·
      3か月前

      Additionally, as a developer on a large open source project, the community is already established on GitHub. It would be incredibly risky to move it and hope everyone comes along.

  • stratself ( stratself@lemdro.id ) 
    link
    fedilink
    English
    arrow-up
    21
    ·
    3か月前

    The case of free CI/CD, visibility, and network effects are already said. So I wanna offer an anectode: someone I know is a graphic designer, who maintains a project that curate icons. Moving to Codeberg means he has to interact with PRs using the CLI, which he really does not have familiarity with. GitHub OTOH has a simple desktop client that allows natively switching across PRs, approving then in the UI, etc. It’s really, really convenient for someone who’s not a developer.

    I think Forgejo-based platforms will need to work on a very good GUI client, in order to attract less technical contributors.

  • plutopos ( plutopos@lemmy.zip ) 
    link
    fedilink
    arrow-up
    18
    ·
    edit-2
    3か月前

    Arguably the biggest contributor to the Linux ecosystem is Red Hat, a for-profit company that offers its technologies to the Israeli military among other things. The biggest contributor to the Linux kernel is Red Hat, while the second biggest is Meta. The Linux ecosystem is not inherently nonprofit!

  • utopiah ( utopiah@lemmy.ml ) 
    link
    fedilink
    arrow-up
    15
    ·
    3か月前

    It’s disappointing yet unsurprising to read the recurring answers, namely :

    • cost
    • incumbency

    precisely because it’s absolutely avoidable and a well known strategy. It’s so well known that it’s precisely why Micro$lop bought Github in the first place. People are there and the free tiers is enough to get the long tail.

    Meanwhile since that strategy happened people who consider smart enough should know the genuine cost behind this : it’s a TRAP. Plain and simple, you get there and you get STUCK there.

    So… yes it takes some sweat and even some money to leave the trap … but if you care about freedom, as most free software or open-source developers might, then it’s aligned with your value.

  • P03 Locke ( p03locke@lemmy.dbzer0.com ) 
    link
    fedilink
    English
    arrow-up
    12
    ·
    3か月前

    Did you download the source code? It’s on GitHub. It’s literally on GitLab. It’s on Bitbucket with ads. It’s literally on SourceForge. You can probably find it on Savannah. Dude it’s on Azure DevOps. It’s a Codeberg project. It’s on Gitea. You can download it on Gitea. You can go to Gitea and download it. Log into Gitea right now. Go to Gitea. Dive into Gitea. You can Gitea it. It’s on Gitea. Gitea has it for you. Gitea has it for you.

  • I believe the core reason is that, when MS bought it, and while they make it worse day by day, the number of projects in Github was already huge and it just keeps growing. That being said, it is still the main platform to find FOSS projects, and to have your project be found.

    A lot of people are migrating though. The good thing about the FOSS community and philosophy is that they don’t really need to rely on shitty companies like Microsoft. They can (and many actually do) just move on, at least regarding their own personal projects.

    • Yep. For example, Gnome migrated to Gitlab some time ago. Obviously it’s not as ethical as Codeberg, but maybe it offers certain features that Codeberg doesn’t (yet) have that they require. PikaOS is (was?) on Gitea.

      For my part, I’ve left Github and will only do development on Codeberg. I’ll still make pull requests to upstream projects that only exist on Github, but I have no control where those parent projects are hosted, and improving those projects is still a net benefit to everyone.

    • Remember that Git is a distributed VCS, so no git repo is dependent on a central server. Everything else about the project might be heavily dependent on GH, but any active developer is going to have a full copy of the code with history on their main workstation.

      That being said, it highly depends on the project, but I’d put it into a few buckets.

      1. Un/barely maintained projects - This is by far the largest number of repos, and many of them are used as dependencies by all sorts of projects. The truly unmaintained ones would vanish, and I bet most of the barely maintained ones would as well. The most important of these would probably be resurrected since their code will be sitting on all sorts of drives, but it will be a mess. Take a look at https://nesbitt.io/2026/05/08/weekend-at-bernies.html for an idea.
      2. Small individually actively maintained projects - There are a lot of these and many of them could continue to be just fine, depending on how much of the full GH feature set they use. They would lose all the PRs, wiki spaces, discussions, issues, and maybe even the project page itself that are hosted on GH. For most projects it would be an annoyance to have lost all that, but if it’s a small enough project that one person is maintaining it, it’s probably small enough to pull over to something else reasonably easily depending on how all in they are on GH tools and their use of type 1repos. And a project with only one main contributor is unlikely to fragment.
      3. Mid-sized active projects - Probably the hardest hit. A lot of these are all-in on the GH tools, particularly issues and CI. Losing that would hurt a lot because the project is big enough to really need those tools and uses them at a volume that they can’t just host on the leads laptop. These are also going to take a lot of work to set up the project infrastructure elsewhere. And this would probably be the sort of thing to push and simmering tensions to erupt, leading to fragmentation.
      4. The big projects - Probably the least hardest hit. Most of these are just using GH as a push mirror. The core team probably has a functioning private communication and governance system, their own issue tracker (even if it pulls from GH), documentation, and public discussion groups. Most of these run their own private CI. And they are the ones most likely for another host to step in and offer to help.

      So the little stuff? Probably going to be annoyed or not care a lot. The big stuff? Same thing. But that middle group would be hurt.

    • utopiah ( utopiah@lemmy.ml ) 
      link
      fedilink
      arrow-up
      10
      ·
      3か月前

      Right, like how Micro$lop :

      • blocked repository search without login (while it worked before the acquisition)
      • pushed in the most traditional Micro$lop fashion for its own product, e.g. Copilot, with in product ads
      • use repositories as ways to feed its own set of products, e.g. Azure for OpenAI, in order to push for code generation while ignoring licenses

      and all the other things (please feel free to make this list more comprehensive) as “reparations”?

      It’s the same old "Embrace, extend, and extinguish " (EEE) scheme they’ve been (sadly successfully) running for decades now.

  • Amuy new projects are codeberg. But github has a default 10gb repo space. Imagine everyone suddenly wants that on codeberg, the cost alone would force them to shut down or have other forms of income than donations.