Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I confess, I'm an old guy, who was around when Open Source was still young. Being able to read the code, learn to be z better programmer, tweak it to my needs, control what was running on my machine.

Reading other comments on this thread it seems like the mood has shifted. Now there seems to be an expectation that Open Source means "you should promptly review and accept my changes".

There is much wailing that corporates (who, by the way, never used to release code at all) are somehow at fault for either existing, or not responding quick enough or requiring paperwork(!).

I'm not sure when pushing code upstream to Open Source became an entitlement. I'm pretty sure it wasn't there at the beginning and it's nor part if any license I'm aware of.





Well, there's a flip side of that, which is that all our critical infrastructure is now open source.

And if you're comparing where we're at now, culturally, with where we were at in the early days of the internet - John Postel, the RFC process, the guys building up the early protocols, running DNS and all that - there's been a different kind of shift.

The way I look at it is, a lot of us hackers (the category I'd put myself in), academics, and hardcore engineers who worked in industry but didn't give a damn about anything except doing solid work other people could rely on - we built up the modern tech stack, and then industry jumped to it as a cost cutting measure and it's been downhill from there.

And this puts us all in a real bind when the critical infrastructure we all rely on is dominated by a few corporate giants who still have the mindset that they want to own everything, and they only pay lip service to the community and even getting bug fixes in if it's something they don't care about is a problem.

This mindset invading the Linux kernel is a huge part of the reasons for the bcachefs split, btw. We had a prominent filesystem maintainer recently talking openly about how they'll only fix bugs if they feel like it or as a part of a quid pro quo with another established player - and that's just not OK. Open source is used by the entire world, not just Google/IBM/Facebook/Amazon.

"How we manage critical infrastructure as a commons - responsibly" needs to be part of the conversation.


But nothing stops you forking it right?

So, if you think a project is too corporate, then fork it.


If the code is any good, sure. Sometimes you gotta start from the ground up and show people how it's done :)

That wasn't the complaint. OP was trying to start the process to even be allowed to submit patches, but was stuck in Oracle's bureaucratic hell for a whole year.

If they didn't want his patches, they could have just said so, rather than stringing him along.

CLAs are a cancer.


Maybe you are saying this is an improvement over the old days, in that the corporations now at least accept open source contributions, even if they are slow at doing it. I think the contention is that corporations are not merely slow at handling open source contributions, but in fact they are a drain on those contributors time and goodwill because they are incompetent. The end result is that some contributors give up and go elsewhere, and corporate-backed projects lose trust over time.

It might have been better if Oracle just said "we don't have the bandwidth to handle open source and we don't want to waste your time, please submit your patches to this other fork and we will merge when we get around to it."


No, I'm saying that whether a project takes contributions or not has nothing to do with open source.

Yes, lots of projects big and small accept contributions. And lots do not. You might think that's good or bad, but it's unrelated to open source.

You are free to submit patches to whatever fork you prefer. If oracle don't suit you then submit somewhere else.

They. Owe. You. Nothing.


There’s also entitlement from just using it: my org uses your software and there’s what we consider is a bug so you MUST fix it as asap as possible and in the future don’t release buggy software because it costs us time and money.

Most of Meta's groups' approach to FOSS is throwing piles of sticks over a wall. They don't even check code can build, that it doesn't have some internal-only dependencies, and don't even care if they break other groups' code. The timeline for very minor bug can also be on the order of months to years because everyone working at the business is focused on shipping "impact" to keep their job when the next performance review/layoff round comes along.

And that's... fine. They're still giving away their code, and anyone is free to step up and mke sure that it builds or that internal dependencies are replaced.

And it's a completely standard situation for non-corporate open source software, too. OpenSSH, for instance, has OpenBSD-specific dependencies and can only be run on Linux because of the porting efforts by a separate group of volunteers.

Sure, it'd be event better if they went out of their way to facilitate external participation, but they don't have to. Not even GNU does so for everything they publish!


tl;dr: There's a spectrum of FOSS varying from performative crap to usable.

You're conflating the differing treatment of projects where there is much investment and community usability like react, ones that are half-assed like edenfs, and the zillions of others that aren't even explained clearly what they do or what they're for.

> anyone is free to step up and mke [sic] sure that it builds

On thrown-over-the-wall projects, there's too many inside-baseball gotchas and little/no documentation. Effort by others are generally unrealistic and a waste of time that won't be merged since there are rules and limitations for community contributions. The vast majority of tiny and obscure projects, MAANG code is useless to average people working on average problems because the burden to make it work is as much or more than reinventing it themselves.

> or that internal dependencies are replaced.

This is hand-waving away reality. No average engineer for reasonable effort is going to be able to reproduce an undocumented API for unreleased kernel extensions/FUSE/etc. for Mac, Windows, and Linux to make edenfs work.

Another case in point: Hack. No documentation and no portable build instructions/toolchain.

React and react native are in a different class where there is meaningful community participation and investment. Whereas hack, edenfs, and chef cookbooks is/was mostly thrown-over-the-wall stuff. There are a few projects in the middle like watchman that update code using an opaque internal->external export process without a whole lot of documentation or clear changelogs, but it's still semi-useful.

The spirit of FOSS is cheapened by flooding the zone with too much stuff on the side of crap. It's better to release less stuff that's well-supported with meaningful community engagement rather than create noise. But if you're fine with a blizzard of noise that isn't useful to anyone else, that's cool for you. Everyone is free to do what they want to do, even if it's trying to make partially-released stuff work when it would've been faster to rewrite from scratch.


I have similar thoughts.

Lots of people have to think about “just because you did the work, doesn’t mean it’s valuable for someone else”.


I'm very much from the same era, "stfu and fork it", "PoC or GTFO".

And as I got older, I realized "I am not the customer, there is no money in responding to me, I am a net negative cost to your business".

And uhh... I'll shuffle the F out now then? And try and catch-up on 200 years of math.

I don't think anything has changed IRL, aside from my knees hurting


"Self-service doacracy" rather than "look at me and fix my 'world-ending' problem for me for free right now". While I applaud creating patches and submitting them upstream, there's zero obligation to review or accept them... just throw them out there and let whatever happens happen in its own time.

It's my tailbone and an old torn back injury; I can't sit or stand for longer than 2 hours and I think I need to swap my Aeron classic size B for a C.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: