I’ve seen some comments about how “gitlab bad” or whatnot, why do people prefer Codeberg over GitLab?

  • it_a_me@literature.cafe
    71·
    1 year ago

    1. Codeberg is fully open source(forgejo) while gitlab has an open source core+community edition but a source available propietary enterprize edition.

    2. Codeberg is a nonprofit with no ulterior motives. Gitlab is a publicly traded for profit entity with a goal to make profit

    3. This could just be me, but codeberg feels a lot more transparent. When they have outages, they explain why.

    4. Super minor, but the codeberg team “self-hosts” their own servers so you only need to trust the one entity rather than additionally trusting the server provider.

    • droopy4096
      141·
      1 year ago

      self-hosting is great but that still means datacenter someplace. I’ve been using GitLab for some time now and CodeBerg “feels weird” to me. But then it could be my biases and “muscle memory”. I’d say whatever feels right for you.

      Unlike other big name Git hosting company who chose to use AI to “steal” from hosted projects other two did not stoop that low. So there’s that.

    • Helix 🧬@feddit.de
      51·
      1 year ago

      Codeberg is a nonprofit with no ulterior motives.

      Well, their ulterior motive is to provide a service to the public.

  • teri@discuss.tchncs.de
    52·
    1 year ago

    gitlab.com is a for profit service/company. They have an open-source community edition of Gitlab which you can run on your own server. Codeberg is a non-profit association running the open-source software “forgejo” for you. At Codeberg you can become a member and then you can vote for important decisions and make proposals. People also care about ethics there. Nobody cares about profit. Codeberg runs on donations from members. I think some people feel more respected at Codeberg because the governing body of Codeberg is a subset of its users. If Gitlab cares about you, then probably because a bad user experience would be bad for business.

    • second@feddit.ukEnglish
      171·
      1 year ago

      That’s a bit of an unfair comparison - that’s the GitLab instructions to install from source. Most people use a package (rpm, deb) to install GitLab.

      The installation instructions for GitLab from prebuilt binaries is https://about.gitlab.com/install/, and that’s significantly shorter.

      That said, I think for most home applications, GitLab is hugely overkill.

      • Oliver Lowe@lemmy.sdf.org
        8·
        1 year ago

        Yes that’s true. I guess what I wanted to point out is that GitLab has dependencies like Postgres, Redis, Ruby (with Rails), Vue.js… whereas Forgejo can use just SQLite and jQuery.

        • ErwinLottemann@feddit.de
          121·
          1 year ago

          sqlite is not something one would use for a database with a lot of users, postresql or mysql/mariadb is a better choice in these circumstances. and i don’t think having jquery as a dependency in 2023 is a positive sign. not sayibg the software is bad, it’s just different.

          • ReversalHatchery@beehaw.org
            4·
            1 year ago

            Fortunately they were inaccurate, and it supports mariadb and postgre too.
            In the documentation, they leave sqlite and mssql to the last places in the listings.

        • Sigmatics
          52·
          1 year ago

          Forgejo uses SQlite

          That’s a red flag

        • second@feddit.ukEnglish
          1·
          1 year ago

          I assume that’s to build from source.

          The times I’ve installed GitLab it’s been a case of dnf install https://.... The rest gets dragged in automatically.

        • ReversalHatchery@beehaw.org
          1·
          1 year ago

          Probably Forgejo/Gitea also uses such dependencies, but their Go counterparts which are statically built into the server binary.

          If resource efficiency only depended on that, Gitlab would be more efficient with memory because of this. We all know that’s not the case, I just said it as a comparison.

          This also means that while Forgejo/Gitea depends less on your system installation, it also wont benefit from updated dependency packages.

    • andruid@lemmy.ml
      3·
      1 year ago

      Right. Paid Gitlabs features tend to be targeted as an all in one DevOps platform for larger scale organizations. So how do you do support tickets, CI/CD, feature tracking and coordination for a portfolio of products, documentation, revision control, code reviews, security reviews, etc? In Gitlabs world the answer is Gitlab, with integrations with other enterprise software. It’s HUGE. That said I’ve never heard of an organization (probably due to ignorance not lack of existence) actually doing all of that.

      I personally I’m kind of leaning towards building a proof of concept of forgejo, tekton, and maybe Odoo to see if it can cover what my org is actually doing, but he’ll we pay for tons of stuff but the amount of excell sheets floating around doing this is wild…

      • Oliver Lowe@lemmy.sdf.org
        2·
        1 year ago

        Ah come on, we all know as software people we can never stop the spreadsheets from being the real data interchange format ;)

        • andruid@lemmy.ml
          2·
          1 year ago

          Hey, at least remote works been really putting nails in the coffin of printed documents floating around.

          But seriously keeping to a good set of tools, providing them at scale and some training will hopefully make the fall back to spreadsheets less attractive to at least the middle wave of adopters.

      • Neshura@bookwormstory.socialEnglish
        1·
        1 year ago

        afaik the aim isn’t to be compatible, they just found Github Actions to be the most comfortable to use and as such based their own system around it with the liberty of breaking changes should they think it neccessary

        • ReversalHatchery@beehaw.org
          1·
          1 year ago

          You’re probably right, I hope though that they’ll try to maintain compatibility at least so that even if the Gitea Actions format changes, it would still accept and be able to use the Github Actions files