11–20 of 34 posts
forge "fragmentation" is a good thing. git was meant to be decentralized from the start. re-centralizing on a single provider would just repeat the github saga all over again.
Yeah, it's like lamenting the great food supply fragmentation.
I don't think we're anywhere close to the downfall of GitHub. It'll be a very slow decay. The fact is, lots of people are very happy using AI tools, and most of those hook straight into GitHub. If AI is driving all this new code, it's only going to make moving away from GitHub more painful. Businesses I've spoken to hate the idea of moving their code forge. Migrations like that suck and they're expensive. There isn't…
Anecdotal, but we've had success with gitea and having agents use "tea" (gh cli alternative) as a skill. If the cli tool you're asking it to use is similar enough it will use it instead of gh without any (major) issues.
forge "fragmentation" is a good thing. git was meant to be decentralized from the start. re-centralizing on a single provider would just repeat the github saga all over again.
It's a huge miss for this article to not talk about atproto, Tangled, and how protocols can solve the fragmentation issues - both between different services and by allowing projects to run their own host while being connected to the network. https://tangled.org/ With the atproto approach you don't have to worry about reserving usernames specifically for one forge or another - usernames are atproto handles, your Blues…
I don't think we're anywhere close to the downfall of GitHub. It'll be a very slow decay. The fact is, lots of people are very happy using AI tools, and most of those hook straight into GitHub. If AI is driving all this new code, it's only going to make moving away from GitHub more painful. Businesses I've spoken to hate the idea of moving their code forge. Migrations like that suck and they're expensive. There isn't…
- Code repository
- Project wiki
- Project roadmap/planning
- Static site hosting
- Issue tracking
- Internal and external contributions (PRs)
- Code review
- Cross platform CI pipelines/runners
- Release hosting
Of these key things, what is Github good at and how much can you improve by providing an alternative that's faster/cheaper/more robust?
Of these I think the only thing Github stays competitive at is "code repository." Everything else kinda sucks and/or is expensive and flaky.
Just as an example, there's that hilarious "just give me an EXE" Reddit post from a few years back. It's fun to laugh it given the state/purpose of Github but you can also look at that as a lost market for Github. Why can't you provide a nice landing page with downloads/installers in a very clean landing page for your project on GitHub? It could even be a premium feature if it means paying for storage/bandwidth.
And don't get me started on actions. Absolute trash tier product that they should be ashamed at the state of.
That looks like a whole load of work. The thing thay is not defined is why I should do it. Also forge are already fragmented. I use OpenBSD and the software in ports comes from all over the web. You got the forges, web links,… As far as collaboration go, you can always send an email to the person. Up to them to accept it. If I care that much, I will publish a blog post or share it via the community’s channel. Those a…
I think these articles are meant for people who entered the developer ecosystem after GitHub became ubiquitous, because those developers basically only ever known GitHub, and some even see GitHub and Git as synonyms. The rest of us who started developing before GitHub, or been around communities that self-host their infrastructure, we're already used with everything being spread all over the place, this place accepts…
I for one would never contribute to a project that requires one of the above. I know some will shoot back with "but Linux!", but that's the exception that proves the rule.
That looks like a whole load of work. The thing thay is not defined is why I should do it. Also forge are already fragmented. I use OpenBSD and the software in ports comes from all over the web. You got the forges, web links,… As far as collaboration go, you can always send an email to the person. Up to them to accept it. If I care that much, I will publish a blog post or share it via the community’s channel. Those a…
Most of the reasons seem to boil down to "X bad", where X is some combination of Github, Microsoft, America, and AI
It's a huge miss for this article to not talk about atproto, Tangled, and how protocols can solve the fragmentation issues - both between different services and by allowing projects to run their own host while being connected to the network. https://tangled.org/ With the atproto approach you don't have to worry about reserving usernames specifically for one forge or another - usernames are atproto handles, your Blues…
I think it's great people are working on it, but why reinvent the wheel? Radicle and Forgejo/Forgefed were already under way before starting Tangled. What would be a selling point that would justify breaking compat with existing solutions ? (to be fair, forgefed is largely unimplemented so far)
atproto apps also tend to separate the PDS form the app view, so you can easily use the same data with different front ends.
And, atproto's identity model is much better. Rather than being tied to a server like the data, it's DID-based and you can use it with multiple PDSes.
Earlier quoted context omitted.
I think these articles are meant for people who entered the developer ecosystem after GitHub became ubiquitous, because those developers basically only ever known GitHub, and some even see GitHub and Git as synonyms. The rest of us who started developing before GitHub, or been around communities that self-host their infrastructure, we're already used with everything being spread all over the place, this place accepts…
> this place accepts patches via email, this one wants a URL to a pastebin containing the patch I for one would never contribute to a project that requires one of the above. I know some will shoot back with "but Linux!", but that's the exception that proves the rule.
Earlier quoted context omitted.
I think these articles are meant for people who entered the developer ecosystem after GitHub became ubiquitous, because those developers basically only ever known GitHub, and some even see GitHub and Git as synonyms. The rest of us who started developing before GitHub, or been around communities that self-host their infrastructure, we're already used with everything being spread all over the place, this place accepts…
> this place accepts patches via email, this one wants a URL to a pastebin containing the patch I for one would never contribute to a project that requires one of the above. I know some will shoot back with "but Linux!", but that's the exception that proves the rule.