And really, I don't think there's a good solution to this problem: almost all SaaS businesses are built on the premise that all the free users who join in the beginning are a loss-leader on the path to acquiring the enterprise contracts. Even bootstrapped companies are not immune. The pool of non-enterprise users just can't support engineers' salaries on their own.
The only real way to avoid the eventuality of a SaaS service focusing its resources on its enterprise customers, is to just avoid using SaaS services. Maybe use FOSS projects like Gitlab instead.
Though, even then, the people who build themselves up as experts on that FOSS project will—with nearly the same inevitability—be hired as employees by some company that wants to sell support contracts for that FOSS project to enterprises. I work at such a company; we're just as enterprise-focused as anyone else, and we've basically sucked our FOSS ecosystem dry of developers who would be heavy user-focused contributors, redirecting their attention (via their salaries) to the enterprise needs.
So, really, I'm not sure if there's any viable solution for most projects. Some projects, with enough reach, can thrive off having multiple competing corporate sponsors—that's when you see committees like WHATWG or Khronos forming, so all the corporate contributors with conflicting enterprise needs can tug at one-another. But nearly nothing has that level of reach.
A company I worked for has outsources some payments infrastructure to a third party. That third party had put in a very aggressive bid in order to win our business. We were to be their "big name customer" and they wanted to use that deal to gain credibility with other potential customers. It seemed like a rational business decision for them, and we took the deal.
But, the fact is, that deal wasn't commercially sustainable, and we both suffered from it. They lost money on everything they did for us, and because they were losing money they tried to do everything as quickly and cheaply as they could, which inevitably meant badly. We were never happy with their offering.
When the time came to renegotiate the deal, we went back out to market, and we invited them to participate in the tender process, but we were very clear - "This is the SLA we expect. These are the penalties we will apply if you miss the SLA. We intend to hold you to them. If you submit a bid, make sure it is commercially viable, and that you can afford to actually deliver on the SLA, or else you will end up losing a lot of money on this."
I think we ended up sticking with them for a bit longer (due to politics and inertia) and then eventually ditched them a few years later.
There are people who want to get things done in the upstream project, and they try... but they just don't have the resources, because most of the people on the project are busy doing their jobs.
Excluding corporate-support-contract-of-this-project employees from having contributor rights to the upstream project might work, but then you get the opposite problem: a downstream that's increasingly diverged from the upstream (because if the customers want a feature, but upstream won't take the patch, forking is pretty much necessary) where the "free core" of the upstream begins to stagnate because (in relative terms) nobody's eyes are on that code.
Low quality bug reports waste everyone's time: I don't know of any developer who would disagree (open source or not, paid work or volunteering). If the "user input" is low quality bug reports, then it is a burden. Complaining that Issues enables low-quality bug reports isn't hubris.