Hacker News Reader

Comment by skhameneh | Hacker News Reader

I've been a proponent of upstreaming fixes for open source software.

Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do.

Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.

I have a very distinct recollection of talks about hardware aspirations and upstreaming software fixes at a large company. The cultural response was jarring.

View on HN

As yet, Valve is the only company I know of doing this, and it's paying off in dividends both for Linux and for Valve. In just 5ish years of Valve investing people and money into Linux- specifically mesa and WINE, Linux has gone from a product that is kind of shaky with Windows, to "I can throw a windows program or game at it and it usually works". Imagine how further the OSS ecosystem would be if Open Source hadn't existed, only FOSS; and companies were legally obligated to either publish source code or otherwise invest in the ecosystem.

> Valve is the only company I know of [upstreaming fixes for open source software]

Sorry, that's ridiculous. Basically every major free software dependency of every major platform or application is maintained by people on the payroll of one or another tech giant (edit: or an entity like LF or Linaro funded by the giants, or in a smaller handful of cases a foundation like the FSF with reasonably deep industry funding). Some are better than others, sure. Most should probably be doing more. FFMpeg in particular is a project that hasn't had a lot of love from platform vendors (most of whom really don't care about software codecs or legacy formats anymore), and that's surely a sore point.

But to pretend that SteamOS is the only project working with upstreams is just laughable.

Sure, but the parent’s comment hits on something perhaps. All the tech giants contribute more haphazardly and for their own internal uses.

Valve does seem somewhat rare position of making a proper Linux distro work well with games. Google’s Chromebooks don’t contribute to the linux ecosystem in the same holistic fashion it seems.

From my time working at a Fortune 100 company, if I ever mentioned pushing even small patches to libraries we effing used, I'd just be met "try to focus on your tickets". Their OSS library and policies were also super byzantine, seemingly needing review of everything you'd release, but the few times I tried to do it the official way, I just never heard anything back from the black-hole mailing list you were supposed to contact.

Yes, I've also worked on OpenStack components at a university, and there I see Red Hat or IBM employees pushing up loads of changes. I don't know if I've ever seen a Walmart, UnitedHealth, Chase Bank, or Exxon Mobil (to pick some of the largest companies) email address push changes.

Those aren’t tech giants. They're just shit companies. I agree they greatly outnumber Big Tech, in employees if not talent.

Check again. The Optum unit of UnitedHealth Group has huge revenue from software and technical services. If just that part of the business was spun out it would be one of the top 20 US tech companies.

too bad UnitedHealthGroup is capital-E Evil and is literally running the "death panels" that insane right wing propaganda tried to scare us about

What a lot of people don't realize is that it's mostly employer HR departments running the "death panels". UHG and its competitors would be happy to sell insurance policies that cover absolutely everything with no questions asked: this would be easier for them to administer without the hassles of utilization management and claim edits. But customers — mainly large employers — demand that insurers (or third-party administrators) impose more restrictive coverage rules in order to hold down medical costs.

Ultimately there will always be some healthcare rationing. This happens in every country. For example, the UK NHS has death panels which decide that certain treatments won't be covered at all because they're not cost effective. Resources are limited and demand is effectively infinite. So the only real question is how we do the rationing.

> UHG and its competitors would be happy to sell insurance policies that cover absolutely everything with no questions asked...But customers — mainly large employers — demand that insurers (or third-party administrators) impose more restrictive coverage rules in order to hold down medical costs.

UHG has been caught denying claims for things that employers already paid them to cover for their employees. You can't blame HR departments for that. You also can't blame HR for UHG upcoding/overbilling which eats into the limited resources of hospitals and the limited resource of taxpayer money ultimately resulting in fewer people able to get the healthcare they need just so that UHG can line their own pockets.

While HR departments do have their own issues, they're nowhere near the level of pure evil that UHG is.

Walmart is a tech giant.

FWIW, when working at a major Silicon Valley tech company in the mid 2010s, my team made significant contributions to OSS projects including OpenStack and the Linux kernel as a core part of our work for Walmart.

The work to upstream our changes was included in the Statements of Work which Walmart signed off on, and our time spent on those efforts was billed to them.

The stats for those projects will have recorded my former employer as the direct source of those contributions - but they wouldn't have existed had it not been for Walmart.

I don't know about ExxonMobil but Walmart, UnitedHealth Group, and JPMorganChase employees do actively contribute to open source projects. Maybe just not the ones you used. They have also published some of their own.

https://github.com/walmartlabs

https://github.com/Optum

https://github.com/jpmorganchase

To steelman this: I've never worked at any of the companies you listed but most likely Red Hat and IBM employees (Is there still a difference?) are being paid specifically to work on Openstack, as they get money from support contracts. When Walmart of Chase use Openstack there is a rather small team who is implementing openstack to be used as a platform. They are then paying IBM/Redhat for that support. There probably isn't really the expertise in the Openstack team at Warlmart to be adding patches. Some companies spend a different amount of money on in house technology than others, and then open source it.

Credit to wine and cross over (?)for years and years of work as well

I'm glad you threw in "I know of", because that part is true.

Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.

Can't you just give the information you are hinting at? Other people than OP read this. You basically tell me to go read thousands of messages on a mailing list just solve your rhetorical question. (answer: Intel, Redhat, Meta, Google, Suse, Arm and Oracle. There are much more efficient ways to find this.) Yes, they are the main kernel contributors and have been for many years. I'm still not sure I understand the comment.

https://lwn.net/Articles/1038358/

I think GP answered as they did because there are so many examples it's hard to know where to start.

It's not entirely unlike if someone said "the only person I know writing books successfully is Brandon Sanderson." I do think "you ought to go check out your local book store" would be a valid response.

No, "just" having to debunk BS from a BSer who lazily threw out misinformation is not the way to go. It's the BSer that needs to do more work.

I'd say as a counterpoint that just because someone works at, say, Meta or Oracle, and also contributes to OSS projects, that doesn't equate to the company they work at funding upstream projects (at least not by itself).

I don't even have to link the xkcd comic because everyone already knows which one goes here.

Well, if they use their work email, doesn't that mean their kernel work is endorsed by their employer?

People don't use their company email addresses for private work.

Linus does...

At GOOG you’re required to, by policy.

Everyone I know who contributes to Linux upstream is paid to do it. It's not really worth the hassle to bother trying if you weren't getting paid. It's also very easy to find companies that will pay you to work on Linux and upstream.

They totally broke CSGO Legacy's code to push its sequel CS2 and won't accept fixes for it because it's 'not being supported'.

To be clear, both of those are closed source, proprietary games owned by Valve. It makes sense for them to want to consolidate their player base in one game.

https://github.com/ValveSoftware/csgo-osx-linux/issues/4047

Valve is so successful because it is a private company, and the CEO is the CTO and he is essentially the corporate equivalent of a religious monk. How else can you get 20+ years to slowly build a software business?

As a side note YC and tech startups themselves have become reality TV. Your goal should be Valve! You should be Gabe Newell! You don’t need to be famous! Just build something valuable and be patient

> How else can you get 20+ years to slowly build a software business?

It used to be normal to build a business slowly over 20 years. Now everyone grabs for the venture capital, grows so fast they almost burst, and the venture capital inevitably ends in enshittification as companies are forced by shareholders to go against their business model and shit over their customers in order to generate exponential profit margins.

Steam is the most dominant game tool on the planet and landed when there was not yet a market for it. Very few other projects will get to the level of success it has in any sector, anywhere.

GabeN was also a MS developer back in the day and likely would have been well off regardless, but he didn't need to play the YC A-B-let's-shoehorn-AI bullshit games that are 100% de rigeour for all startups in 2025.

From what I understand, Gabe/Valve almost went bust during Half Life's development. His gamble paid off when that turned into a runaway success, but he still could have lost it when he bet again on HL2 and Steam; at the time it was extremely controversial to make those a package deal. If Half Life 2 had been not quite as good as it turned out to be, it could have turned out to be a studio with a one hit wonder that burned their goodwill with some sketchy DRM sort of scheme on their second game.

Ironically, Gabe is more famous than the rest of whoever you're talking about, not because he seeks fame but just because he generally does right by his customers and makes himself accessible. Telling gamers to email him with questions, concerns, comments, anything, and then actually responding. Even though he's apparently spending most of his time hanging out on yachts, people love him because he makes an effort to be tuned in to what his customers want. If you do that, you'll be famous in a better way than what you can get from reality TV.

WINE was a thing for years and generally worked okay for a lot of things.

I was playing Fallout 3 on WINE well before Valve got involved with minimal tweaks or DIY effort.

Proton with Steam works flawlessly for most things including AAA games like RDR2 and it's great, but don't forget that WINE was out there making it work for a while

> WINE was a thing for years and generally worked okay for a lot of things.

Yes, but Valve's involvement handled "the last 10% takes the 90% of the time" part of WINE, and that's a great impact, IMHO.

Trivia: I remember WINE guys laughing at WMF cursor exploit, then finding the exploit works on WINE too and fix it in panic, and then bragging bug-for-bug compatibility with Windows. It was hilarious.

Also, WINE allowed Linux systems to be carrier for Windows USB flash drive virii without being affected by them for many years.

But this is a perfect example of one of those "90/10" esque ideas.

Even if Wine was 90% there technologically, the most important 90% is really that last 10.

WINE, CodeWeavers, Mesa, Red Hat, and plenty of others have been pumping money into the Linux graphics subsystems for a very long time. It's cool that Valve was able to use its considerable wealth to build a business off of it. But they came in at a pretty opportune time.

Windows support had gotten a boost from .NET going open source as well as other stuff MS began to relax about. It also helped that OpenGL was put to rest and there was a new graphics API that could reasonably emulate DirectX. I don't know much about the backstory of Mesa, but it's pretty cool tech that has been developing for a long time.

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.

I’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better.

What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount of time we lost to trying to appease a few maintainers who were never happy with code unless they wrote it themselves was mind boggling.

For some projects you can basically forget about upstreaming anything other than an obvious and urgent bug fix because the barriers can be so high.

While there's sometimes maintainer-prima-donna egos the contend with there's also this:

Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they will not be able to maintain the functionality into the future (because no one on the maintaining team has experience in a certain field, for example).

The quality bar for a 'drive by patch' which is contributed without the promise of future support is ridiculously high and it has to be. Other peoples' code is always harder to maintain than your own so it has to make up for that in quality.

Not any patch. Sometimes there are patches that are not explicitly fixing defects, but for example they surface a boolean setting that some upstream library started to expose. That setting is exactly like a dozen other settings already there. It's made using the same coding style and has all requisite things other settings have.

Will you be still making a fuss over it?

Maybe, it depends!

Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way.

Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work? I'm not your employee. Your product doesn't put a roof over my head.

I don't want a job where I do free work, for a bunch of companies who all make money off my work. That's a bad deal. Its a bad deal even if my code gets better as a result. I have 150 projects on github. I don't want to be punished if any of those projects become popular.

We can't go around punishing projects like ffmpeg or ruby on rails for the crime of being useful.

I don't know.

The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life.

Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism, and polarization, I just as increasingly want to have no part in them most of the time.

I think many projects would be better for having a lane for drive-by contributors who could work on fixing bugs that prevent their day-to-day from working without expectations of becoming full-time engaged. The project could set an expectation that "we will rewrite your patch as we see fit so we could integrate and maintain it, if we need/want to". I wouldn't care as long as the problem is taken care of in some way.

Being allowed to contribute to open source is a privilege, not a right.

You could also just pay for it.

“Pay my way or take the highway” is as close to the closed-source ethos as you can possibly get. Collaboration is not feasible if the barrier of entry is too high and those involved make no effort to foster a collaborative environment.

Yes, because with a closed source you can also just download the source and add your own patches and maintain your own fork... /s

Most open source projects have way more patches contributed than the core developers can handle, so they tend to only accept those from the friendliest contributors or with the highest code/documentation quality.

Thanks, I prefer that job where I am paid for writing code, not having to pay to write code.

In my experience simple bugfixes are nearly always accepted without fuss (in active projects, that is. Some project in maintenance mode where the last commit was 3 months ago is a different story, because then probably just no-one can be arsed to look at the patch).

Some simple setting expose like you describe can sometimes go in without a fuss or it can stall, that depends on a lot of factors. Like the other reply states: it could go against future plans. Or it could be difficult for the maintainer to see the ramifications of a simple looking change. It sucks that it is that way (I have sent in a few patches for obscure CUPS bugs which have stayed in limbo, so I know the feeling ;-) ) but it is hardly surprising. From a project's point of view drive-by patches very often cost more than they add so to get something included you often need to do a very thorough writeup as for why something is a good idea.

> I just as increasingly want to have no part in them most of the time. If all people you meet are assholes.... ;-P Not to say you are an asshole, or at least not more than most people, but I have been in this situation myself more than once, and it really pays to stay (overly) polite and not let your annoyance about being brushed off slip through the mask. The text-only nature of these kind of communications are very sensitive to misinterpretations and annoyances.

It would be nice if all you'd need for a patch to be included somewhere was for it to be useful. But alas there's a certain amount of social engineering needed as well. And imho this has always been the case. If you feel it gets increasingly hostile that's probably your own developer burnout speaking (by do I know that one :-P )

> Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work?

Then say you don't expect contributions at all. That's a fair game, I'm ok with it. I will then exercise my rights granted by your license in another way (forking and making my own fix most likely). My gripe is with projects that write prominently "PRs welcome", and then make enough red tape to signal that nah, not really.

> The amount of time we lost to trying to appease a few maintainers who were never happy with code unless they wrote it themselves was mind boggling.

That brings us full circle to the topic because one important thing that gets people motivated into accepting other people's changes to their code is being paid.

If you work in FOSS side projects as well as a proprietary day job, you know it: you accept changes at work that you wouldn't in those side projects.

In the first place, you write the code in ways you wouldn't due to conventions you disagree with, in some crap language you wouldn't use voluntarily, and so it geos.

People working on their own FOSS project want everything their way, because that's one of the benefits of working on your own FOSS project.

I've literally had my employer's attorneys tell me I can't upstream patches because it would put my employer's name on the project, and they don't want the liability.

No, it didn't help giving them copies of licenses that have the usual liability clauses.

It seems a lot of corporate lawyers fundamentally misunderstand open source.

Corporate counsel will usually say no to anything unusual because there's no personal upside for them to say yes. If you escalate over their heads with a clear business case then you can often get a senior executive to overrule the attorneys and maybe even change the company policy going forward. But this is a huge amount of extra unpaid work, and potentially politically risky if you don't have a sold management chain.

Sounds like your employers attorneys need to be brought to heel by management. Like most things, this is a problem of management not understanding that details matter.

Why would they invest resources - scarce, expensive time of attorneys - in researching and solving this problem? The attorneys' job is to help the company profit, to maximize ROI for legal work. Where is the ROI here? And remember, just positive ROI is unacceptable; they want maximum ROI per hour worked. When the CEO asks them how this project maximized ROI, what do they say?

I believe in FOSS and can make an argument that lots of people on HN will accept, but many outside this context will not understand it or care.

If you fixed something in an open source library you use, and you don't push that upstream, you are bound to re-apply that patch with every library update you do. And today's compliance rules require you to essentially keep all libraries up to date all the time, or your CVE scanners will light up. So fixing this upstream in the original project has a measurable impact on your "time spent on compliance and updates KPI".

That is a real benefit, I agree.

This touches on what I ended up telling them: maintaining a local patchset is expensive and fragile. Running customized versions of things is a self-inflicted compliance problem.

I still had to upstream anonymously, though.

I don't know if it would work, but sometimes I consider a "moochers" rule wrt opensource code.

Like, here's the deal: The work is proper, legit opensource. You can use it for free, with no obligations.

But if your company makes a profit from it, you're expected to either donate money to the project or contribute code back in kind. (Eg security patches, bug fixes, or contribute your own opensource projects to the ecosystem, etc).

If you don't, all issues you raise and PRs get tagged with a special "moocher" status. They're automatically - by default - ignored or put in a low priority bin. If your employees attend any events, or join a community discord or anything like that, you get a "moocher" badge, so everyone can see that you're a parasite or you work for parasites. Thats ok; opensource licenses explicitly allow parasites. I'm sure you're a nice person. But we don't really welcome parasites in our social spaces, or allow parasites to take up extra time from the developers.

I've spent the last 32 years pushing every employer I've had to contribute back to open source. Because of the sector I work in, more often than not I'm constrained by incredibly tight NDAs.

I can usually stop short of providing code and file a bug that explains the replication case and how to fix it. I've taken patches and upstreamed them pseudonymously on my own time when the employer believed the GPL meant they couldn't own the modifications.

If after all that you still want to label me a moocher at cons, that's your choice.

You can wear your secret cape with pride, don't worry about the moocher badge.

It goes even further sometimes, I've seen someone in the Go community slack announce they are going to dial back their activity because of Very Serious Clauses in their Apple contract.

That seems to imply that Apple employees are prohibited from being good internet citizens and e.g. helping people out with any kind of software issue. This presumably includes contributing to open source, although I'm sure they can get approval for that. But the fact they have to get approval for it is already a chilling effect.

Apple? Not interested in being a good internet citizen? Say it ain't so!

I upstreamed a 1-line fix, plus tests, at my previous company. I had to go through a multi-month process of red tape and legal reviews to make it happen. That was a discouraging experience to say the least.

My favorite is when while you were working through all that, the upstream decided they need a CLA. And then you have to go through another round of checking to see if your company thinks it's ok for you to agree to sign that for a 1 line change.

Certainly easier to give a good bug report and let upstream write the change, if they will.

In this scenario does your employer have strong controls around what whether you can write hobby code on your own time?

Generally yes. Or yes, you could just do it yourself in your free time.

Even at places that are permissive about hobby code, a company ought to want to put its name on open source contributions. These build awareness in the programming community of the company and can possibly serve as a channel for recruitment leads. But the (usually false) perception of legal risk and misguided ideas about what constitutes productivity usually sink any attempts.

It is amazing how companies want this "marketing" but don't want to put the actual effort to make it possible.

A tech company I worked at once had a "sponsorship fund" to "sponsor causes" that employees wanted, it was actually good money but a drop in the bucket for a company. A lot of employees voted for sponsoring Vue.js, which is what we used. Eventually, after months of silence, legal/finance decided it was too much work.

But hey it wasn't an exception. The local animal shelter was the second most voted and legal/finance also couldn't figure it out how to donate.

In the end the money went to nowhere.

The only "developer marketing" they were doing was sending me in my free time to do panels with other developers in local universities and conferences. Of course it was unpaid, but in return I used it to get another job.

This is what I've done in those rare cases I've had to fix a bug in a tool or a library I've used professionally. I've also made sure to do that using online identities with no connection to my employer so that any small positive publicity for the contribution lands on my own CV instead of the bureaucratic company getting the bragging rights.

One of my past employers in the UK added to the policy all the software the employee writes during the employment (eg. during the weekend, on the personal hardware), is owned by the company.

Several software engineers left, several didn't sign it.

Yes, company was very toxic apart of that. Yeah, I should name and shame but I won't be doxxing myself.

Many years ago an employer tried to to that and everyone .. just refused to sign the new contracts. The whole thing sat in standoff limbo for months until the dotcom crash happened and the issue became moot when we were all made redundant.

I found a tiny bug in a library. A single, trivial, “the docs say this utility function does X, but it actually does Y”. I’m not even allowed to file a bug report. It took me some time to figure out how to even ask for permission, and they referred it to some committee where it’s in limbo.

My team lead once approved me upstreaming some changes to a open source project, so long as I did it using my private account.

Basically I got to do the work on company time&dime, but I couldn't give my employer credit, due to this kind of legal red tape.

I liked that teamlead

Maybe I've just gotten lucky, but at companies I've worked for I've usually gotten the go-ahead to contribute upstream on open source projects so as long as it's something important for what we are working on. The only reason I didn't do a whole lot as part of my work at Google is because most of the open source projects I contributed to at Google were Google projects that I could contribute to from the google3 side, and that doesn't count.

interesting, checking the git history of FFmpeg, google has approximately 643 contributions

    git clone https://git.ffmpeg.org/ffmpeg.git
    cd ffmpeg
    git log --pretty=format:"%ae" | grep -E "chromium\\.org|google\\.com" | wc -l

prints 643

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it...

True. In my case I literally had to fight for it. Our lawyers were worried about a weakened patent portfolio and whatnot. In my case at least I won and now we have a culture of upstreaming changes. So don't give up the fight, you might win.

It would probably be easier for these companies to pay Collabora or Igalia.

> Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.

I sympathize and understand those issues for small companies, but after a certain size those excuses stop being convincing.

Especially for a software company like Google who runs dozens of open source projects, employs an army of lawyers to monitor compliance, and surely has to deal with those issues on a daily basis anyway.

At some point there needs to be pushback. Companies get a huge amount of value from hobbiest open source projects, and eventually they need to start helping out or be told to go away.

This is why all open source software should be copyleft. No discussion to be had: either you upstream changes, or that open source developer's going to get funded via the courts.

Reply on news.ycombinator.com