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.

▲

embedding-shape 6 days ago | parent | next [-]

> 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.

▲

Nextgrid 6 days ago | parent [-]

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.

▲

Retric 6 days ago | parent | next [-]

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.

	▲	Groxx 6 days ago \| parent [-]
		yeah, I think ~all of open-source-funding-history stands as evidence opposed to #2, a la https://xkcd.com/2347/

▲

embedding-shape 5 days ago | parent | prev [-]

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.

▲

Novosell 6 days ago | parent | prev | next [-]

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.

▲

bdangubic 6 days ago | parent | prev | next [-]

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”

▲

Nextgrid 6 days ago | parent [-]

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.

▲

bdangubic 6 days ago | parent | next [-]

why on the server?!

	▲	Nextgrid 6 days ago \| parent \| next [-]
		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.
	▲	franklyworks 6 days ago \| parent \| prev [-]
		This was probably the question to ask before declaring it all as junk.

▲

Cyph0n 6 days ago | parent | prev [-]

> Checks can be linters, security scanners, etc.

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

▲

ic_fly2 6 days ago | parent | prev | next [-]

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.

	▲	jerdthenerd 6 days ago \| parent [-]
		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.

▲

philippta 6 days ago | parent | prev [-]

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.