3 ms·

I can appreciate Hashimoto's genuine feelings about Github, and the world of open-source software development that it opened for him and that he spent a signifi

I can appreciate Hashimoto's genuine feelings about Github, and the world of open-source software development that it opened for him and that he spent a significant chunk of his life participating in. 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. 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. I've also used Github for a significant chunk of my life, often because I had to for my job. But I've never developed an emotional attachment to it. Indeed, I have long been annoyed that Github is someone else's proprietary software, that does what it can to structurally lock users into their platform despite being built upon free-software git. I've never been able to love software that requires an email-based account and accepting terms of service and that doesn't work in Iran because the company that runs it obeys US sanctions law. So without reservation on my end, I'm glad to see that ghostty is moving off of github to something else.

zhouzhao 6mo ago
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.
sho_hn 6mo ago
> 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.
- paulryanrogers 6mo ago
  GitLab cloud lost some of my projects. And it was (is?) quite slow. Props to those who can keep it running self hosted.
  - c-hendricks 6mo ago
    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).
  - crimsonnoodle58 6mo ago
    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.
  - snorremd 6mo ago
    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.
    - Neikius 6mo ago
      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!
dannyfritz07 6mo ago
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://gitsocial.org/ - https://radicle.dev/ https://radicle.dev/ - https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug
- jbaber 6mo ago
  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.
  - dannyfritz07 6mo ago
    I have trouble wrapping my head around how to make it so the public can create an issue in your git repo.
    - Hendrikto 6mo ago
      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}
- BTBurke 6mo ago
  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 https://kilimanjaro.io if you want to see what it looks like.
duxup 6mo ago
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.
jdelman 6mo ago
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.
- legobmw99 6mo ago
  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
ozgrakkurt 6mo ago
This is orthogonal imo. There are plenty of services that work really well that are closed source
xnx 6mo ago
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.
munificent 6mo ago
> 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.
- JuniperMesos 6mo ago
  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.
  - itsmek 6mo ago
    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?
- tardedmeme 6mo ago
  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.
techblueberry 6mo ago
> 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?

zhouzhao 6mo ago

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.

sho_hn 6mo ago

> 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.

paulryanrogers 6mo ago
GitLab cloud lost some of my projects. And it was (is?) quite slow. Props to those who can keep it running self hosted.
- c-hendricks 6mo ago
  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).
- crimsonnoodle58 6mo ago
  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.
- snorremd 6mo ago
  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.
  - Neikius 6mo ago
    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!

dannyfritz07 6mo ago

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://gitsocial.org/ - https://radicle.dev/ https://radicle.dev/ - https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug

jbaber 6mo ago
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.
- dannyfritz07 6mo ago
  I have trouble wrapping my head around how to make it so the public can create an issue in your git repo.
  - Hendrikto 6mo ago
    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}
BTBurke 6mo ago
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 https://kilimanjaro.io if you want to see what it looks like.

duxup 6mo ago

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.

jdelman 6mo ago

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.

legobmw99 6mo ago
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

ozgrakkurt 6mo ago

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

xnx 6mo ago

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.

munificent 6mo ago

> 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.

JuniperMesos 6mo ago
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.
- itsmek 6mo ago
  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?
tardedmeme 6mo ago
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.

techblueberry 6mo ago

> 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?