Initially, LinkedIn was just another site where you could find jobs. It was simple to use, simple to connect with others; it even had some friendly groups with meaningful discussions.

And then it gained monopoly as the “sole” professional network where you could actually land a job. If you are not on LinkedIn now, you are quite invisible in the job market. Recruiters are concentrated there, even if they have to pay extremely high prices for premium accounts. The site is horrible now: a social network in disguise, toxic and boring influencers, and a lot of noise and bloated interface to explore.

When Google decided to close their code.google.com, GitHub filled a void. It was a simple site powered by git (not by svn or CVS), and most of the major open-source projects migrated there. The interface was simple, and everything was perfect. And then something changed.

GitHub UI started to bloat, all kinds of “features” nobody asked for were implemented, and then the site became a SaaS. Now Microsoft hosts the bulk of open-source projects the world has to offer. GitHub has become a monopoly. If you don’t keep your code there, chances are people won’t notice your side projects. This bothers me.

Rant over. I hate internet monopolies.

      • Kissaki@feddit.de
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        1 year ago

        I’d rather not have to register on every individuals instance for every project, for bug reporting, discussion, or simple changes.

        On github it’s easy for me to contribute and communicate. On other platforms, not.

        • exu@feditown.com
          link
          fedilink
          English
          arrow-up
          7
          ·
          1 year ago

          There’s work to have instances federate, similar to how Mastodon or Lemmy work. And the admin could also enable Oauth2 login with GitHub and GitLab for easier access.

        • shagie@programming.dev
          link
          fedilink
          English
          arrow-up
          2
          arrow-down
          1
          ·
          1 year ago

          You could set up a mailing list for the project and pass around email patches.

          git send-email and git am are core parts of the functionality.

          While https://github.com/torvalds/linux does exist, the workflow for the various modules is described in https://github.com/torvalds/linux/blob/master/MAINTAINERS and the PR bot that shows up on pull requests in the repo: https://github.com/torvalds/linux/pull/782

          … and email is a federated protocol that is resistant to censorship that is associated with having a single server hosting the content.

          • Kissaki@feddit.de
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Did you reply to the wrong comment?

            I was talking as a user or contributor.

            • shagie@programming.dev
              link
              fedilink
              English
              arrow-up
              1
              arrow-down
              1
              ·
              1 year ago

              If the open source project is managed with local repos and patches are sent via email for consideration and integration, one doesn’t need to register remotes for each individual’s instance of the repo for each project.

              With a bit of adjustment to the “how this works” for the workflow (rather than relying upon GitHub or Gitlab or any other centralized repo), git shines as a distributed version control system that is enabled with git send-email and git am.

              The repo can be published to any of the hosting sites, but the workflow for changes, bug reporting, and discussion happens over email rather than via the implementation specific aspects of one hosting site or another.

              There won’t be the issue of “this repo got taken down from {host} because it was owned by someone logging in from a sanctioned country.”

              Yes, centralized hosting solutions make it easy to do these things… but the federated and distributed way to avoid them is hosting independence by managing the project through email.