2. Raspberry pi as a forge for a long time: also check, the git server shim is super lightweight, its just an XRPC layer over git repositories + an sqlite3 database. there are folks running it on a riscv board with 512 megs of RAM.
3. Actions are critical and they should be runnable on my local machine: IMO this ask is slightly misplaced. it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc. it would be really cool to "promote" results of such builds to the forge itself.
It is the job of the build system, yes. In most cases the problems people want to solve with locally runnable Actions aren't the build not working, it's the whole integration of the thing; all the YAML definition, secrets, exactly what commands it runs, how it restores tools and caches (which your build system _might_ take care of but the available primitives for that in GHA are very poor), etc.
I do think it's just an awkward problem to solve though, because it essentially devolves to needing to run the entire system somewhere else, which is why every system I've seen like this ends up being trial-and-error.
Surprised to see raspberry pi for hosting data that's supposed to be integral to a workflow. I've been burned too many times by SD card corruption in the past. Do you use NVME drives nowadays, just curious.
I use RPi 4 with a cheap SSD connected via USB-to-SATA connector as a tiny home server for a year already and it works without issues.
I know that not all USB-to-SATA connectors are compatible with RPi – I got lucky with the first connector I tried (Unitek). Not sure if RPi 5 has a wider compatibility.
>it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc.
yes, and... the idea here is that it would be neat to extend the hermetic builds idea such that this can be run locally / anywhere where there's compute easily. The root problem that's being called out here is that idea of running something until the CI says it's green when there's a change, commit, network call, in the cycle is a pain in the ass. (The best way to avoid this churncycle is to just never write bugs! TFIC ;P)
Both Radicle and Tangled miss the point; these are all for public collaborative work, but what about private repos? Many users work on side projects; they use GitHub private for this. Once you learn GitHub, then you also start public projects on GitHub.
The point I am trying to make is, until you offer a user the ability to make a private repo for side projects, it's unlikely to take off.
What people want is the ability to make a private repo, go away for a few months and come back to find their repos right there waiting for them.
A remote execution cluster and CAS for build artifacts is a good way to avoid duplicate work on local vs CI, and avoid the problem of needing to trust local builds.
Between Radicle, Tangled and Grasp, Radicle feels the coolest to me, emotionally, local first, p2p, for whatever reason it feels kind of nostalgic.
Grasp is actually pretty cool too, built on nostr, which is maybe a stronger platform in the end? I dont really know enough about it. Stronger as in, you're maybe opening up more interoperablity by putting your stuff on a "anything network" vs Radicles "p2p git data network".
To be honest they're all cool ideas, Tangled feels some how corporate though.
Graps seems neat in the way it forces you to sign your commits (which should really be standard practice) but I think Github itself has proven that interoperability is not that important.
I can understand that. It's a difficult problem design-wise and needs someone that knows crypto, so I won't hold it against software that labels itself as alpha.
There's a good argument to be made that the data for reviews could be held in git repos just as easily as the source.
It can be done incredibly easily simply by having a branch per review with a known prefix (although these will rapidly clog up the default branch namespace), implemented via git namespaces to be distinct from the main namespace, or maybe just a special branch e.g. ".reviews" that just contains commit IDs for the tip of each review branch.
It just needs someone who's invested enough to specify it and make a viable implementation, after which people might start adopting it. I guess the reason github and the various forges didn't take this approach is that keeping the review metadata within their ecosystem is what gives their platform value. If anyone could use any local tool they like for reviewing other people's code, there wouldn't be as much vendor stickiness.
EDIT: actually, I guess there are other reasons why you might want your review metadata in a different repository, such as access control and/or cross-repo reviews.
There were a few efforts like that back in the day (when people still cared about offline and store-and-forward-style operation[1]), like Bugs Everywhere[3], git-appraise[4] which stored its data in Git’s little-known “notes” namespace[5], and git-bug[6] which for some reason I’ve seen mentioned quite a bit in such threads recently unlike the others—though I’m not complaining about one of them getting mentioned at least.
Also, as far as read-only access, Gerrit review data is actually accessible via Git[7] (for review ABCDE, pull refs/changes/DE/ABCDE/meta instead of one of the usual numbered refs under that prefix), and someone made the effort[8] to make it accessible via Git notes too (as mentioned in the post on Git notes that I linked above).
[1] Can I have a viable replacement for PGP for that use case? Please stop telling me that I don’t exist and should screw off[2]? Please?..
> 1. Stuff happens in the wrong order. […] You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
My approach is to utilize https://pre-commit.com/ to have all checks available to run locally during commit (or push), but leave it to contributors whether they want to run it or not. If they don't, the checks still run on the forge after pushing. The upside of this approach is that it still allows contributors to commit without internet access or the forge being down.
> 3. PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission.
Well, that's possible with Github and is just a matter how permissions to merge PRs are configured. Just let every contributor merge changes without explicit approval. And if you want LLM approval, make that a Github Action with mandatory success for merging.
> 8. On the flip side, since I need to be online all the time to really work with a team […]
Sure, for communication you need internet access, but working on code can be much more efficient if you can do so without relying on internet access and the forge being available.
I'd even argue working on issues and reviewing PRs should be available entirely offline too with just the state getting synced whenever internet connectivity to the forge is available.
When the solution becomes the problem, an opportunity for disruption opens up. Lots of chatter around this right now. I'd be curious to see if any of the many alternatives popping up gain traction before Github course corrects.
I think the problem is that Microsoft committed to AI totally. There is
no way back for them. And this also means that Github will suffer from
this. Microsoft PR will tell people that AI is the solution to everything,
but in reality it will lead to problems that keep on coming up again and
again. Now, people may say "but Github services being down, does not have
anything directly to do with AI" - while that may be true, the problem is
that Microsoft shifted its strategy already, so most of its considerations
will go about AI top down control. Whether people's workflow using Github
is disrupted, is at best only of secondary interest to Microsoft - and that
specific problem will keep on resurfacing again and again and again. Perhaps
it will be silent for 3 months or so - but I am 100% certain that in the not
so distant future, you'll have a new drama story about how Github is declining.
This is like step-wise deterioration. Ghostty won't be the last here.
Whether alternatives arise ... that will be interesting to see. I mean those
alternatives need to not suck, but a lot of those websites etc... kind of suck.
They can support hosting your own git instance through their platform. That would imo be more interesting. You keep your code, run your runners, but don't get bombarded with bots
One of my issue with the PR process is the way they are focused on comments first, instead of the code. You also have the same issue that email threads have, if you comment something substantial, with details you pretty much always get a response that will take one small point, and sort of ignore the rest.
I also hate how noisy the discussion part is, and how GitHub handles that noise by just… hiding part of the discussion. For controversial discussion it is such a mess and horrible to track what is happening.
It’s just not a great discussion platform, while also putting that as the default tab in the PR view
This makes total sense to me. Everything that makes up the state of your project should either be part of the versioned repo (git) or not be part of the project.
I created a little Github Issues replacement for myself that puts the issues within the repo so that the work and the todos stay in sync. https://github.com/steviee/git-issues
And I bet there's numerous other projects like that.
I really like Gerrit's workflow with diff reviews as opposed to pull requests, but unfortunately compared to something like gitea it lacks everything else we've come to expect from git hosting (issues, project planning, etc) which makes it seemingly a hard sell for many. I really wish there was a nice diff review platform kind of like phabricator but alas.
My best guess is lack of resources and that they want to focus on the well known PR workflow instead of trying new things out of the gate. It's exactly that, it's a proven github workflow for better or for worse that most people are familiar with.
This article says git was designed for distributed version control. Then says git doesn't work for most distributed projects because there isn't high trust. But, I'm puzzled why people would still want to build software with low trust.
Discussions like that need to get into the details: trust to do what? You don't want to let randos force push over your repository but you might want to let them submit patches.
> Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
How would a pre-commit hook help? Would the developer not be crying and working late if their work was rejected by the pre-commit hook instead of the PR? Also, if the tests are so fast they wouldn’t block the terminal running `git commit` for more than a minute or two, you can just run the tests on the local machine, and you should be running them as part of your workflow.
> PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission. A nice one. With legroom. Let me customize and more easily control this. If the person is a maintainer and the LLM says its low risk/no risk just let them go.
You can do this with the existing forges, you can give trusted people the right to bypass the rules. Or you could build your own small PR auto-approval bot, which hands the diff to a LLM, and if the LLM approves, the bot approves the PR on the forge.
There are different workflows. I sometimes commit code that does not compile, so that I have a checkpoint. Or because it’s 16:59 and I want to leave the office (and I want to protect the code I wrote from hardware failure). I’d be annoyed if any pre-commit checks took more than 2-3 minutes, and for most projects, that is not enough to build and run any meaningful tests (especially remotely).
> I was prompted to write this after reading the good post about Ghostty leaving GitHub but it's something I've written and talked about for a few years.
Many of us were annoyed already when Microslop, 'xcuse me, Microsoft assimilated GitHub. But we have to be realistic - alternatives often sucked. Sourceforge? I find creating issues there annoying to no ends. I can use gitlab, which is a bit better than sourceforge, but I also hate creating issues there. I recently saw codeberg appears to have updated its UI (I think?), but I also find it quite annoying.
What GitHub got right were, initially, the UI; and also a focus on folks using github, e. g. making things easy/easier for them. They did not get everything right though - the wiki support I find awful. I rarely use the wikis because they are so bad.
I think the really big problem is that there are commercial interests aka private interests. Microsoft is just one example here; it is a problem literally everywhere in similar sites. In the past I pointed at the example of discussions in issues, with regards to the xz backdoor utils - and the next day after I also participated in discussions, Microsoft took it all down; though it also does not matter if it was Microsoft or the repository owner. The problem is that individuals can too easily censor potentially useful information. The issue discussions WERE useful, and they were censored. If I remember correctly, all information from back then was never fully reinstated. Perhaps people mirrored it, but I did not see a link. The point is that I think this shows that top-down control can be really detrimental. And let's be honest: how many of you trust Microsoft? We kind of need something that is de-central, works reliably and well, and also has a good UI by default and a simple (or at the least a good) workflow. And we also need to avoid the situation where private actors can hold everyone else a hostage. I have absolutely no idea how to solve the above; perhaps it requires different approaches at the same time.
The www kind of changed and I feel that private interests - aka huge mega-mega corporations in particular - made things a lot worse in the last 10-15 years here. That needs to change.
I started Free.ai as a weekend project with the same mindset. And a month in the work hasn't stopped. So I second this. Just find a good name, it helps.
If you want a certain app with a feature and the app isn't open source, then you may as well just clone the app and add the feature.
Claude Code and Codex (and other tools) have computer use and are perfectly capable of navigating, experimenting, cloning functionality, writing tests...
If the app is open source it's probably easier to just fork and add your features though. And cheaper.
Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server.
Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
Isn't this already totally possible? Or am I thinking subversion?
Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. How does the code get to the forge for feedback? That's a post-push hook!
yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.
The alternative to GitHub is already here. It is called self-hosting and there are many alternatives.
The Linux kernel is not hosted on GitHub and uses cgit. Others use GitLab, or Gitea and there is also Forgejo (Which Codeberg uses) that people are using and can be self hosted.
This is why now everyone is realising why "centralising everything to GitHub" [0] was a terrible idea and now GitHub has been (unsurprisingly) run into the ground.
As a casual user, I find the UI incredibly confusing. And not just because it's different from GitHub, but because there are so many features and there are menus absolutely everywhere.
I'm sure if I used it more often that I would figure it out, but it's deeply off-putting for someone who only uses it twice a year or so.
> Well Y Does Some Of That
yes but tangled.org really does do most of that!
1. JJ as the VCS: tangled supports stacked PRs using jj change-ids. https://blog.tangled.org/stacking , we use it a lot to build tangled itself: https://tangled.org/tangled.org/core/pulls
2. Raspberry pi as a forge for a long time: also check, the git server shim is super lightweight, its just an XRPC layer over git repositories + an sqlite3 database. there are folks running it on a riscv board with 512 megs of RAM.
3. Actions are critical and they should be runnable on my local machine: IMO this ask is slightly misplaced. it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc. it would be really cool to "promote" results of such builds to the forge itself.
It is the job of the build system, yes. In most cases the problems people want to solve with locally runnable Actions aren't the build not working, it's the whole integration of the thing; all the YAML definition, secrets, exactly what commands it runs, how it restores tools and caches (which your build system _might_ take care of but the available primitives for that in GHA are very poor), etc.
I do think it's just an awkward problem to solve though, because it essentially devolves to needing to run the entire system somewhere else, which is why every system I've seen like this ends up being trial-and-error.
Surprised to see raspberry pi for hosting data that's supposed to be integral to a workflow. I've been burned too many times by SD card corruption in the past. Do you use NVME drives nowadays, just curious.
I use RPi 4 with a cheap SSD connected via USB-to-SATA connector as a tiny home server for a year already and it works without issues.
I know that not all USB-to-SATA connectors are compatible with RPi – I got lucky with the first connector I tried (Unitek). Not sure if RPi 5 has a wider compatibility.
>it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc.
yes, and... the idea here is that it would be neat to extend the hermetic builds idea such that this can be run locally / anywhere where there's compute easily. The root problem that's being called out here is that idea of running something until the CI says it's green when there's a change, commit, network call, in the cycle is a pain in the ass. (The best way to avoid this churncycle is to just never write bugs! TFIC ;P)
Both Radicle and Tangled miss the point; these are all for public collaborative work, but what about private repos? Many users work on side projects; they use GitHub private for this. Once you learn GitHub, then you also start public projects on GitHub.
The point I am trying to make is, until you offer a user the ability to make a private repo for side projects, it's unlikely to take off.
What people want is the ability to make a private repo, go away for a few months and come back to find their repos right there waiting for them.
A remote execution cluster and CAS for build artifacts is a good way to avoid duplicate work on local vs CI, and avoid the problem of needing to trust local builds.
Honestly, something like Radical seems a lot more seamless and complete. Or at the very least, I'm wary of Tangled's alpha tag.
Between Radicle, Tangled and Grasp, Radicle feels the coolest to me, emotionally, local first, p2p, for whatever reason it feels kind of nostalgic.
Grasp is actually pretty cool too, built on nostr, which is maybe a stronger platform in the end? I dont really know enough about it. Stronger as in, you're maybe opening up more interoperablity by putting your stuff on a "anything network" vs Radicles "p2p git data network".
To be honest they're all cool ideas, Tangled feels some how corporate though.
Graps seems neat in the way it forces you to sign your commits (which should really be standard practice) but I think Github itself has proven that interoperability is not that important.
Also it sounds like private repos are not possible at all, which is quite the limitation!
https://tangled.org/did:plc:wshs7t2adsemcrrd4snkeqli/core/is...
I can understand that. It's a difficult problem design-wise and needs someone that knows crypto, so I won't hold it against software that labels itself as alpha.
There's a good argument to be made that the data for reviews could be held in git repos just as easily as the source.
It can be done incredibly easily simply by having a branch per review with a known prefix (although these will rapidly clog up the default branch namespace), implemented via git namespaces to be distinct from the main namespace, or maybe just a special branch e.g. ".reviews" that just contains commit IDs for the tip of each review branch.
It just needs someone who's invested enough to specify it and make a viable implementation, after which people might start adopting it. I guess the reason github and the various forges didn't take this approach is that keeping the review metadata within their ecosystem is what gives their platform value. If anyone could use any local tool they like for reviewing other people's code, there wouldn't be as much vendor stickiness.
EDIT: actually, I guess there are other reasons why you might want your review metadata in a different repository, such as access control and/or cross-repo reviews.
There were a few efforts like that back in the day (when people still cared about offline and store-and-forward-style operation[1]), like Bugs Everywhere[3], git-appraise[4] which stored its data in Git’s little-known “notes” namespace[5], and git-bug[6] which for some reason I’ve seen mentioned quite a bit in such threads recently unlike the others—though I’m not complaining about one of them getting mentioned at least.
Also, as far as read-only access, Gerrit review data is actually accessible via Git[7] (for review ABCDE, pull refs/changes/DE/ABCDE/meta instead of one of the usual numbered refs under that prefix), and someone made the effort[8] to make it accessible via Git notes too (as mentioned in the post on Git notes that I linked above).
[1] Can I have a viable replacement for PGP for that use case? Please stop telling me that I don’t exist and should screw off[2]? Please?..
[2] https://news.ycombinator.com/item?id=44239804
[3] https://github.com/aaiyer/bugseverywhere
[4] https://github.com/google/git-appraise
[5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments)
[6] https://github.com/git-bug/git-bug
[7] https://gerrit-review.googlesource.com/Documentation/note-db...
[8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h...
> 1. Stuff happens in the wrong order. […] You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
My approach is to utilize https://pre-commit.com/ to have all checks available to run locally during commit (or push), but leave it to contributors whether they want to run it or not. If they don't, the checks still run on the forge after pushing. The upside of this approach is that it still allows contributors to commit without internet access or the forge being down.
> 3. PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission.
Well, that's possible with Github and is just a matter how permissions to merge PRs are configured. Just let every contributor merge changes without explicit approval. And if you want LLM approval, make that a Github Action with mandatory success for merging.
> 4. Stacked PRs are just better. […]
Seems like Github is working on this: https://github.github.com/gh-stack/
> 8. On the flip side, since I need to be online all the time to really work with a team […]
Sure, for communication you need internet access, but working on code can be much more efficient if you can do so without relying on internet access and the forge being available.
I'd even argue working on issues and reviewing PRs should be available entirely offline too with just the state getting synced whenever internet connectivity to the forge is available.
When the solution becomes the problem, an opportunity for disruption opens up. Lots of chatter around this right now. I'd be curious to see if any of the many alternatives popping up gain traction before Github course corrects.
> before Github course corrects
I think the problem is that Microsoft committed to AI totally. There is no way back for them. And this also means that Github will suffer from this. Microsoft PR will tell people that AI is the solution to everything, but in reality it will lead to problems that keep on coming up again and again. Now, people may say "but Github services being down, does not have anything directly to do with AI" - while that may be true, the problem is that Microsoft shifted its strategy already, so most of its considerations will go about AI top down control. Whether people's workflow using Github is disrupted, is at best only of secondary interest to Microsoft - and that specific problem will keep on resurfacing again and again and again. Perhaps it will be silent for 3 months or so - but I am 100% certain that in the not so distant future, you'll have a new drama story about how Github is declining.
This is like step-wise deterioration. Ghostty won't be the last here.
Whether alternatives arise ... that will be interesting to see. I mean those alternatives need to not suck, but a lot of those websites etc... kind of suck.
They can support hosting your own git instance through their platform. That would imo be more interesting. You keep your code, run your runners, but don't get bombarded with bots
@dang Not that it really matters, but why is this not a duplicate of my post? https://news.ycombinator.com/item?id=47962269
I recognise myself in this post without having realised it previously.
The PR review process is flawed, it adds something, but maybe not what it intends.
One of my issue with the PR process is the way they are focused on comments first, instead of the code. You also have the same issue that email threads have, if you comment something substantial, with details you pretty much always get a response that will take one small point, and sort of ignore the rest. I also hate how noisy the discussion part is, and how GitHub handles that noise by just… hiding part of the discussion. For controversial discussion it is such a mess and horrible to track what is happening.
It’s just not a great discussion platform, while also putting that as the default tab in the PR view
This makes total sense to me. Everything that makes up the state of your project should either be part of the versioned repo (git) or not be part of the project.
I created a little Github Issues replacement for myself that puts the issues within the repo so that the work and the todos stay in sync. https://github.com/steviee/git-issues
And I bet there's numerous other projects like that.
Hope you get your submarine, man! ;)
I really like Gerrit's workflow with diff reviews as opposed to pull requests, but unfortunately compared to something like gitea it lacks everything else we've come to expect from git hosting (issues, project planning, etc) which makes it seemingly a hard sell for many. I really wish there was a nice diff review platform kind of like phabricator but alas.
But why doesn't Gitea add it? It already has everything else, why are these forges always Github clones instead of doing more?
My best guess is lack of resources and that they want to focus on the well known PR workflow instead of trying new things out of the gate. It's exactly that, it's a proven github workflow for better or for worse that most people are familiar with.
This article says git was designed for distributed version control. Then says git doesn't work for most distributed projects because there isn't high trust. But, I'm puzzled why people would still want to build software with low trust.
Discussions like that need to get into the details: trust to do what? You don't want to let randos force push over your repository but you might want to let them submit patches.
> Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
How would a pre-commit hook help? Would the developer not be crying and working late if their work was rejected by the pre-commit hook instead of the PR? Also, if the tests are so fast they wouldn’t block the terminal running `git commit` for more than a minute or two, you can just run the tests on the local machine, and you should be running them as part of your workflow.
> PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission. A nice one. With legroom. Let me customize and more easily control this. If the person is a maintainer and the LLM says its low risk/no risk just let them go.
You can do this with the existing forges, you can give trusted people the right to bypass the rules. Or you could build your own small PR auto-approval bot, which hands the diff to a LLM, and if the LLM approves, the bot approves the PR on the forge.
> you can just run the tests on the local machine, and you should be running them as part of your workflow.
aren't you describing why you'd want a pre-commit for this? you do not have to remember to do so, and new people do not need to learn it.
There are different workflows. I sometimes commit code that does not compile, so that I have a checkpoint. Or because it’s 16:59 and I want to leave the office (and I want to protect the code I wrote from hardware failure). I’d be annoyed if any pre-commit checks took more than 2-3 minutes, and for most projects, that is not enough to build and run any meaningful tests (especially remotely).
> I was prompted to write this after reading the good post about Ghostty leaving GitHub but it's something I've written and talked about for a few years.
Many of us were annoyed already when Microslop, 'xcuse me, Microsoft assimilated GitHub. But we have to be realistic - alternatives often sucked. Sourceforge? I find creating issues there annoying to no ends. I can use gitlab, which is a bit better than sourceforge, but I also hate creating issues there. I recently saw codeberg appears to have updated its UI (I think?), but I also find it quite annoying.
What GitHub got right were, initially, the UI; and also a focus on folks using github, e. g. making things easy/easier for them. They did not get everything right though - the wiki support I find awful. I rarely use the wikis because they are so bad.
I think the really big problem is that there are commercial interests aka private interests. Microsoft is just one example here; it is a problem literally everywhere in similar sites. In the past I pointed at the example of discussions in issues, with regards to the xz backdoor utils - and the next day after I also participated in discussions, Microsoft took it all down; though it also does not matter if it was Microsoft or the repository owner. The problem is that individuals can too easily censor potentially useful information. The issue discussions WERE useful, and they were censored. If I remember correctly, all information from back then was never fully reinstated. Perhaps people mirrored it, but I did not see a link. The point is that I think this shows that top-down control can be really detrimental. And let's be honest: how many of you trust Microsoft? We kind of need something that is de-central, works reliably and well, and also has a good UI by default and a simple (or at the least a good) workflow. And we also need to avoid the situation where private actors can hold everyone else a hostage. I have absolutely no idea how to solve the above; perhaps it requires different approaches at the same time.
The www kind of changed and I feel that private interests - aka huge mega-mega corporations in particular - made things a lot worse in the last 10-15 years here. That needs to change.
Doesn't sound too hard.
Why don't you see how far you get in a weekend with Claude.
I started Free.ai as a weekend project with the same mindset. And a month in the work hasn't stopped. So I second this. Just find a good name, it helps.
gitwheel.com
This can be the mindset now with a lot of things.
If you want a certain app with a feature and the app isn't open source, then you may as well just clone the app and add the feature.
Claude Code and Codex (and other tools) have computer use and are perfectly capable of navigating, experimenting, cloning functionality, writing tests...
If the app is open source it's probably easier to just fork and add your features though. And cheaper.
Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server.
Truly magical, it would have taken me months.
Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. How does the code get to the forge for feedback? That's a post-push hook!
yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.
The alternative to GitHub is already here. It is called self-hosting and there are many alternatives.
The Linux kernel is not hosted on GitHub and uses cgit. Others use GitLab, or Gitea and there is also Forgejo (Which Codeberg uses) that people are using and can be self hosted.
This is why now everyone is realising why "centralising everything to GitHub" [0] was a terrible idea and now GitHub has been (unsurprisingly) run into the ground.
[0] https://news.ycombinator.com/item?id=22867803
If you think GitLab is a good alternative to GitHub, I have 0 trust in you.
GitLab and Azure are a daily source of pain for us.
Can you name some? I keep wondering about the aversion to Gitlab. I have yet to have negative experiences with it.
As a casual user, I find the UI incredibly confusing. And not just because it's different from GitHub, but because there are so many features and there are menus absolutely everywhere.
I'm sure if I used it more often that I would figure it out, but it's deeply off-putting for someone who only uses it twice a year or so.
The author's premise is that these all follow similar models to github and that's the problem they're calling out.
Github, Coke and Heinz. Ewww we don't have the same taste.
Guinness for the flow part, Four Roses for the review part.
Forge (github or whatever) doesn't matter.