To be honest, I think the real issue with OSS is the whole masquerading of acting like a corporate project and almost red tape attitude that some maintainers have that can block a PR for weeks or months.
Unless you are a very important client who is paying money to the maintainers or unless the project is OSS but let's say, backed by/open sourced by a company like Google (as in, not some unknown person who kind of answers to no one) the chances of meaningful contributions landing are effectively zero.
If you are a client of a given library working for "Unknown company 8965688" and you are using a library and make a PR with a change you need or request it, in my experience, you'll simply be ignored.
Then comes the original post: we'll fork the library to an internal repository, make it our own, and stop depending on the whims of the maintainers who care absolutely nothing for the people who request features precisely _because they are actively using the library_ and need an improvement.
OSS has become a really, really bad place to be when it comes to actively depend on something that is managed by someone who simply doesn't care about you in the slightest.
Then, as we have people competent enough in the technology, forking becomes the natural thing to do.
Merging that PR can take a lot of time for testing, and also risks locking in some feature into the project, which the maintainer does not need or use, but they're now stuck supporting (owning) from here on.
Typical conversation:
- contributor: I need feature X for my big client, it's super important, please support it.
- maintainer: interesting, I'm not familiar, but I'll take a few hours to review. Can you help maintaining it? write tests? help fix other bugs?
- contributor: no. corporate does not allow me to. I am too busy, have other paid projects to work on, why would I do things for free?
Don't get me wrong, everything I do is FOSS, but it's easy to be brunt as a maintainer.
Why do maintainers owe you support? I assume by your comment that you're a company, in that case, since you're making money off the value added by that OSS project, financially support the developers to get support in return. Then you can act entitled :)
I often have to use open source projects in my work (Backend Software Engineer), there are projects that are popular, many of them backed by companies themselves and there are small one-person projects.
As an engineer/developer, you may have an issue with one of these libraries, tools, etc and you'll put in a ticket with all of the details your development expertise can coax out; sometimes you'll get responses of thanks for a clear report, sometimes you'll be ignored, and other times they'll disagree or be unwilling, and now you're stuck.
You'll go to management and ask if they'll pay said company/developer to fix it and they might, or they might not.
You either look for an alternative, write something yourself, or you fork it internally, fix the issue and move on; now you and your peers have another piece of code to maintain because nobody on either side of you would budge.
I've never been abusive to an OSS developer, I've certainly been frustrated, and I'm an FLOSS advocate myself.
Some projects I've worked with, and I won't name names, have turned around fixes in literally an hour, are greatful for a good thorough report and want their software to work for you (and I'm talking large internationally used enterprise grade tools), and others will just be rude or dismissive, but you still have to solve that problem, it's your job.
When I have a job to do I'll just move on from projects that make it harder, and I'll advocate harder for the projects that make it easier, if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits.
There are other projects that are larger, and we pay them decent recurring sums to be able to ask for a fix or feature to be turned around quick, and it'll end up in their open source code, so everyone benefits from that money this company spent.
When you're a small start-up developer you have far fewer options available to you compared to a large company who can or will throw money at people inside and out to get things done.
>if it's small and generally unmaintained, we'll just fork internally, improve 8t all we want and move on, now nobody in the wider community benefits.
Everyone can still benefit, just make your private fork a public one. Of course you now have the same problem as the original maintainer in that people will make requests of you or fork it
Exactly, they're just posting code, but, simultaneously, if they put it in the public domain, they probably expect that the code will be used by others and from that moment, well, they are at least responsible for replying to PRs or close the ones they don't care about merging.
Once it's public and gains "customers" the responsibility grows a bit, otherwise don't post it at all publicly, after all, if you're not going to care about real world use cases, it's just as valuable as any toy project that hasn't seen the light of day.
This type of almost "passive gatekeeping" is the reason why we've formed several OSS projects we rely on. Yes, we incur maintenance burden but the predictibility gained is Invaluable.
A project being backed by a major company like Google is no guarantee of a well run project. For one project by Microsoft employees on GitHub, they don't appear to even read issues or trivial PRs.
Unless you are a very important client who is paying money to the maintainers or unless the project is OSS but let's say, backed by/open sourced by a company like Google (as in, not some unknown person who kind of answers to no one) the chances of meaningful contributions landing are effectively zero.
If you are a client of a given library working for "Unknown company 8965688" and you are using a library and make a PR with a change you need or request it, in my experience, you'll simply be ignored.
Then comes the original post: we'll fork the library to an internal repository, make it our own, and stop depending on the whims of the maintainers who care absolutely nothing for the people who request features precisely _because they are actively using the library_ and need an improvement.
OSS has become a really, really bad place to be when it comes to actively depend on something that is managed by someone who simply doesn't care about you in the slightest.
Then, as we have people competent enough in the technology, forking becomes the natural thing to do.