It's the same issue with support as a software company. We have companies paying us $10k a month who "want us to consider something for future roadmap if other customers would also value it" and free users who "demand we fix (expected and documented behavior) IMMEDIATELY". The problem isn't open source, it's free.
And this can happen on HackerNews too! Here is a thread in the last week where 50% of posters from HackerNews were berating Microsoft for open sourcing all of VS code, but not open sourcing one of their free language servers (calling them selfish, anti open-source e.t.c.). I think this is the exact same sentiment.
So Microsoft open sourced all of VS Code, but didn't want to open source the Pylance language server (a separate product which is installed separately as an extension) which they provide as a free (as in beer). This is because Pylance is also used within their other (charged) offerings such as full Visual Studio and is a differentiator from their competition in the premium space. Also they have hinted that it includes some proprietary secret-sauce that they don't want to make public.
Bear in mind that Microsoft is making VS Code free and open source... here are some quotes from the thread:
> I find it what they are doing to be dishonest [...] the consequences of their actions is that people who dislike them will talk bad about them.
> [Microsoft] have the right to be two-faced about their open source policy, I have the right to speak about how I think it's bad to do so.
> They should please stop acting like they are the second coming of christ for open source [...] they are misleading their users.
> Microsoft proved that they only care for OSS [...] because it enables them to spy on coders and their code to develop proprietary and closed sourced spins for software development product. The OSS community got served.
> Microsoft always does this, they fool people by pretending they’re in favor of open source or make something free but it’s just a trick used to bait and switch people into the proprietary anticompetitive Microsoft ecosystem.
> Seems like Microsoft is back to pissing in the public pool.
To be fair, Microsoft has plenty of bad rep, stemming from decades of abusive behavior, to recover from.
Also, a megacorp is not a person (no matter what the law may say).
Being abusive towards individual developers should not be tolerated, but leveraging fair or unfair criticism towards an amoral entity? Eh, whatever floats your boat.
It's like when you give your old stuff away on Facebook/craigslist/gumtree - when it's free, you'll get very entitled people messaging you whether you can deliver it to them, or don't keep agreements. Asking for $5 removes 99% of the trouble.
Free users don't care if you tell them to fuck off.
The company paying $10k can't change vendor overnight so it's in their best interest to stay in good terms. Also in his company, the guy you're talking to don't want to be "the guy who pissed off that key vendor".
I second that. Once a vendor becomes important enough I even stop thinking of it as a vendor and rather as a partner that you interact with as if it was part of your own organisation. I am not amused when members of my team are rude to a vendor and jeopardise a relationship that took a long time to build. Even when you pay six figures a month, you can still get preferential treatment compared to other customers in the same tier when it comes to influence over the roadmap if you actively foster the relationship.
> Free users don't care if you tell them to fuck off.
You don't have to and shouldn't respond in any specific time period. Even if you're the sole maintainer of a critical project and you imagine the world wants your head, the world has to wait sometimes.
However, users may abandon projects where support tickets go untended, maybe even writing a post about it in the process[1], so try to respond when you can, unless you've abandoned the project.
As a representative for a FOSS project or even a bystander commenting on a PR, respond professionally and succinctly.
If you shouldn't accept a PR, don't.
If it's a request that seems hostile to the project, and you have time, either leave it for a little while to cool off, try to serve it with professionalism without getting off-topic, or at worst close it.
If needed, add a "code of conduct"[2] so that you can "encourage a pleasant and productive environment by responding to disruptive behavior in a fast, fair way"[3]. Note that instituting one before it's needed, while seeming proactive, may put off some users.
If you screw-up, apologize briefly, then fix it or move on.
I think part of the problem is the expectation of instantaneous gratification today. Individuals can get any item they want shipped premium to their door step the next day nearly everywhere. So why shouldn't software features be the same? The problem with "free" is that many, many more people can use the software.
Large corporations (which the $10k/mo user probably is) on the other hand calculate updates in months or even years.
My company also has a very large customer that asks us to implement something "whenever possible" and if we need 2 years they are just happy we did it. Why? Because they have a long update cycle. It's not really important if it's in the next release because they might not even install that but wait for the release after that.
As somebody who usually works in those big support contact enterprises, I often find myself incredibly frustrated by the open source projects my employers pay for. You often see these companies that take the enterprise approach to support contracts, taking the open source approach to fixing issues. As in, if you want something fixed, you’ll be lucky if it ever happens.
The issue that undermines you’re (mostly correct) observations on slowing moving enterprise, is that they’ll often adopt technology before knowing if it will even work the way they want it to. So when it comes time to implement, you’ll find things that don’t work as described, often accompanied by some years old issue on their tracker which basically say “we might get around to that some time”.
“Enterprise grade” proprietary software is usually terrible anyway, so still prefer open source for the reason that I’m able to write my own patches for it (which I often do). But I find the open source attitude toward fixing issues, in software that your customers are actually paying a lot of money for, incredibly frustrating. There’s a particular maintainer on a project that I use a lot at work, and anytime I see his avatar on the forum while trying to debug an issue, I instantaneously know that my whole day is about to be ruined by some of the least helpful advice you could possibly imagine.
Isn't it a bit more subtle than that? The business issues with free users are well documented, but this is a bit different. What we're really taking about is GitHub - you don't have the same volume of low effort comments demanding features on pre-GitHub collaboration tools like making lists, IRC or even using the email address associated with commits.
I'd suggest that it's more a combination of: the volume of users that now have access to the world's most popular git hosting service is vast compared to the number of people who can usefully contribute, the ease with which maintainers can be contacted through it and the "friendly by default" stance that most maintainers take on a platform where your stars are more valuable in the real world than your CV.
> consider something for future roadmap if other customers would also value it
Personally I wouldn't want a custom feature just for me. Because I know it'd likely be poorly supported and sometimes break. Because that's how it's been when I've been on the other side of that.
For this exact reason I've cut almost all of my tech support for friends and family. It seems that what goes around comes around, and my time was worth what they paid for.
That’s sort of dispersing the problem onto some other poor sap or group of saps. Businesses do need to set boundaries and it’s terrifying to do so because “the mob” can suddenly decide against having goodwill. Best bet is to set standards very early and firmly like you’d treat a child - EG “we do NOT put our hand in the fire, but you can do just about anything else” and “we do NOT adjust our roadmap to people who yell the loudest but we are happy to have a conversation over why it’s important”
