Hacker News Reader

Comment by throwaway150 | Hacker News Reader

It is us, developers, who convinced our management to purchase GitHub Enterprise to be our forge. We didn't pay any heed to the values of software freedom. A closed source, proprietary software had good features. We saw that and convinced our management to purchase it. Never mind what cost it would impose in the future when the good software gets bad owners. Never mind that there were alternatives that were inferior but were community-developed, community-maintained and libre.

The writing is in the wall. First it was UX annoyances. Then it was GitHub Actions woes. Now it is paying money for running their software on your own hardware. It's only going to go downhill. Is it a good time now to learn from our mistakes and convince our teams and management to use community-maintained, libre alternatives? They may be inferior. They may lack features. But they're not going to pull user hostile tricks like this on you and me. And hey, if they are lacking features, maybe we should convince our management to let us contribute time to the community to add those features? It's a much better investment than sinking money into a software that will only grow more and more user hostile, isn't it?

View on HN

> learn from our mistakes and convince our teams and management to use community-maintained, libre alternatives

Every company I've been at that tried to self-host something like GitLab, later moved to GitHub. Nobody in business cares if it's open source/free software. They care about managed hosting, centralized services, invoicing, etc. DIY is great for hobbyists and the cash-strapped.

This is the irony of software engineering. This is how a lot of bad software gets written too.

> Every company I've been at that tried to self-host something like GitLab, later moved to GitHub

Interesting, my experience has been the opposite. 99% of companies I've seen self host their VCS, it has been Gitlab (with some rare sel-hosted GitHub Enterprise everyone seems to hate, and the very rare Bitbucket).

To be fair most of them started with it when Gitlab was really really ahead, features wise. The gap has somewhat closed, but Gitlab is still a superior product IMO. Just the fact that you can have an actual organisational structure, and move it around, and share variables/configs between groupings, beats anything GitHub have to offer which is slightly nicer than GitLab.

Are you based in Europe? Gitlab has a much stronger presence there. In the US Gitlab adoption is much weaker in my experience.

Yep, but I interact with companies all over the world, and while American ones tend to not self-host (in general, but VCS in particular), out of those that do, Gitlab still seems more popular.

I’ve setup self-hosted gitlab configs for multiple projects and it works fine.

Yeah I can't see a better alternative to GitHub.

OSS can build truly incredible libraries and frameworks. User facing products? ehhhhh not so much.

GitHub has gotten worse over the years but it's not like there's some gold standard open source alternative. And remember, early GH was filled with a pretty amazing group of developers and open source advocates.

If the counter is that, instead of buying github, we could have invested in building some other tool, well, that's not how this works. People need to build what the company is actually building for its users.

At work we've started switching to codeberg (which uses forgejo) and honestly it's a breath of fresh air compared to GitHub. It's blazing fast compared to GitHub and has feature parity with our needs.

Not an option for the majority of companies as it only allows open source repositories as far as I'm aware.

Tangled.org

Selfhosting gitea is trivial, I'm saying this as someone who has been doing it at work for almost 6 years. Our experience has recently prompted another org (run by people we know) to move off GitHub, they also seem to be happy.

There are plenty of alternatives to Github, from Gitlab and Gittea to Forgejo, but Codeberg is not one of them, which is what I wanted to stress.

I have (almost completely) moved my business from GitHub to Forgejo as well. I’m deploying an instance at home as well.

It’s shocking how bloated and slow GitHub is even for basic actions when you compare it to Forgejo running just your own stuff.

Bonus: if you can manage to reliably backup a database and a filesystem, you can then backup your forge. Outside GH Enterprise there is still no restorable backup option inside GitHub.

This is great to hear! I’ll check it out.

How is it for usability (other than speed) compared to GH. Given that most/all devs are already comfortable in GH. What are the downsides in your experience?

A bit late on my reply here, sorry.

There are minor clumsy points here and there in the UI, but nothing major and nothing that’s a stumbling block.

It’s hard to paint a perfect comparison without using the same features but all the basics are there and working.

The version we have in use doesn’t support a gist functionality but the last I looked there was a PR for a similar feature with a less-GH—lawyer-baiting name. That was the biggest thing for me.

It has a GH Actions compatible rubber system too.

Funny how Microsoft products tend to instill blindness over time; refocusing on git hooks (and not the UI) can offer some perspective.

Forge, Gitea, and git itself contains a cgi script with quite a bit of functionality. And of course, the way it is supposed to work, git-over-ssh, as in give committers Linux shell accounts on a shared machine, with the CGI script running for pretty pictures (Remember CGI? You know, "cloud functions" before such a thing existed)

Huh, I should make an Apache plugin that launches docker exported containers uploaded into a directory.

Why a shared machine? Git was “supposed” to work with email. Do that.

That would be a huge downgrade for most users.

So is managing a shared Linux central repository…

I'm a contractor so have worked on a lot of different projects for different companies, big and small and also early startups.

This is far from truth imo. It is very possible to only use (F)OSS. Github, AWS, Azure, Vercel are not at all more pleasant or easier to work with than on-prem Gitlab/gitea/codeberg/jenkins/k8s/kibana/prometheus/grafana.

I could spend an hour and have a full setup done on physical or VPS to have 1) remote git hosting 2) pipelines running on changes 3) pipelines publishing images or some artifacts 4) automated deployment for these images/artifacts

I'm struggling to see what am I missing. What is worthwhile that Github offers? It is popular and easy to set up org+repos, but that seems it. A few years ago I was working on Azure Devops with the azure pipeline and that was the worst developer experience I've ever had. AFAIK Github actions uses the same syntax and works the same way, at least it was at that time.

What you're missing is maintenance, security, scaling, and protection from data loss.

Bespoke CI is easy to build but no one wants to be in charge of rolling out a critical security patch to that on-prem box no one's touched since that consultant from 2 years ago.

Your CI has to be fully codified, stateless and possible to redeploy with a single command. That's the only way it can remain sustainable. No persistent hidden state, no manual configs (even as an option!) and automatically rebuilt on every release as the new version is deployed.

As a really big bonus, that also makes your CI testable.

In the previous job, we built such a thing: https://smarketshq.com/building-a-reproducible-ci-system-for...

Yes, totally agreed in theory, and it sounds like y'all built a great solution for your use case. But it takes substantial effort and discipline to do something like that at scale.

At some point, you develop complex interdependencies with other systems. You need sophisticated caching for optimum build performance. Techniques like GitOps are unsustainable at a certain number of engineers/commits per hour.

ah that point gha is not much of an help anyway

>I could spend an hour and have a full setup done on physical or VPS to have 1) remote git hosting 2) pipelines running on changes 3) pipelines publishing images or some artifacts 4) automated deployment for these images/artifacts

This sounds like a week or two of work to me (I'm a novice though). You should write a guide.

on the other hand, a better user experience is something open source projects can aspire towards as a pure goal, with no perverse incentives pulling them the other way. a lot of the recent github changes have degraded the user experience because that was overall more profitable for the company.

> DIY is great for hobbyists and the cash-strapped.

And the companies with specific needs (funnily enough, at the other end of the cash spectrum) or have a lower internal cost than the products out there.

There's more of them out there than we give credit for I think. In particular, running one's own stack on the corner seldom makes the news.

LOL. You can do GitLab hosting with High Availability at a very professional level without needing a huge team.

And I hope ours does too. We're on Gitlab with runners on AWS at the moment, and the overhead is huge. Thousands of working hours spent on setting up and maintaining the infrastructure (even if it's code and probably a fraction of what our own datacenter would involve), millions in costs, hundreds of jobs spinning up to do jobs.

But also, many hours spent building jobs and the like that are off-the-shelf on Github Actions.

This is the main issue though, it feels like doing anything but what the largest companies offer just costs more time and money. It reminds me of the decades long push to move away from Microsoft, only for e.g. the office 365 offering to show up and make everyone's (software, account management) work easier and cheaper, forever.

Well, what else can we say? Enjoy your unilateral price increases or features shoved down the throat (CoPilot anyone?), with exactly 0 extra money in your pocket. Unless you are a C-level, of course.

> later moved to GitHub

And had to live with their constant outages :)

Blender does it

How does Forgejo compare here? Would it be better or worse than Gitlab? How about a self-hosted Sourcehut instance?

Lots of businesses can't put sensitive work product onto external servers. You just don't work for them.

Yours is a fairly cynical take, if realistic. It's true that hosting a forge or code repo is fairly complex and doesn't move the needle for most businesses, but…

As a CTO at a small company, I chose to self-host key infrastructure or picked small players to avoid tech giants. Perhaps there'll be more businesses like that, where decision makers put their money where their mouth is.

GitHub isn’t even good, it’s just the mediocre default everybody uses. PRs were fantastic and the best thing ever - 15 years ago!

Just curious - what do you think the current best git platforms are?

Azure DevOps is the gold standard for Pipelines.

That's not saying much, since it's still dependent upon the untyped mess that is YAML.

YAML is just a data format. Make your own "thing" that takes input in any format you desire, then dump it to YAML. (also, YAML is dynamically typed, and supports explicit typing, but the parser can choose to ignore it)

these days we generate yaml out of cue

i don't know why it's not more popular.

if only they supported ed25519 ssh keys

AD is just sourcesafe/tfs/vsts with rebranding, each time trying to get rid of the bad reputation in developer circles.

Really?

I grant you pipelines are the best bit about ado, but the fact that you can’t test them is a pain.

And the webhooks and templating are pretty messy and unpleasant quickly.

We’re changing from ADO to GitHub (had to be an MS product for corporate) and the infra people are looking forward to GHA as they prefer their maintenance to ADO pipelines.

git

What ever happened to Hudson/Jenkins? That was the full featured CI/CD solution before github actions.

I'm not at all a fan of GitHub actions, but come on, Hudson/Jenkins was a nightmare world, GitHub actions is a million times better

Jenkins is in every way a “Java” program, and not the good kind.

What you can say for it, is that it was free and near infinitely hackable.

I use Jenkins every single day, and have been using it my entire career through three different companies self hosting it.

Please tell me how we somehow have been hobbled despite having simple and clear pipelines setup that autobuild any branch we want and allow one click deploys to our preprod environment and automatically manage versioning and scalably handle load from "Literally zero" to "Everyone in the company wants to rebuild everything now" and goes down less than github.

What are we supposedly missing?

More importantly, what are we missing that tangibly improves results for our consumers?

Assuming all those three were post-Jenkinsfile, it’s pretty decent.

Multibranch is still weird and obviously added-on.

Writing plugins is ugly.

Working with Jenkins CasC, JobDSL and declarative pipelines, I'm not sure where the million times comes from. Sure, there are some annoying parts, and GHA has the social network for reusable actions, but apart from that it's not that different.

Oldschool maven type jobs where you type shell script into a `<textarea>`? Yeah, let's not talk about those, but we don't have a single one left anymore.

Jenkins Groovy is awful and full of footguns. Have you ever run into a serialization exception?

It's too powerful and there are too many of its implementation details exposed to the user.

I haven't seen a serialization exception, but I have run into plenty of footguns with YAML (ref GitHub Actions).

The DSL semantics can be weird with when things like params/env expansions in options block are evaluated.

That also is/was awful. But it's just another platform like GHA, and the solution to this kind of thing is always the same, should not be surprising, and is boring in the good way. Write automation so that it's not tightly coupled to the platform on the backend. If you can't migrate between platforms then you're eventually going to be unhappy.

If someone is forcing you towards high stakes tight-coupling with no thought whatsoever towards the lock-in, you should get it in writing that "we at ${org} are fully committed to ${vendor} with ${platform}, on ${cloud} using ${tech} come what may, now and forever" and lots of sign off so that everyone knows who to blame when this is inevitably wrong.

Without trying to sound snarky: What is the fancy alternative you are suggesting to pull requests?

Something like Gerrit. Instead of carefully crafting a logical series of patches that are all well documented with commit messages, PRs are just garbage filled diff soup of "fix typo" commits. I hate it. It's hard to review and seems to be based on putting the least amount of effort into proposing changes to the code. See https://gist.github.com/thoughtpolice/9c45287550a56b2047c631...

Well but this is controllable, i.e. it is people who choose to do this not the platform. Very much an internal design choice.

That's down to culture and (self) discipline, not tools.

It's not entirely, because Github simply does not support inter-version diffs when you have multiple commits. If you force push onto multiple commits there is no way to show a diff between version 2 and version 3 of those commits. How Github lacks such basic (and imo necessary) functionality in 2025 is amazing to me.

Something like linked and dependent PRs in a chain would go someway to replicating Gerrit but again this basic functionality is not available out of the box for whatever reason.

100% don't understand why people think github actions are terrible.

everything else is trash.

Github Actions changed the landscape.

They're composable.

The only two other things that come close is Concourse.CI and CircleCi.... and circle-ci is 100% trash

Versioning sucks (the references are mutable), debugging sucks, you cant run them locally.

Pin the action's version via a digest and use Renovate for updates.

You can run all your CI locally if you don't embed your logic into the workflows, just use CI for orchestation. Use an env manager(Mise, Nix etc) to install tooling(you'll get consistency across your team & with CI) and call out to a task runner(scripts, Make, Task etc).

> You can run all your CI locally

if you can, you don't need CI. we can't (too slow, needs an audit trail)

I think the idea is GitHub actions calls "build.sh", or "deploy.sh" etc. Those scripts contain all of the logic necessary to build or deploy or whatever. You can run those scripts locally for testing / development, or from CI for prod / auditing.

Yes this is what I meant! If you structure it correctly using task runners and an environment manager you can do everything locally using the same versions etc. E.g.

```yaml name: Continuous Integration (CI)

on: pull_request

permissions: contents: read

jobs: formatting: name: Formatting runs-on: ${{ matrix.architecture }} strategy: matrix: architecture: [ubuntu-24.04, ubuntu-24.04-arm] language: [rust, shell, python] steps: - name: Checkout code. uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1 - name: Setup Nix. uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0 - name: Check formatting. run: nix develop -c make check-${{ matrix.language }}-formatting

  linting:
    name: Linting
    runs-on: ${{ matrix.architecture }}
    strategy:
      matrix:
        architecture: [ubuntu-24.04, ubuntu-24.04-arm]
        language: [rust]
    steps:
      - name: Checkout code.
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Setup Nix.
        uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
      - name: Check linting.
        run: nix develop -c make check-${{ matrix.language }}-linting

  compile:
    name: Compile
    runs-on: ${{ matrix.architecture }}
    strategy:
      matrix:
        architecture: [ubuntu-24.04, ubuntu-24.04-arm]
    steps:
      - name: Checkout code.
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Setup Nix.
        uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
      - name: Compile.
        run: nix develop -c make compile

  unit-test:
    name: Unit Test
    runs-on: ${{ matrix.architecture }}
    strategy:
      matrix:
        architecture: [ubuntu-24.04, ubuntu-24.04-arm]
    steps:
      - name: Checkout code.
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
      - name: Setup Nix.
        uses: cachix/install-nix-action@4e002c8ec80594ecd40e759629461e26c8abed15 # v31.9.0
      - name: Unit test.
        run: nix develop -c make unit-test

... ```

oh that makes sense. I thought the OP was suggesting running CI locally instead of a workflow on remote runners

Github Actions is a cobbled together mess. It is mainly based on Azure DevOps Pipelines and still has some glaring bugs and wildly inefficient parts.

If it works for you, great. But it is far from being good.

We use Gitlab for CI/CD and tbh it is amazing. Simple, predictable, debuggable.

This whole thread is various people saying "[This] is trash, [that] is awesome", with the next person claiming the opposite. I suspect most people with strong negative opinions here know enough to have felt the pain, and not enough to be able to properly reason about the system.

I've worked with Github Actions, Gitlab-CI and CircleCI in the last 10 years, and they've all been such an improvement over Jenkins, or god forbid, CVS with manual deployments, that I'm generally just counting my blessings.

For me the pain only came when not adhering to KISS. All the mentioned VCS are pretty much feature complete and only really differ on meta-topics (cost, license, lock-in) or niche topics (Actions marketplace, matrix builds, SSH on Runners). I've not yet run into an issue that would have actually blocked me, because there's always sh to fall back to in case of a bug or missing feature.

I think I agree with you that:

- everything else is trash.

- Github Actions changed the landscape.

- They're composable.

And I still hate github actions! Aside from anything else, they have one major flaw, which is there is no good development/test loop for writing them.

If you write most of your CICD in some kind of script, then you can run it locally, and do some basic checks around environment etc before deploying.

If you write most of your CICD in github actions or any alternative, you will be doomed to push 100 commits with messages like "maybe be?", "hmmm. . ." before eventually squashing them all down when it turns out several hours later that you mispelt an environment variable.

top tip: make a repo in your org for pushing all these nonsense changes to, test out your workflows with a dummy package being published to the repo, work out all the weird edge cases/underdocumented features of Actions

once you're done, make the actual changes in your real repo. I call the test repo 'pincushion'

We call ours "bombing-range"

We maintain an internal service that hosts two endpoints; /random-cat-picture (random >512KB image + UUID + text timestamp to evade caching) and /api/v1/generic.json which allows developers and platform folks to test out new ideas from commit to deploy behind a load balancer in an end-to-end fashion, it has saved countless headaches over the years.

a display of great wisdom, nice

Thumbs up on Concourse CI: I like seeing all my builds at once on any easy-to-read dashboard. That’s why we switched from GitHub actions: the dashboard.

GitHub Actions are amazing ! For a public repository who will give you a free machine to run for 6 hours at a stretch for a job !!

This thread is largely commentary on the technical aspects of GitHub Actions.

The fact the business gives away free compute is irrelevant and more a discussion of their marketing budget.

Not to defend this behaviour, but a lot of clouds SaaS do require you to pay for both ”management” and for the actual resources. And if you’re using vms in their cloud, you pay twice.

For example, Azure has had a script runner service for ages that you can hook up to your ”own” vm, by installing an agent. But then you pay double, the fee (per second) for the service as long as the script is running, and the fee (per second) for the vm in azure as long as it exists. So, as with GitHub actions, it’s cheaper to run it on their provided crap instances.

To get rid of the double costs I guess you could install your own CI server and agents, that polls the GitHub repo, but then you don’t get the integration in their web gui. That was what you did before gh actions came around, a local Jenkins for example.

> alternatives that were inferior

Actually there were alternatives that were far superior (seriously, no way to group projects?) but also more than 2x as expensive. If GH "fixes the glitch" then it will be plan B time.

What are these superior alternatives? Never could stand GitHub and I'm suffering GitLab at the moment.

It's not my money man. It's still fine.

That not-your-money is still going towards rewarding user-hostile decisions

No ethical consumption under capitalism. My phone has minerals in it mined under slave-like conditions.

I'm all for everyone going full Libra - we do it at my co-op - but it makes sense to me that venture funded companies would "play the game" and light investor money on fire because, first, who gives a shit, and second, the investors want you to do that anyway so they can find out as fast as possible if you're a unicorn.

At my co-op, I spend hours writing future proof code and integrating FOSS solutions that I hope will serve us forever. When I'm at a startup, I'm looking for the fastest, maybe cheapest solution. YC gave us 200k in AWS credit? Guess we're on AWS. Another company in the cohort is some LLM IDE ala cursor and gave us a year free? Sure, burn tokens their investors are paying for, more agents for me. Vercel offers us a year of free hosting? Great, I hate nextjs but Claude loves it so fuck it, we deploy a nextjs app on vercel and lock ourselves deep into that ecosystem. Our product may not look like this at all in a year so I may be rewriting it in Vue or whatever when the vercel bills start coming in. Doesn't matter.

“not my money” thinking will always indirectly lead to bad things for you on a long enough timeline.

Edit: this got flagged, but if you end up in an unprofitable position because you chose Oracle as a vendor and they squeezed your company so hard they need to choose between paying you (either via a raise or via actually employing you) or staying with a vendor thats squeezing them; they will choose the latter, as its short term cheaper.

I think you can take it too far and spend a lot of time worrying about nickel and dimes for someone who doesn't care... github is unlikely to eat a business and if it does you made some bad choices.

Otherwise you make the call, maybe the company changes their business practices for the worse, maybe they don't ... it's not like you can ever be sure about that.

There's always been this lesson with CI/CD - don't couple yourself to a specific product. If you do, you're gonna get screwed eventually. It happened with TravisCI, CircleCI, now it's happening with GitHub. The business model only makes sense if you can charge for it, those charges are only ever going to go up.

I use Gitea and think it is superior to GitHub. Can be quite well integrated in the usual Microsoft corporate environment easily as well, so you don't even need to create users. Perhaps setup two or three groups and you are done. Can be up and running in a few little hours if you start with nothing aside your domain controller.

It also doesn't randomly fail and if it would, you can probably fix it yourself.

I don't think actions on a git repository host is a good way to fix poor deployment strategies if it goes beyond pushing a package to npm and co. Just to poke at the wound again.

But Gitea has interfaces here as well, didn't try them though.

I don't understand how once these companies go down the user hostile hell-hole... like why do we allow them to keep operating?

How is there not a collective decision to dissolve them?

haven't logged into GitHub since they added mandatory 2FA

Same here, my commit history chart makes people think I suddenly died on October 21, 2023, going from all green to all white.

Bitbucket also implemented 2FA, but it's 100% optional, so I'm sticking with that for the moment.

I deleted my account the day Microsoft acquisition was confirmed. If more people did that, maybe we wouldn't be here.

Whatever your issues with the price, this comment is truly wild. When you’re using commercial PyCharm, you’re paying JetBrains to “run their software on your hardware.”

paying for the time the debugger is active would feel bad though.

A one-off software license (or even a subscription) is completely different. The issue is metered billing for something you are paying for already which costs the company nothing. The equivalent is not only paying a flat monthly fee to Adobe for access to Photoshop, but also an additional charge for how long you have it open on your machine every month.

I’d like to introduce you to Oracle and many software companies pre-SaaS that were charging per core.

If I recall correctly, Atlassian’s CI product also charged you for parallel jobs back in the day. And businesses were paying it because they felt it gave them value for money.

it's just software.

it changes and you move on.

Takes like these do not account for the value you gained by using the software in the meantime. Here are 2 scenarios:

1) company uses exclusively free software, spends more time dealing with the shortcomings of said software than developing product, product is half baked and doesn't sell well, company dies.

2) company uses proprietary but cheap/free (as in beer) software that does the job really well, focuses on developing product, product is good and sells well, company how has a ton of money they could use to replicate the proprietary product from scratch if they wanted to.

A purist approach like in scenario 1 leaves everyone poor. A pragmatic approach like scenario 2 ends up earning enough money that can be used to recreate the proprietary software from scratch (and open-source it if you wanted to).

In this case the problem isn't even the proprietariness of the software, it's the fact that companies are reliant on someone else hosting the software (GH being FOSS wouldn't actually change anything here - whoever is hosting it can still enforce whatever terms they want).

FOSS alternatives already exist, it's just that our industry is so consumed by grifters that nobody knows how to do things anymore (because it's more profitable for every individual not to); running software on a server (what used to be table stakes for any shop and junior sysadmin) is nowadays lost knowledge. Microsoft and SaaS software providers are capitalizing on this.

> A purist approach like in scenario 1 leaves everyone poor.

That depends, not always. Sometimes the employees of said company manages to contribute back upstream, on the dime of the company. If the "free software" they used and contributed to have a lot of users, it's certainly not "leaves everyone poor" but rather "helps everyone, beyond monetary gain".

Sure, you can make the argument that it isn't that great for the company, and you may be right. But the world is bigger than companies making money, killing a few companies along the way to make small iterative steps on making free software for absolutely everyone is probably a worthwhile sacrifice, if you zoom out a bit.

Even purely from an altruist perspective I’d argue scenario 2 makes more sense as the resulting money can be used to fund a lot more open-source contributions.

Could in theory is very different from what actually happens.

In the end the purists approach results in better more productive software across even slightly longer timescales. That ultimately produces more value and thus a richer society than the kind of short term pump and dump schemes which SV is so fond of. Who captures that value is a different story than was that value created.

yeah, I think ~all of open-source-funding-history stands as evidence opposed to #2, a la https://xkcd.com/2347/

It could, but would it? For-profit companies usually don't suddenly turn around and start funding FOSS, unless that was part of their core mission from the start. If a company aims to make as much money, then that tends to be the mission they stick with, for better or worse.

or alternative hire right people that know what they are doing and don’t need a whole lot of junk to work on and deploy. I have been coding 31 years now and don’t have the slighest clue why anyone would ever need a “github action”

There's value in enforcing checks on the server side to avoid people accidentally/maliciously merging code that doesn't pass said checks. Checks can be linters, security scanners, etc.

> Checks can be linters, security scanners, etc.

The first checks I setup are build and test. The rest is “extra”.

why on the server?!

Because then you protect against a compromised/misbehaving developer workstation. No matter what the individual developer does, the server will prevent a PR being merged if it doesn’t pass the server-enforced checks.

Running builds on a designated server would also protect against malware on a developer’s machine silently embedding itself into the resulting artifact and then deployed to production.

This was probably the question to ask before declaring it all as junk.

Your scenarios seem to hinge on OSS having lots of warts while proprietary software is perfect.

In reality you have to also make concessions with proprietary software, so the moat is not as large as your comment makes it seem imo.

The first part is wrong, it’s a question of org size. A lot of large orgs hand roll a lot of these things, they call it developer excellence.

And your last paragraph hits the nail on the head, people are afraid to run their own software.

While I agree with the spirit of your statement "people are afraid to run their own software", I feel like this assumes that people are the ones choosing the software they run. I wish my teams could run more things ourselves, but are told no by our systems and infrastructure staff.

Any self hosted service in an enterprise means that you're dealing with all the headaches that come with that including: backups, user/role creation and mapping maintenance, infrastructure scaling needs, OTEL or other monitoring, etc.

It's an easier decision for VPs to pay GitHub anything less than the man hours required to execute the above tasks because it's a "not our problem" fee.

Perhaps our industry should adopt a different approach, that fills in the gap between those.

- You host open-source software on your own hardware.

- You pay a company for setup and maintenance by the hour.

Have any suggestions to those community-developed and maintained options?

Gitea. Gitlab (ish?).

GitLab actually implemented Actions first back in the day (called CI/CD). I remember GitHub was following their lead.

Which is funny reading how TFA tries to feign ignorance:

> When we shipped Actions in 2018, we had no idea how popular it would become.

Gitea scales really badly with large repos in my experience. Gitlab works a lot better mostly because you can just throw more hardware at it. This is with a pretty large git repo and a lot of daily commits.

On the other hand, gitlab is a memory hog. You need a big vm dedicated to it.

We were on codeberg for a couple years and it was fine.

Yeah Gitlab is a pig, but that’s what I meant with you can throw hardware at the problem. I’ve been meaning to check out Codeberg for personal project hosting since it seems to address the shortcomings of gitea

You can also just use Gitlab Cloud but setup as many self hosted runners as you like.

GitLab scales much better horizontally than it does vertically.

4x 4c/16gb instances will perform much better than one 16 core 64GB instance.

>Gitea scales really badly with large repos in my experience.

Isn't it written in this super scaling language that everybody says scales super well?

What is the problem with it?

I honestly don't have any issue paying the self-hosted runner fee. Paying it and counting it against our total allocated minutes when we bought the machine is going too far though.

> Now it is paying money for running their software on your own hardware.

(facepalm)

Reply on news.ycombinator.com