Hacker News Reader

> Github has always been non-free software hosted by someone else, and run according to its owners' rules and for its owners' benefit, not ultimately the end user. This was true in 2008 and it's true today.

Yup. At KDE we never seriously considered GitHub. We always built our own git infra, and eventually landed on GitLab, after banding together with Gnome and a (generous and forthcoming) GitLab to convince them to move everything we needed from the Enterprise Edition to the free software Community edition.

I think we've had exactly one multi-hour git outage in 16 years.

GitLab cloud lost some of my projects. And it was (is?) quite slow. Props to those who can keep it running self hosted.

It's actually much faster when self hosted, even on modest hardware. And it's not _that_ bad to manage with docker (for how much it provides).

It can be run as a single docker container, so it's actually very easy to self host. Occasionally it'll get into a 500 conniption and needs a restart, but you can create a healthcheck for that.

I kept a Docker install of GitLab running for many years at my first full time employer out of university back in 2014 to 2020. It was really not too difficult. Every once a while they would release a major version that required a migration or config update, but mostly the updates were a docker compose pull and docker compose up away. At our single company scale with only some 25 developers max (don't remember exactly anymore) a self-hosted instance on a moderate VM was super stable and quite boring. And boring is often good. It might be that hosting GitLab for much bigger organizations is a different beast!

I remember that the first instance of their CI solution was a separate server/service that coordinated CI jobs on runners. That was a bit cumbersome. But then they integrated the CI coordination into the main server and you only needed to figure out the CI runner part.

Today I would likely have gone for Forgejo with runners for such a small company if I were to self-host. Less moving parts and smaller footprint.

Just moved our stuff from gitlab to forgejo. Gitlab is fine. Just too much stuff for a small org. And I hated the upgrades. And they kept adding things and none of those were what I wanted :) guess a different audience or something. very good to have some options though!

Seeing KDE and Gnome come together isn't exactly uncommon but it still warms my heart reading about it.

Unlike their fanbases, KDE and Gnome teams collaborate all the time

...until it comes to bikeshedding new standards

Which features were moved? I would have thought required mandatory approvals would be the first ones to be moved.

I have had my eye on these technologies for a while. Embedding the issue tracker and such in your git repo. Every day these make more and more sense.

- https://gitsocial.org/

- https://radicle.dev/

- https://github.com/git-bug/git-bug

Exactly this. Even though I don't use git-bug anymore, I'm still a sponsor. I desperately want an issue-tracker-in-.git to become a standard.

Issues and CI are the only lock-in. The latter is legitimate because you're using someone else's CPU, but every developer has the tooling to "git diff" and write comments if we could just agree on a format.

I have trouble wrapping my head around how to make it so the public can create an issue in your git repo.

They can clone the repo, make changes, and then push. On the server, you can have a hook that checks if the commit only contains appropriate issue changes, and apply just those.

Sure, a little more complicated than “Create Issue”, but not that much for devs. We could even simplify the workflow with e.g. git-issue or something like that, similar to e.g. git-send-email.

    git issue init “There is a problem”
    git issue push
    git issue get 6 # short for issue@{6}

I made the decision to leave Github a couple months ago when I retired and started heavily working on personal projects. I like the idea of radicle and used it for a while, but it's complicated to set up and maintain if you want to run your own seed node and pin your personal projects.

What I ended up with is a version of a static forge - Charm's soft-serve to host the repos and a forked version of the pico.sh pgit static site generator. I added git-bug integration to track issues in the repo and an alternative CLI to git-bug that works better when collaborating with agents.

A static forge site is very resilient to bot traffic because it only renders a limited number of commits, instead of pathologically allowing a near infinite number of URLs for bots to crawl.

https://kilimanjaro.io if you want to see what it looks like.

Indeed really quick and responsive

I would agree with everything you say, but why not both?

We are actually facing 2 distinct problems:

- Github is a centralized, controlled git hosting, identity, collaboration platform.

- Bots are attacking any public facing interface.

So maybe the solution is:

- to keep a Radicle node private/behind fences to lower the maintenance/security burden, with eventually access to selected collaborators.

- publish the repos with a static site generator like pgit

I'm not a fan because it makes the change log mostly issue tracking and not actual changes.

Using a separate Git repo with a defined naming structure I could appreciate.

(e.g. gitrepo.org/project and gitrepo.org/project_issues )

Radicle is such a cool concept and seems to be working great. The only thing it needs is a better way to search through the projects hosted on each node.

The centrality of GitHub was part of its appeal. It’s where you went to see where nearly every (obviously not all) open source project was being developed. Based on his post, the network effect was a large part of the draw and the reason he stayed despite reliability issues. A more federated set of git UIs will never capture the same feeling.

I could imagine something like the mastodon protocol but for git forges, where even though they are separate websites there would be no true boundary to discoverability/interaction

They're all just value propositions. Is it worth my time and money? There ya go that's it.

It's not unlike the emotional drama I see each time Netflix raises prices (people get really upset about that), or video game discussion (the worst). If it's not worth the the value proposition, move on ... don't hang on / waste emotional cycles on Netflix or something like that ...

Granted I'm not a robot, I get the the emotional connection too, I think back to my early days in computing and I still fondly think of the now defunct manufacturer of my first PC, later the Windows 95 start me up commercials ... it was something magical.

> I can't help but think that some of this heartbreak would have been avoidable, if only he possessed more of the Richard-Stallman-esque attitude that non-free software is inherently suspect and unethical.

I think that model works well when it comes to code, but I don't think the non-free software movement ever really figured out how to deal with services and data. Even if GitHub was completely 100% GPL Free Software... the user accounts and everyone's comment history and stuff lives on a database somewhere. The servers are running somewhere. That's where the community is.

Even if you could take GitHub and spin up your own fork running the exact same software, the community isn't there. The interactions aren't there, the history isn't. It's like building a clone of your childhood house and wondering why your young parents don't magically appear in it.

You're completely right. I care about the free software movement from an ethical/freedom-preserving perspective, and I do think that many facets of the movement are too grounded in the details of how personal computer software in the 80s and 90s worked, rather than in the question of how to import the user-freedom-perserving ethos to services and data.

The question of how to create free-software-mediated online communities that don't involve storing user identity and data in a company's private database is critical. The user database, and what can be built upon it, is the single biggest reason people do use Github despite its flaws.

Is the problem solved by an open database license? Doesn't that make a community migration easier, putting a cap on how enshittified any given database can become?

I don't think the community of GitHub matters as much as people keep saying here. I think each project has its own small number of developers, and getting all of them to move is much easier. It has a larger number of bug reporters and downloaders, who only interact with the project occasionally and are perfectly capable of doing the same thing anywhere else.

> On the other hand, I can't help but think that some of this heartbreak would have been avoidable, if only he possessed more of the Richard-Stallman-esque attitude that non-free software is inherently suspect and unethical.

Since we’re getting all philosophical, heartbreak isn’t inherently bad, it means you had the opportunity to love something deeply. Being engaged in the world means taking risks on things that might disappoint you. I do wish more of that love were directed at open source, but it’s not as if open source is without heartbreak and disappointment. Richard Stallman is sort of emblematic of someone who starts out with good intentions, but whose paranoid risk aversion probably put a ceiling on his potential?

I've never understood the enthusiastic sharecropping for Github. It's a reasonable tradeoff to let Github own the public home for your code, but no reason to be happy about it.

This is orthogonal imo. There are plenty of services that work really well that are closed source

Agreed. His suffering comes from his inabillity to see the bad in closed source software. I lost my respect for him when he sold Hashicorp.