[account42]

If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you:

> This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.

(from the zlib license, but others have similar disclaimers)

If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them.

If you don't then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or "fix".

[stupidcar]

As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Nor can you force your employer to negotiate a contract with the maintainer.

Don't get me wrong: I'm not arguing the maintainer has any responsibility to fix your issue. I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. Their choices are constrained by factors outside their control, and they are under pressure to deliver. It's this pressure that explains some of the frustration and anger that can bubble up in open source discussions.

I don't think there's an easy solution, but more empathy on all sides might be a start.

[hypfer]

> As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in.

Well y'know... you're kinda being paid for that. That literally is your job. You're given money to deal with that.

It is not a matter of "empathy" for a FOSS maintainer to do your job for you.

[ricardobeat]

I would like to know which universe everyone here lives in, where such scenario is a possibility. Let’s say you use Kubernetes. A transitive dependency that does DNS resolution in a built in module is doing something wrong, like not resolving hosts ending with the letter X. You can’t “refactor to remove the dependency”, you can’t realistically maintain a fork of the whole thing. This is what the majority of these situations look like. OSS is supposed to be a collaborative environment where everyone can contribute a little, not a “fuck you, pay me” environment.

[vinceguidry]

Our team does do cutting-edge work with Kubernetes, and we run into this situation quite literally all the time. How do we handle it? We're being supported by a multi-billion dollar business and we have the resources and talent to a) code around the deficiency, b) pivot to find something new, c) get in touch with our contacts at Google, actually use those enterprise support contracts we pay $$$$$ for, or d) make our own stop-gap solution. Every single one of these we've employed at various steps in the last few years.

Where you're mistaken is in not understanding the difference between FOSS and Enterprise OSS. You're describing a collaboration environment that can and should be present in FOSS. (but sadly often isn't) With OSS... you better have your checkbook ready. It very much IS a "fuck you, pay me" environment, and if you don't have the cash, you really shouldn't be messing around with Enterprise OSS. Use, and support, Free, by that I mean copylefted, Software. Build on Proxmox, not on K8s.

FOSS is a software commons, Enterprise OSS is a giant collection of walled gardens. You have to pay me to maintain Enterprise OSS. I'd maintain FOSS for free. You can't apply the dynamics that underpin FOSS to Enterprise OSS. Enterprise OSS is not written for you. You're not its target market. Enterprises want as much as possible to offload the massive costs, so they fund software foundations like the CNCF and the Apache project to do the core dev work so that teams like mine can have a stable base to build on and relative career stability.

[MangoCoffee]

>OSS is supposed to be a collaborative environment where everyone can contribute a little

OSS coders doesn't owe you anything if they don't want to be collaborative. you already getting the code for free. you are paid to deal with these Open Source software. you can always buy the commercial software if Open Source is not doing what you want.

> not a “fuck you, pay me” environment

i don't understand. if OSS coders offer an pay option. why shouldn't they get pay? you get paid to deal with Open source software by your employer, no? you get to eat 'cause you get paid to deal with Open source software, no? why shouldn't OSS coders get to eat too? only you get to eat but not them?

[ctrlmeta]

> OSS is supposed to be a collaborative environment where everyone can contribute a little, not a “fuck you, pay me” environment.

This is a gross misunderstanding of what open source is. Please read the licenses that come with the OSS software you use. The authors and maintainers do not owe you anything beyond what the license says.

[jamie_ca]

I read that sentence as "where everyone can contribute a little [to the overall ecosystem]". Absolutely maintainers don't need to accept your contribution of a patch, and that's what forking is for - both are part of the overall banner of open source licensing.

[ricardobeat]

Who said anything about “owing”? If you write a book and I send you a note correcting something in it, you’re right - you don’t owe me shit, but it would be pretty nice to get a response. I find these views extremely cynical, a little niceness works both ways.

[ctrlmeta]

Since you agree that the maintainers don't owe us shit, we are on the same page. I guess I took issue with this -

> OSS is supposed to be a collaborative environment

OSS is supposed to be what the OSS authors and maintainers want it to be for their project while satisfying the terms and conditions of the license they have chosen for their project. It does not have to be a collaborative environment. Yes, it will be great if it is. Many authors just don't have the time to do collaboration after they have made the initial few releases. But that does not stop others from collaborating on it or forking it and improving it.

I am sorry if this sounds cynical. That's not my intention at all. I genuinely like that the open source licenses gives a lot of rights to the user while also including disclaimers that the author is not responsible for troubles you face with the software. Far from being cynical, I find it very beautiful actually. It allows the authors to be creative and publish software when they can without worrying too much about support and maintenance. Of course it would be nice if the authors also support and maintain the software and many authors do but it is good to know that it is not necessary and the licenses say so too.

[jacobr1]

You don't maintain a fork of the whole thing. You maintain a patch, ideally of an isolated area and now pay for the cost of maintaining the integration/sync of that patch until upstream merges or otherwise fixes the root issue. Depending on issue you can do this in basically clean, or ugly-hack kind of way.

[asoneth]

At the end of the day, everyone must eat and put a roof over their heads.

Someone who uses an open source project in the course of their paid employment doesn't have standing to accuse volunteer maintainers of being overly motivated by money.

[sebastianz]

Then do not use kubernetes, if its complex enough that you cannot afford it as a dependency, with all that entails.

[powerhour]

OSS used to be more collaborative but these days it is corporate to the point you have to sign a damned contract to get a contribution merged. I am not owed better, I am just sad for what we lost.

[account42]

Did we actually lose anything? Projectes that used to be collaboratively developed in the open are still being collaboratively developed in the open and as far as I see that is also the case for most new projects. Except those that are mainly developed by a signle corporation, often with a commercial offering - but having these in addition to more collaboratively developed projects ins't really a loss.

[brudgers]

OSS isn’t supposed to be anything other than what the license says.

[hampereddustbin]

If commanded, sure, but in many cases your job would actually be to communicate the changing environment to management so they may allocate more resources or pay the maintainer or whatever middleman company to upkeep the required software.

Silently trying to plow through problems of these magnitudes will cause the project to be late and still cost the same. It's bad for everyone

[jstummbillig]

It's really simple: Harassing people, who explicitly waived liability in a manner that agrees with the law, is never an okay strategy. That is not to say it can't be very attractive in the face of personal adversity or be very effective, in getting you what you want. Just it's never okay.

I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume?

[alibarber]

I simply cannot fathom the idea of harassing someone publicly on the internet to deal with a professional issue I face.

In fact, at every company I've ever worked for, damaging the company's reputation by doing that would have lead to far more serious issues at work than just finding a workaround and documenting it well - and then, if suitable, contributing back to the project with something helpful.

[hampereddustbin]

>I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume?

There are a lot of people on this site. Some of them may think differently than others, there is no way to fuse them into a single persona.

[jstummbillig]

But that is exactly what we do by upvoting, statistically. There is a body of prior work to look at. Our collective stance on oss or mass surveillance is clear, and you can infer the resulting upvotes with certainty, statistically (might actually be a fun game).

The spirit of hn has clear biases and it's not equally open-minded towards all ideas.

[marcus_holmes]

this. As a dev, this is not your problem. If you had a dependency forced on you, and that dependency has issues that the maintainers are not willing to deal with, then escalate the problem to your manager.

Of course, if you included a dependency because you thought it was a good idea, and it turns out to not be a good idea, then that's a different problem. You'll have to let management know that you'll need some time to refactor the code to remove the dependency. That could be a difficult conversation, but the answer is still not "hassle the maintainer to fix my problem"

[briantakita]

> "hassle the maintainer to fix my problem"

Who is proposing that it's a good idea to hassle the maintainer? Most of these interactions go awry when someone decides to be an asshole. The tone of the article which says "fuck off" demonstrates the interpersonal impulses at play here.

Choose who you rely on wisely & try not to get into bad situations. If the maintainers of project x have an ill disposition toward the community, then consider it a red flag.

[keybored]

The hypothetical FOSS maintainer is giving a new meaning to “kill them with kindness” in this thread.

[swatcoder]

> frustration and anger

The root problem in your story is that your developer doesn’t feel like they can safely convey to their manager that the project has unexpected constraints. That form of intimidation happens, sure, but it’s not very nice to bring random strangers into the drama of your poor work environment.

If you have a shitty manager that you can’t communicate with, the maintainer doesn’t deserve to become the outlet for your frustration and anger, do they?

There’s a classic story of the workee coming home and taking out his work problems on his wife, who takes it out her marital problems on their kids, who take out their problems on the pets.

It’s meant to help you see that shuffling your problems on other people doesn’t solve problems and instead just makes other’s lives worse.

[BowBun]

Another take: Maybe many of us in software have enjoyed a long run of productivity driven by open source availability. That productivity is now baked into many software cultures (who doesn't assume they can use industry standard libraries, outside of very sensitive environments?) and an expected part of what programmers can do.

Imagine turning around 40 years in and telling business folks "Oh crap, actually we're only 20% as effective because we've been ignoring glaring security, maintainability, and social issues around FOSS that we've simultaneously benefited from for decades".

Feels like some golden handcuffs to me!

[pc86]

> I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies.

The whole point of this article is that these are your three options.

What are you saying the fourth option is? It sounds like you're just saying "yeah but this isn't good because (for example) nobody will merge my random bug fix into React core." That's sort of the point - your options then are #2 or #3.

[peteradio]

#4:

Integrate your patch+tests into your build process and don't bump on every external lib revision. Maybe that's basically forking, but what would be the issue with doing this for an OSS project dependency?

[jacobr1]

Yes - this is the answer (if you can't work with upstream). There are many variants to this: monkey-patching, vendoring (local fork), micro-libs that replace a subset of functionality, wrapper libs, etc ...

[civil_engineer]

Yes. This is the happy path. But also submit the patch, of course!

[lanstin]

This is what I do. Sometimes maintainers eventually fix it and sometimes they don't. i am happy when they do of course, but work is fine either way.

Of course i make it a point myself to view each dependency as a significant cost and to work seriously to minimize them. I used to version pin or vendor in the deps, and then subscribe to the security announce DL for all deps, and avoid insane things like npm or mvn, but that has become more difficult and having a conmercial dep scanning service in your CI makes mvn or npm safe enough, but it remains true that code dependencies are a long term cost. for personal stuff, i would rather take OSS code I find and take the few hours it takes to modify it into my standards, leaving attribition, assuming the license allows of course. copy, modify and recombine.

[chris_wot]

The LibreOffice project in effect does this in a number of libraries.

[chris_wot]

If a bug fix with test coverage sits in a queue for years, just because the maintainer is an arsehole, then a bit of mild criticism should probably be expected.

Consider it a fixed fork fuck you.

[pc86]

The "just because the maintainer is an arsehole" thing is the question here. How many times is it really just because the maintainer doesn't like the person who submitted it, or they just laugh to themselves and want to see how angry people get? I'd venture a guess to say almost never.

The issue becomes when folks assume it's just the maintainer being a jerk rather than any number of completely valid reasons, which could be anything from "PRs from employees and core contributors are prioritized and we can barely handle those as it is" to whole way to "I don't think this feature fits in with my larger vision for the project."

It is almost never "just because the maintainer is an arsehole."

[chris_wot]

There could never, ever be an Ulrich Drepper who maintained a project the size and importance of glibc in any project, ever.

[chrisseaton]

> then a bit of mild criticism should probably be expected

No they’ve every right to ignore your PRs for any reason or no reason at all. You aren’t paying them.

You can ask them to merge but you’ve got no basis to criticise them because they never promised you anything.

[chris_wot]

In that case, I guess forking the project to fix it whilst criticising them is disallowed?

[chrisseaton]

Can I ask you to send me $100 and then criticise you when you don’t? Or is that an unreasonable criticism since why on earth should you send me any money?

[chernevik]

The point of the comment is that "fix it" isn't an option when the maintainers won't even look at your bug fix.

I'm VERY appreciative of FOSS but it does seem that if you are going to maintain a project then it isn't unreasonable to expect that you'll at least consider a PR, and give some reason if you choose to reject it.

[peteradio]

Not to saturate this thread with my varying opinions, but default rejection with reasoning of stability could be assumed. Anyone who has worked in code long enough knows seemingly obvious changes can have unintended consequences. If a company is making money off my FOSS code then maybe they can test their fixes for an eternity before I incorporate it and it potentially breaks some other companies code.

[tpoacher]

Just because it's the whole point of the article doesn't make it true.

In the corporate context of the particular person you're replying to (rather than the general case of an isolated disgruntled user), there are infinitely many options. The above are just the ones 'desired' by the author in their ideal world. Perhaps this could be the unwritten 4th F: "Fight dirty".

You could, for instance, go down the litigation route until shit falls your way. Or pay random shills to post articles twice a week on how React isn't what it used to be because of this bug. You could convince the twittersphere that this particular bugfix is offensive and should be hashtagged. You could pay people to spam their github with issues that are effectively that bug and waste enough developer time until they decide that not fixing that bug is costing them more time than it does to fix it.

If your company C-team feels this is simply a matter of economics and happy to pay the 'cost', these are totally valid options.

And while the author of this blog does have a point and I sympathize, they'd better be prepared to face the consequences of resorting to the 3rd F too quickly when they do. The world is not all peaches and roses out there.

[zaphar]

Anyone who chooses option 4 has a high chance of becoming a pariah. It is also equivalent to option #3 for the author. He's just going to ignore you and his projects are probably going to ignore you. The only person option #4 hurts is you.

The correct thing for any reasonable engineer to do is transparently communicate the impact of those previous decisions to their management. The framework/library/system we chose no longer supports our needs in this instance. We can either workaround it, maintain a fork of it, or replace it. The costs of doing each of these is X. What do you want to do.

Fighting dirty is unlikely to accomplish getting your feature out the door.

[shadowgovt]

Any company that embraces option four should consider that the door swings both ways. Convince the developer providing the free service that it's not worth their time and you have bought yourself a free ticket to becoming the new maintainer or becoming content with your product being based on a rotting dependency.

Option 5, "find cash to pay for maintenance," is a much better option than option four for a corporation to consider.

[sbuttgereit]

For the maintainer in the scenario it is precisely that simple. For the client developer sure, they might be in a tough spot not directly of their own making but their difficult position does not somehow convey any responsibility at all to the maintainer... not even a responsibility to be sympathetic, empathetic, or kind. Any action by a frustrated developer against the maintainers at this point, any harassment whatsoever, might be explainable by the developer's situation but would not be in any way justified by it.

The developer's problems are just not the maintainer's in any way and any attempt to harass the maintainers into being responsive would be unethical. Full stop.

[mpol]

In that case you could maintain a set of patches for upstream, instead of going for a full fork. You could document how much time you spend maintaining those patches and communicate that to your manager. If it is still cheaper to maintain that set of patches and not pay upstream, I guess that is a business decision that might financially work out.

[swiftcoder]

"paying upstream" is fine for little independent open-source projects, but for the big popular dependencies it doesn't actually work. You can't just pay Google to work on Android/Chrome, or pay Facebook to make changes to React...

[mpol]

Using software from Google or Facebook, it should have been known when making that decision that there is no influence you can have on those. These companies are run by psychopaths.

I do understand your point though, there will be many other software projects where the same issue is happening. I guess maintaining your own set of patches or doing a full fork are then the options. Or refactoring.

[samsquire]

> and they are under pressure to deliver.

You're being paid to deliver and the maintainer is not. This is a critical fact. The maintainer did their bit, it's time to do yours.

> but more empathy on all sides might be a start.

More empathy for the _maintainers_ I think.

[ricardobeat]

> it’s time to do yours

And how is fixing a bug and submitting the patch not doing your part? This is what OSS is all about.

[samsquire]

It isn't that's it's not doing your part, it's that to think they are equal amounts of work, time, value and money.

Creating the Linux kernel is different to packaging an upstream Dependency. Or fixing a bug in a dependency.

You effectively owe the maintainer again for the work they do reviewing your work. Something that takes them away from their free time and other issues.

Sure both are hard and valuable but they are not equal difficulty or value.

The company earns money based on the revenues produced by the software that uses the maintainers product. That money goes to you as part of your wages and you think a bug fix is enough to compensate for the maintainers additional time for looking or merging your bug. Do you see now how that might not be reasonable or fair? Your balance debt to the maintainer is negative even after your bug fix. Especially given money is involved so it's doubly negative.

You also need to think of the time and money the maintainer spent in addition to the work to produce the initial product. So there you are even more indebted to the maintainer.

[ricardobeat]

You’re looking at this as a one-sided transaction. The distinction between producers and consumers is not clear cut, especially if you consider only the subset of developers who submit patches.

In reality, unless they run their own handwritten OS, the roles are going to be reversed next week, where that maintainer benefits from the other person’s work (and salary as you say) through another piece of software. This is the premise of free software. Each contributes what they can, everyone benefits.

[blowski]

This all comes down to "no silver bullets" and "there are no solutions, only trade-offs".

You can have codebase x for free, but depending on future changes is risky, especially if it's close to your core. A larger team are likely to be more stable, but be less amenable to any specific changes you want. You can fork the code, or provide patches, but this adds extra complexity you'll need to manage.

[lallysingh]

Sounds like that developer inherited a problem at work and wants to make it someone else's problem. Solving those problems is part of their job.

[hampereddustbin]

This issue would be above the developer's paygrade.

It's not the developer's job to make requirements fit in the timeframe, that would be the manglement's job. If execs have made bad decisions with regards to the developer's input on what it's going to take, the problem is solely on them.

[gpvos]

That's a rather idealized view. In practice, management has more than enough ways to make it the developer's problem. Of course, that may mean it's time to leave.

[MuffinFlavored]

> If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you:

I don't want to say "easier said than done" but... imagine doing `npm install` for like... Webpack, React. Start adding a few React related libraries

You're talking exposure to... hundreds (thousands) of "free" open source projects.

Obviously nobody owes anything to anybody in terms of "let me dedicate my free time away from my family/friends/my other hobbies/my personal sanity" to make sure the package I publish online is as perfect as possible. It just gets muddy/gray.

Is there a sense of entitlement for the unpaid generosity of library providers? Almost surely. "You published something, it got popular, now you are telling everybody who needs help fix it yourself or f*ck off".

It's just a weird source of conflict. People publish packages hoping they get used/become popular. Then they got popular and get overloaded by issues/requests and either embrace it or get combative.

[danwee]

You are right, but in practice that's not what happens. Companies do not rely on open source libraries, the developers working for such companies do.

I can give you a realistic example. If you want to use Kafka and Go, your probably only option is to use https://github.com/confluentinc/confluent-kafka-go. Its LICENSE explicitly says "no warranty". Now, what if I find a bug in the library? Only two realistic solutions from my side:

1. I submit the issue and hope for the maintainers to fix it

2. I dig deeper and try to fix the issue. I submit the PR

None of the above scenarios are guaranteed to have a happy ending. The issue could be ignored, or piled up among thousand of other (maybe higher prio) issues. My solution may not be optimal and could be rejected (or if it's optimal, nobody is taking a look at it, and it could remain open for weeks/months).

> If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them.

In the real world that would mean that I go to my manager and asks them to pay money to the maintainers of confluent-kafka-go to fix the issue I found. I don't think my manager would approve that, but let's imagine he does. The guys at confluent-kafka-go may not want money to fix the issue. These guys have probably already jobs that pay them well, and they work on the library at will.

Note: I'm talking about confluent-kafka-go, which I know is behind the Confluent software company. But I could as well be talking about libraries maintained by individuals like https://github.com/edenhill/librdkafka

[hampereddustbin]

If paying the maintainer is not possible, you can always pay some third party or hire more people internally to maintain the required libraries. If the company chooses not to pay anyone, it's a risk they brought upon themselves.

[xerxes901]

In the specific case of confluent-kafka-go I’ve had to make extensive use of the second F. Trying to get the major improvements I’ve made into upstream has been… challenging.

Of course that F comes with a substantial maintenance cost. I’ve moved onto other projects internally at work and still every month or two I’ll get roped in to deal with some confluent-kafka-go releng issue or some such.

Tried giving them money too but confluent were pretty explicit with us that go was a low priority client library for them. I guess I’m not really saying anything other than I agree with everyone else in this thread, there’s no magic answer, only tradeoffs.

[guelo]

One of the tragedies of the popularity of Open Source is that companies have become used to not paying for software dependencies. Back in the 90s when I got started it was much more common. In fact companies liked paying because that contract usually came with real life support from the vendor, and that was seen as peace of mind.

[the_duke]

That's still often the case in enterprise environments. There's a reason companies use Openshift instead of plain Kubernetes (despite it being a bloated mess), or Redhat over Debian, or Sqlserver instead of Postgres, ....

[2muchcoffeeman]

But then it’s too bad right? Why should the maintainers care?

[ricardobeat]

Because you release open source software to help others, in the same way others have helped you with theirs. Where has all the empathy gone?

[zaphar]

I sometimes release software under an OSS license. I sometimes take patches from people. Other times I reject them because it's not the direction I want to take the project.

I sometimes use software under an OSS license. Sometimes I submit patches for fixes and they get accepted after appropriate amounts of reviews. Sometimes I maintain an internal fork for years before my fix lands. Sometimes I choose a different solution because my projects needs no longer align with the software's direction.

At no point do I ever think it's a great idea to bully an OSS maintainer into my way of thinking. I have all kinds of empathy for both groups but the rules of engagement here are very clear and anyone who thinks they should be different is just going to be hurt in the long run.

[lanstin]

I release open source software so other people can use my work if it would help them help themselves. The code took some work and its nice for it to be known, but i dont have time to help anyone with anything, what with a corporate job and kids.

the people expecting more seem to be saying it would be better not to release code that one has no intention of helping people with, but that world is strictly worse.

[ricardobeat]

Note that the baseline being discussed here, and in the article, is accepting a patch, not writing a bug fix or new feature yourself.

If every bugfix mandates a fork, the whole ecosystem becomes impossible. So the answer to you question is yes: unless you explicitly label something as a research project, one-time release, no patches welcome, we’re better off without it in the long run, as the sea of dead npm packages shows.

[lanstin]

I guess I was picturing just a GitHub, but for go, that is the same as npm. I have gotten excellent benefit from gists only and for that matter code on stack overflow.

Still I guess I regard open source as more like twitch broadcasts than shopping for shrink wrap. If some one wants to take patches and so on, great but that seems extra to just releasing the code. The fundamental advantage of code is that it is malleable. That gist might not fit my project but if it solves the problem I can meld it into what I need so fast.

And a lot of bug fixes aren’t really bug fixes per se but are extra use cases, so a fork per use case doesn’t seem so bad. And I guess the advice for “person that wants a popular open source project” might be different for “just wants as much code as possible to be part of the common knowledge of humanity.”

[pabs3]

I've had success asking for paid feature development on random GitHub projects the company I work for depends on. I had no involvement in the financial side of things though, just writing up the issues and verifying the results.

OTOH on another project where the company wasn't willing to spend money on commercial support provided by a company related to the project, they strongly tried to push us towards paid development even though I did extensive debugging on the bug we found and tried but failed to fix it myself due to the complexity of the codebase. Eventually they did fix the issue without paid support though, luckily in the interim we had a workaround.

[PeterisP]

What's wrong with option 2?

It doesn't matter if the PR is accepted, rejected or ignored, you have a working fix that you can legally use forever.

[fisf]

Funny. The repo you linked has a very explicit 3rd option: "Supported - Commercial support is offered by Confluent."

[morelisp]

Not really the point, but in case this is describing a real issue and not just a hypothetical situation: I've found sarama to be very responsive to bug reports and patches.

[lanstin]

once you have the PR, just point your code to your PR branc. it will be fairly easy to pick up changed from the main repo from time to time anyways.

Especially in corporations, do not make your project depend on things not under your control, or you will stop shipping.

[tremon]

This software is provided 'as-is', without any express or implied warranty

You're creating a distinction where there is none. Commercial software has the exact same disclaimer.