105
GitHub faces a fight for its survival at Microsoft (www.theverge.com)
submitted 4 months ago by to c/programming@programming.dev
45 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 4 months ago (6 children)

It'll not be gitlab, gitlab is fine but the UI sucks and no improvements in sight.

Forgejo/Codeberg is the one that will take over in the coming decade.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 7 points 4 months ago (1 child)

    You think it sucks because you're used to GitHub's interface. I really dislike the github interface after having left it a few years ago. Gitlab's interface is, to me, so much better and a breath of fresh air (even though it might look like the old old Github).

    As for forgejo, I agree, once they get functional federation and a good CI (not a shitty Github actions clone), github and Gitlab can really fuck off. Gitlab might become a "competitor" once they have federation, but they only will do that if forgejo takes off sue to federation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 4 months ago* (last edited 4 months ago) (2 children)

    Forgejo/Codeberg is the one that will take over in the coming decade.

    This is both wishful thinking, and would reintroduce the same problem anyway (centralization) if it would happen (the codeberg part).

    I don't take seriously individuals celebrating a move to self-hosting either. While it may look cool and ideally liberating at first, infrastructure/hosting responsibility has worse bus factors and burnout than actual development (not to mention actual monetary costs). It's safe to assume that any code self-hosted has a high chance of becoming unreachable in 1-3 years (and yes, exceptions exist).

    Solutions like radicale don't help with unpopular repos, as you would again get a (hosting) bus factor of 1 (the dev/seeder), if that.

    A theoretical solution leveraging an anonymous encrypted distributed storage network for repos would help keeping code alive for a while (after the bus hits). But unpopular content will eventually fizzle out, out of the network.

    Multiple congregations of Forgejo (or something similar) communities forming would be cool. But the technology that would help them form one social block with network effects doesn't exist*. And what's proposed here and there (like federation for issues) doesn't cover the code itself. And even if we get far in that direction, instance drama incidents, and attempts at exerting control over "the network" will inescapably appear.

    * I don't know if tangled counts. But judging by the amount of love ^😑^ people show the AT protocol, it may as well not exist.

    tl;dr: Codeberg will not become GH-big. And if it did, it wouldn't be a good thing. And yet there is no ideal alternative to central forges anyway, not even a theoretical one.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 4 months ago (1 child)

    I agree with most of what you're saying, but:

    • forgejo is working on federation. They've been working on it for a certain amount of time by now, but I do think we can expect some concrete version of what you describe in terms of community to materialize in the next decade as long a people want it and are motivated enough

    • when talking about code that is stored in a version control software that supports decentralized state (git, mercurial are the 2 I have working knowledge of) the "easy" fix for low bus factors is to just fork/mirror the software you want to see continue to exist. Source code is not that voluminous, I would be surprised if [the collective we] can't manage to store multiple copies of the sources for software we deem useful. It's a question of changing habits, not finding some miracle tech

    Of course, habits aren't necessarily easy to change.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 4 months ago

    Your comment contains an implicit assumption; there is always a co-occurrence between active development, and all ever grown interest in a project.

    A person could grow a newfound interest in a repo after 1/3/5/10/20 years of inactivity. Most people are not glued to their chairs watching endless feeds, and bookmarking/starring (and maybe forking) all repos of interest away. The "normal" chain of events usually starts with a person growing a need for certain functionality (for research or direct use), and then checking out all tools, libraries, or resources available related to that functionality.

    Relying on users to only "seed" repos they approve of is not a good strategy for high availability, for many reasons, not the least of which is the tendency of some users to develop tantrums over time, and pressing the "remove account and delete all history" button*. This is why anonymous distributed storage is unrivaled as an availability provider, at least for a period. Long term availability however still requires frequent re-grabbing or re-insertion (both have the same "refreshing" effect in these networks).

    *Pushing code repos themselves to the side again, a decision will also have to be made with regards to whether the "ghost" behavior from GitHub should be replicated, or should "respecting the user wishes" to really delete EVERYTHING take precedence. Deciding this is important as it would/should be a part of the user agreement.

  • permalink
  • fedilink
  • source
  • parent