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