They&#x27;ve stopped listening because now they have two classes of users: multi-million dollar enterprise contracts, and everyone else. I guarantee you that they&#x27;re very responsive to the &quot;users&quot; in the former class.<p>And really, I don&#x27;t think there&#x27;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&#x27;t support engineers&#x27; salaries on their own.<p>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.<p>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 <i>for</i> that FOSS project <i>to</i> enterprises. I work at such a company; we&#x27;re just as enterprise-focused as anyone else, and we&#x27;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.<p>So, really, I&#x27;m not sure if there&#x27;s any viable solution for most projects. <i>Some</i> projects, with enough reach, can thrive off having multiple competing corporate sponsors—that&#x27;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.