Hacker News Reader

Comment by atonse | Hacker News Reader

During one of the x threads where Mitchell was (legitimately) complaining about Github, there were a couple replies suggesting that GitHub should hire him to be their CEO.

And I remember seeing that and thinking "huh... not at all a bad idea."

There is a specific kind of leader that can turn such ships around, and they are strong in their convictions, and aren't just "managers", but visionaries coupled with strong execution and power to attract talent.

I think a new GitHub will emerge and when it's just right, will grow like wildfire (like OpenClaw, or even GitHub itself did during the SVN and SourceForge era). And many are already trying to be that new GitHub.

View on HN

The problem is that Github does a lot.

However, I consider that there is still not a great UI for the core service, in special for a complex project.

In the other hand, I bet jujutsu has the best basic take, and is still missing a good forge.

Unfortunately, naming things is hard, and JujitsuHub just doesn't roll off the tongue the same way that GitHub does. jjhub? forgesu?

jub

JubHub

You just don't have to think about it too hard:

jjplace/jjhub/codetown, whatever. Doesn't matter.

Names don't matter that much for brands. Names just have to be simple enough to remember (ideally two syllables or less). What the heck does Nike mean, for example? Boeing is just someone's name. Microsoft is just two words smashed together. A brand's name literally doesn't matter.

Case in point: Apple Computers.

having it include the word App is genius

Nike is the Greek goddess of victory.

I often daydream about what a magical "life scoreboard" would have on it, some universe-aware program counting arbitrary things. I'd love for such a scoreboard to display "percentage of Nike shoe owners that know Nike is the Greek goddess of victory."

I would guess under 10%, and only that high because Nike sells shoes in Greece and Italy.

Dojo is such an obvious thing, but its such an obvious thing that there are dozens of software trying to call themselves that.

Dojjo then?

Dojjjo, pronounced do-jj-jo

Now we're talking!

At first I thought the KDE apps all playing on the K was kinda weird and awkward, but as time went on I really appreciated how easy it was to search for them due to this. So I really think it's a benefit to play on traditional words rather than use them as-is.

JujutsuJunction (Ju³), obviously.

you don't have to name your forge after the VCS it's based off of.

JitHub.

("Please don't sue us.")

This is hilarious & the best name to use honestly

GitHub, but it's pronounced with a soft G, like the peanut butter.

> forgesu

Mi vidas kion vi tie faris.

Xit has a better “take” on Git. Pijul & Darcs still have better fundamentals.

worse is better

pujil's patch alebgra is sick but the whole system implementation is so complex my guy is still toiling away on it, unfinished, after half a decade

But how much of that do people actually need? Most users don’t use most features. The core MVP is not that big.

The old saying goes: Everyone only uses 10% of what MS Excel can do. But everyone uses a different 10%.

The same goes for Github to a degree. Yes, there are hot paths that "everyone" uses, but also areas where most people never wander and other use daily.

Google Docs doesn't do even 20% of what Office does, but it's a serious competitor anyway. That's because it implements a 5% feature that 80% of its customers use: instant internet sync.

Does it do anything that GitLab does not?

With what I heard about GitHub Actions, the GitLab CI pipelines should be much better.

Not that I haven’t shot myself in the foot with GitLab pipelines on numerous occasions.

It does a lot but at the end of the day, if the core functionality is just not good anymore, maybe put all the side projects on the actual side and focus on how to make sure core functionality suck less.

For example - We adopted GitHub Actions, then we swapped it out this year. Our own primary use case is code hosting + PRs. We want it to talk to the other (better) tools that intended for their use case. We want it in a secure yet fast and available manner. Nothing else. I don't care about projects, issues, or whatever super app they're trying to become.

Maybe it's time for fossil to get another look... It's effectively distributed code, wiki, and issues all using the same tool.

Every time Fossil comes up, people's big objection is that you can't squash commits. Personally, I'm fine with that - I tend to agree with Hipp that the repo history should not sacrifice truth for the sake of pettiness in the timeline. But a lot of people seem to disagree, which limits the audience for Fossil. I use Fossil for my own projects but I wouldn't expect it to become big like git is.

Mailing patches is the same as squashing commits. The Linux kernel would be much harder to maintain without messy history being carefully distilled down to well crafted patches.

But mailing patches is a pain in the ass. VCSes should support squashing and rebasing.

Gitlab is pretty cool to be honest, and it’s generally underrated.

I agree, but it does have faults. Performance is woeful, and managing an on-prem instance is (literally) a full time job.

> managing an on-prem instance is (literally) a full time job.

Hosting a Docker container is a full-time job? I have worked at several employers self-hosting their own instances without issues or a lot of effort. Many FOSS projects do, that definitely do not have a full-time guy for that. What are you talking about?

Hundreds or 10k+ users?

I imagine requirements and integrations may differ a lot. I have seen many incidents with a large instance.

yeah that is true. i did manage a gitlab instance for ~100 developers (between 2019 and 2022) and yeah performance was shit. not gonna lie, i blame ruby for that.

if you accept the performance hit, it's great quality software though.

however, a fairly large company with 100-120 users (developers, devops engineers, QAs etc) and ~600 gitlab runners ran happily on a 8 core / 64gb virtual machine (hosted on a local vmware cluster).

so it is (was?) also fairly cheap.

gitlab.xfce.org is absolutely not a full-time job. It's run by one guy in his spare time, and that spare time doesn't even amount to a part-time job.

I do agree about performance, though.

The problem is that what users want GitHub to be and what their owners (Microsoft) want them to be are disjoint.

If AI replaces software development the way that big tech company management wants it to, maybe they'll converge again. In the mean time, people want a git remote and they're getting an unstable host diluted with some flaky vibecoding bullshit.

> GitHub should hire him to be their CEO.

Not really the fix you think it might be. That wouldn't change Microsoft's ownership, and he'd still be hamstrung by whatever cost-cutting, anti-competitive, user-unfriendly bullshit Microsoft wants to shove down Github users' throats.

> GitHub should hire him to be their CEO

And then impose the same requirements that killed GitHub in the first place.

- "Ok guys first thing is move off Azure and ditch Copilot to get back to the level of stability we had before all that mess"

- "Uuh, no"

Be a pretty quick story

He would pull them away from co-pilot and the unlimited spigot of money that agentic coding brings, which is contrary to the best interests of Microsfot.

> I think a new GitHub will emerge and when it's just right, will grow like wildfire (like OpenClaw, or even GitHub itself did during the SVN and SourceForge era). And many are already trying to be that new GitHub.

Really? I can only think of two: Codeberg and Sourceforge. Which are both great, but that's not what I'd call "many".

Gitlab, Bitbucket, Gitea

Oh, I'd forgotten about GitLab and Bitbucket. How is Bitbucket doing these days?

Gitlab? Three distinct codebases is quite a lot to be honest. Especially when Forgejo has the lineage of Gitea and Gogs in its wake.

At least as far as I can tell, Gitlab seems to be used a lot more than the other two. I don't think I've ever gone to a page for a SourceForge project that was created after maybe 2012 or so, and although it's possible I've looked at a project on Codeberg or Forgejo, I can't think of a single one off the top of my head. Meanwhile, I've run into projects on Gitlab (either gitlab.com itself or a self-hosted version) at multiple employers and various Linux codebases and packages (Plasma and Gnome desktop environments and other various windowing-related software, Arch Linux package sources, etc.).

I guess it's possible that my experience is wildly different than others, but if we're talking about volume of usage today rather than individual preferences, it's kind of shocking for me that someone wouldn't think to reference Gitlab at all in the list of potential successors, let alone not mention it literally first.

Note that SourceForge is very different from Sourcehut. Sourcehut is a self‑hostable software forge that can be interacted with by email even without an account. I'd forgotten about GitLab. I guess it's annoying enough that I repressed it.

I'm a bit confused; from what I'm seeing, no one mentioned SourceHut until now. Did you make a typo before?

> Really? I can only think of two: Codeberg and Sourceforge. Which are both great, but that's not what I'd call "many".

Oh shoot, I must have been more tired than I thought. I definitely meant Sourcehut, not Sourceforge.

Gitlab's interface makes me want to cry every time I have to use it. I would not recommend it to someone who misses classic GitHub. Codeberg/Forgejo/Gitea would be a much better match.

What, cause it is too busy?

I haven't made a comprehensive list, but off the top of my head:

- frequently needed navigation links buried within menus within other menus

- menus labeled by mysterious icons, sometimes with mysterious text, sometimes with no text at all

- authentication system that has failed me in a variety of ways over the years, even locking me out of an account in one case

- client-side script execution required to do anything all, even simply display a file

As I said, I haven't kept a list, but GitLab is very much in the category of interfaces that were built by javascript fanatics who don't understand (or don't care about) ergonomics or privacy. I accept that not everyone is bothered by its many problems, but I avoid it when I can.

Doh, I completely forgot about GitLab. OK so that's 3 services. I'm only counting hosted services that aim at serving all comers and providing an entire platform similar to GitHub. Individual disconnected instances, while useful, aren't a replacement for the social aspect of GitHub.

I think both gitlab and forgejo are working on federation.

https://forgefed.org/

Sourceforge???

I am pretty sure they were talking about sourcehut...

I was yes, I must have been more tired than I realized.

AtomGit

I'm still holding out hope for distributed and federated git forges. The only compelling reason for everyone to centralize on GitHub is collaboration on issues/PRs without everyone allowing signups on their self-hosted forges. That could be achieved without hosting every line of code everyone's ever written in the same crumbling infrastructure.

It'll probably never happen. But it'd be really nice if it did.

Jeremie (of XMPP) has a neat project, v-it, which uses atproto (Bluesky) to let people socialize their changes to projects. https://v-it.org/

It's a bit short of actual PRs, but in some ways, especially with agents, the lo-fi approach has some advantages.

Interesting project, thanx.

Also nice language evolutions: "socialize their changes to projects", "lo-fi approach" :)

> I'm still holding out hope for distributed and federated git forges.

Do you know that you can just send a patch via email (assuming you're not using the gmail web client)? You can even save the diff on some hosting website and send the link via any text medium.

I say this as someone who actually ran mailservers for about 25 years, who can telnet to port 25 and type SMTP to send an email, and who is hugely found of plaintext: I'd rather quit coding than move to that workflow. I loathe every bit of the pipeline of getting a clean patch from machine A to machine B, where I control at most one of them, and having it come out the other side with the same SHA256 digest. I don't look down on people who prefer it: to each their own! But I'll never in a million years understand it. Say what you will about the GitHub-style PR process, and there's plenty to say about it!, but there's a reason that devs outside LKML and the *BSD mailing lists pretty much immediately leapt onto GitHub the moment it became widely known. It was a revelation.

I get your point and maybe my tone was snarky (not a native speaker). But why would you want an exact reproduction on the other side? The diff format is human-readable for a reason, so slight errors can be fixed quite easily (if they do happen). Extracting patches from a well-configured MUA can be done quickly too.

In this workflow, I don't think it's meant to have the same SHA1 digest. It's a workflow that's very much designed for a handful of core contributors (who have direct repository access) and gatekept one-off patches.

Some other accepted git workflows, like rebasing onto master, or even adding a "committed-by" or "signed-off-by", don't preserve SHA1 hashes either, and it seems you don't really need that property outside of closely collaborating cliques.

Reply on news.ycombinator.com