Comment by qudat
3 days ago
This is a really cool project and I’ve been following it for awhile. I’m also keen on breaking up the code forges monopolies.
I’ve been dipping my toes into this space mainly because I think code forges as they exist are trying to solve multiple problems at the same time. I think there’s value in splitting this functionality up into discrete services.
For example, most forges: host your git repo, web view, collab tool, ci/cd pipeline, and task management.
I don’t see why these necessarily need to be bundled together.
For example, as long as we are comfortable not having direct access to the git repo, we can have a purely static web viewer for git: https://pgit.pico.sh
For collab, as long as we are comfortable sharing patchsets and reviewing locally, we can have a collab server that doesn’t need a git repo in order to function: https://pr.pico.sh
Then self hosting your own bare git repo on a VPS is trivial.
Git is already decentralized, centralizing it because all the other services require it is the anti pattern
If multiple services have multiple owners it becomes also a question of trust. You either validate one service that fits 80% of your requirements, or validate ten services where each solves one specific requirement.
Also, of course - economy of scale for the infrastructure / integrations between features. Monoliths are still a thing.
But yeah, I agree developer experience may be traded here.
"Git is already decentralized"
Decentralized is a big word.
Git never tackled the decentralized aspect, being served over a master-slave protocol like HTTP means you have a tendency to centralize it again.
Git was really useful because it allowed decentralization but didn’t require it like CVS or SVN. It catered to the “just clone the repo and create a new branch when you hop on the airline and push updates to origin when you land” model. But it’s really unusual that people really want a hugely distributed model. Typically, people want to go to The Blessed Repo and get The Blessed Code. For example, Linus’s got kernel tree is more important than everyone else’s clone.
This!!
It is trivial to set up a VPS with a git remote. Access it with ssh. Done. Git clone fred@fooda.com:/hubs/frog gets you hopping instantly.
I think the issue behind the curtain (attempt at an obscure reference to the wizard of oz) is lock in. And why is lock in such an issue all around us? Why is github so completely focused on lock in rather than service? Behind the curtain of lockin is funding. Paying for it. A business model.
Maybe centralization => lockin => money? Like gmail. Like github. Etc.
If you have no business model for service => money (and we do not!) then this is what you get.
[Edit: "funding" => "is funding"]
I see you hand waved people who pay money so that forges can operate.
If you have a company you don’t want to pay 20 invoices to different vendors.
If you have a company you don’t want to deal with debugging integration between your CI/CD and web view and git providers, you want to make a ticket and have it fixed.
When you are developing a project you don’t want to spend time figuring out which task management will integrate with other parts.
As a developer you also don’t want to jump through 5 different tools and waste time you want integrated and streamlined experience.
Git being decentralized doesn’t have value besides the fact that I can have my local copy and work on it separately from whatever is there on the central server my company uses.
Inevitably someone will end up paying for Tangled. Their architecture demands an infrastructure piece that actually hosts the forges and PDSs through BlueSky won't always be free. They're also non-trivial to run.
A PDS is just a docker image of a TS node app w/ sqlite that can run on effectively no hardware at all (someone got one running on a microwave once upon a time).
A relay is also fairly trivial to set up and can be orchestrated via docker I believe. You can run them on a raspberry pi as long as you have a half decent internet connection.
The tangled appview runs on a single machine w/ like 4 cores and a few gigs of ram.
You can run a knot (git host for tangled) on pretty much any hardware.
And a spindle (CI runner for tangled) on anything that meets the requirements for your CI ops.
It's multiple moving parts which increases complexity but IIRC they also all have nix flake support as well so orchestrating all of the moving parts together via nix is increasingly trivial.
The vast majority of this comment is false, btw
The infrastructure to host the forges is still a problem yes, but PDSes are VERY trivial to run, they’re just a Node.js app and they have a Compose file to make running it a quick shell script to run. And they will always be free, Bluesky is well aware that making access to the platform a paid thing would kill the project outright, and even then the code is open source and in the process of being written up as an RFC, so… please fact check your comments before posting :)
2 replies →
While there may be no technical reasons why these functions need to be bundled together in a forge, there may still be economic reasons (can’t support development as a standalone function) and usability reasons (people want it to arrive “batteries included”). The counter might be “open source proves this can work because people ignore the economics there, too,” but remember that most open source projects die with a single maintainer and the most successful ones have some sort of corporate patrons contributing sponsorship money, engineers, etc.
There is stagit as well, but it does not support branches:
https://codemadness.org/stagit.html
Does Pgit support branches?
Yes it lets you generate a tree for any revision
> I don’t see why these necessarily need to be bundled together.
They don't need to be, but it's very convenient.