[embedding-shape]

> Honest question, why are companies interested in hosting on github?

Mostly boils down to marketing and easier to establish a community. Almost every developer has an account there, leading to network effects being much larger, so if you're a new FOSS project, finding contributors and getting your project in front of other's eyes is much easier when you're on GitHub compared to your own Forgejo instance.

With that said, I'd question if chasing "most external one-time contributors" or GitHub stars is the right way to actually run a FOSS project, personally I'd avoid thinking about those vanity-numbers as much as possible and focus on the project, code and contributors themselves.

But, I've literally heard those two arguments for "why GitHub" countless of times over the years.

[Mashimo]

Oh FOSS projects I totally understand. It's where I go to too.

But closed source companies surly don't need to establish a community?

[embedding-shape]

Go with the flow, don't rock the boat and use what developers already know, are probably the most cited reasons I've heard.

I've tried so many times in the past to argue for self-hosted setup that you fully control if you can afford it, things just get so much smoother and if you're a software development company, you probably want to own the software development workflow E2E so you can actually ship as fast as you want.

[Esophagus4]

I’ve argued the opposite most of the time in build vs buy. Buy in almost every case unless it’s a real competitive advantage to you.

I know developers love to build, but do you think:

1) self-hosting git provides any competitive edge to the business over letting someone manage it?

2) it provides so much value that you’re willing to fund engineers to build, secure, support this on an ongoing basis?

I’ve found the answer to those is No in both cases.

The same reason you wouldn’t build your own internal chat tool, you’d use Slack. And you wouldn’t bother self-hosting your own Jira or documentation.

Code hosting is code hosting, there’s no difference where it's hosted. There’s no slowdown in delivery with using GitHub - their March uptime was 99.5% which annoys some commenters but it’s fine. That’s 45 minutes downtime per month which is tolerable.

You would spend way more effort and money building a jenky self-hosted solution to end up with a worse result.

[oasisaimlessly]

You don't have to 'build' anything. Just spin up a GitLab docker container. Bonus: If you put it behind a VPN, you never have to worry about updating it.

[Esophagus4]

Oh man, what could go wrong.

Edit: to be clear for anyone reading, don’t do this, it’s a really bad idea. You need to patch your stuff, even behind a VPN. If you’re unsure, just google: “examples of security breaches of unpatched software behind VPNs”

[WestCoader]

Yeah I literally work on that side of things, Platform/etc. Managing GHE, CI across so many CI platforms over the past almost two decades, etc. It's a disaster thinking you can "just spin up X". Sure, if you're a two person operation, but scale becomes a factor real fast. Too many people on HN are giving away they have little to no experience. And I'm the one that made the initial comment in this thread, lol. It's frustrating, but I don't want to go back to "managing build agents" and the control plane (aka whatever your central Git Host is) for everything and all jobs, etc. That's a pain in the ass and 90% of environments have no fucking clue how to maintain that shit.

If someone wants to pay me to do lead such an effort, I'd do it, and yes, it'll all be done and managed in code, and it will be done better than 90% of folks could do (I've seen the production build systems most environments have built, some big names too, and they're trash...in no small part because it's simply hard to do), but it'll take a while to smooth the experience out for all of your requirements. You're gonna be paying, and very well, for a while.

[idkyall]

Usually, at large enough corporations, it's one of two things. Some random project gets open sourced, and it ends up on Github(see, for example, Salesforce) - or, more commonly, some subsidiary or acquisition had github and has either refused to migrate to the internal source system or the hassle of migration isn't worth it.