The actual advantage of open source is that you actually have access to the code, create a fork and maintain it yourself if things go south.
And btw: If using open source software is only an option when I know all the languages needed to write all the stuff myself, then the whole thing just lost its meaning.
I must ask, do you use Linux?
(Linus, notably: can be hard on maintainers, very respectful of userspace)
Yes, he is. But that's not because he has a duty to do so. It's because he chooses to, and because he can afford to so choose. If he stops doing it tomorrow, sure, a lot of people will have to scramble, but it's still up to him.
a) open source developers are obligated to provide their users with fixes to any bugs they run into, or
b) open source developers will never ever do anything for their users, so anyone who uses open source needs to be competent at maintaining and modifying all the open source software they use.
I hope you don't truly believe that, and assuming you don't, I hope you aren't arguing this way in bad faith.
Because neither of those things are true. Open source developers will often want to fix bugs in their software, and add new features that people find useful. A user need not assume they'll have to take ownership of everything they use and maintain it themselves. But an open source user has no right to demand anything from the developers. Sometimes the user will have to do their own work if they're having a problem, because sometimes those problems won't get addressed (either ever, or on a time scale that the user needs). And anyone who makes use of open source software should go into it with that understanding.
I've done that myself: I've adopted open source libraries at work (and for personal projects), have found issues with them, fixed the issues, and sent PRs to the maintainers (and maintained and used my own forks until those PRs were merged and new releases made). On occasion when bugs I've found seemed like they'd require too much deep understanding of the code, I've filed issues and provided as much information as I could to help the maintainer reproduce the issues. Sometimes those bugs got fixed, and that's great. But sometimes they didn't. That's frustrating, to be sure, but those maintainers had no obligation to me. From there, I had three options: a) dive in and take the time to learn the software well enough so I could fix the bugs myself, b) live with the bugs being present and decide that that will be ok, or c) drop that software and find or write something else that met my needs.
And all that above is what you sign up for if you decide to depend on someone else's open source work. If you don't like that, then you have two choices: a) write everything that you need yourself, or b) pay someone else for their work. That's it. You have no right to demand anything from any open source developer.
For any project that I maintain... anyone who comes in believing I'm obligated to do whatever unpaid work they want from me immediately gets banned from whatever communication channel they're using to make those demands.
The chances of the Linux kernel suddenly becoming completely unmaintained are so close to nil that it's not really worth considering.
But yes, if you're running something on top of Linux, and run into a kernel bug, you're of course free to report it, but the only guarantee is if you find and fix the bug yourself. None of those kernel developers are obligated to help you. In practice, many will want to help you! But that's not something anyone is entitled to.
I've worked at shops where there were people (myself included) who were capable of and occasionally had to dive into the kernel to fix issues. Often these were kernels coming from BSPs from some random chipset manufacturer, where the kernel was a year out of date and no Linux developer would want to touch it anyway. But even if we were running the absolute latest kernel version, we'd still probably dive in to investigate while reporting the issue upstream.
FWIW, here’s my actual view on this: there’s a great episode of the Oxide and Friends podcast where Brian & co. talk to Kelsey Hightower about Hashicorp changing the Terraform license to exclude a lot of companies in the TF ecosystem—the ultimate “we’re the maintainers we can do what we want” move. Kelsey has maintained many open source projects and understands the importance of maintainers having freedom to focus their energy where they see fit regardless of what the peanut gallery thinks.
His view, which I agree with, is that what is ultimately needed is upfront clarity from maintainers about how they’re going to govern the project. If you want to have complete control over your project and ignore bugs and pull requests as you see fit, and users need to accept the software as it is, that is fine and good, but put it in the README so that prospective users know what they’re getting into. If you want to have a community-driven governance structure where people have a path to getting involved and steering the project, like Kubernetes, that’s good too and you should lay all that out for users too. What Terraform did, where they cultivated community engagement in order to have this plugin ecosystem and then rug pulled those plugin authors by changing the license, “poisoned the well of open source” (his words) by giving the impression that OSS is inherently fickle and serious teams should be hesitant to use it because maintainers can and will break things carelessly. I worry that comments like the OP’s reinforce this impression.
Professionally, I am one of the developers of Pachyderm, which is an open-source version control and data pipelining tool.
If project members don't welcome that in an actively developed project, that they use themselves too, sometimes in fairly critical scenarios, then that's a bit incomprehensible.
I've found fairly serious crasher bug due to misuse of OpenSSL API in multiprocess context with shared memory and a race condition leading to use of unexpected pointer values in one SIP proxy project, that recently even commissioned a code audit, which lead me to thinking they care about quality of the code.
I provided analysis and a suggested fixes for both issues. More than month into this, no response from anyone related to the project. Thus:
1) It's fine, purely technically... I can apply my own patches, debug the project and fix issues.
2) It's concerning, because it makes the project less trustworthy to me. What other people's serious bug fixes just went into oblivion due to "issue autoclose" bot they use on github and are lingering in the codebase for no reason other than the fix author not wanting to prop up the issue by commenting on it every 7 days?
3) How many such devs just keep crasher and security fixes for themselves, because they realized the project owners are not very responsive, and expanding 2x the effort to describe the issue to someone else, rather than just fixing it for themselves and moving on, is not worth the additional effort.