I started off reading this article thinking "well, anyone who has ever maintained an open source project has almost certainly experienced the unending entitlement of users even when working for free". But after reading the article, I'm not surprised your users dislike you more after communicating with them...

> I have already thought about this a great deal. I am not changing anything based on your email.

> User can provide details for us, but if others aren’t experiencing it, it’s unlikely to be prioritized.

> We know about this, but fixing it is a decent amount of work or low-priority because it’s not a big deal or few users see it.

> a human response detailing why I am unable to solve your problem today and am not even going to try is about the worst thing a user can receive!

> Good in theory, sometimes useful, but often the same small, unrepresentative segment with strong thoughts.

> Castro is an opinionated app and I’ve thought a lot about what we’re building and what we’re going to work on next. It’s unlikely I’m going to implement the request.

Your support policy seems to be more along the lines of "you may e-mail me for an explanation of why I'm not interested in your thoughts" than an actual commitment to support for paid customers. You aren't interested in comments on the payment model, bugs, or feature requests.

> why software lends itself to subscription so well [...] no matter how carefully or kindly it’s explained, the reply will be more negative than the initial email

Especially when you're using it to justify scummy practices, it's no wonder that no matter how kindly and carefully you piss on your users, they know it's not raining.

You mention early in the article that you intended to base this approach as a response to your own subpar user experience with support in other products. But does your user experience with other products tell you that you want to subscribe and be nickle-and-dimed for the rest of your life for every last thing? Especially when you're promising to users that while you're still working on the software and that's why they need to pay every month forever, you won't work on the bugs nor features they want? Subscription works "so well" for software because it makes you a lot of money, but it doesn't work well for the users its being forced upon who don't actually want the updates you're working on.

As far as I can tell, your software is not significantly based on ongoing maintenance costs, ergo it does not inherently justify ongoing payments to use. If you let greed stop clouding your eyes, you could adopt the approach that many ethical independent developers use: an option to pay once per major version and keep it for life, with optional subscriptions to try the waters and keep up with the latest and greatest version.

One suggestion — when you have an unsatisfying answer for a customer like “I can’t reproduce that”, or “I won’t build that feature”, the customer may not appreciate the amount of effort you have invested in that decision. A 30 minute phone call/video call may communicate more effectively the depth of care you have. Even if you convey the same information, people _love_ talking to the owner/founder, it is a very strong indication that you care about their thoughts.

Indeed a helpful article for it's detailed insights. Once you think about alternatives, it's clear why everyone else is on the well-known path (such as unhelpful support.)

I've often heard stuff like "telecom provider support sucks" or "IKEA furniture breaks easily."

When you ask people whether they researched support quality before deciding on a provider or whether they considered a $3,000 heavy-wood furniture the boomers had, they immediately sense the accusation in the question: It was their decision to suffer these fates. They then tend to get mad fast.

People like to save 3 cents on their monthly internet bill and to disassemble their furniture in 5 minutes. It's exactly why everyone is optimizing for it.

Thinking about customer support as a ‘differentiator’ or a way to drive profit is depressing. You should simply strive to do what’s best for your customers. The sort of feedback you’re getting is golden and in the right hands can be put to use rather than be dismissed. Assuming that people who disagree with your pricing model just don’t understand how business works is really telling. You have to accept that your pricing model sucks to a group of people (who are likely experiencing subscription fatigue) and decide if it’s worth losing or never getting their money.

Your support strategy is missing an outlet for needy users to ask questions, effectively blaming customers for a structural flaw in your own setup. You could easily spin up a forum where power users help each other and devs can occasionally jump in to help or note pain points. Furthermore, your development and QA processes clearly need scrutiny. The reason bug reports feel like a ‘waste of everyone’s time’ is likely because you don't have the right error logging or telemetry built into the app itself. Having to wait for a manual bug report from a user is already a failure.

It’s completely okay to define your product however you want and to reject feature requests, but to say you’ve singularly thought through every problem in an armchair, in comparison with the distributed minds of the rest of us, is pretty arrogant.

I know this isn’t a very interesting comment, but just to provide some balance to the mostly negative comments I’m seeing:

It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.

> When emails overwhelmed me, I asked a thoughtful user who emailed frequently and seemed to know as much about the product as I did if he’d help answer the emails, so I paid him to do that. And he did a great job, especially in terms of directly solving user problems.

Hey, I got promoted from customer to Customer Support at _my_ $dayjob!

Let's review some common areas.

- Pricing: everyone is always looking to get a better deal. That's their right but I'm unlikely to give one. Saying no here is just another (emotional) cost of doing business.

- Bug reports: broad agree on all four points but not necessarily the conclusion. Users who are willing to go down the debugging rabbit hole with me are golden.

- Pathological customers: I like to call them "frequent flyers". Enough said.

- Feature requests: we're not necessarily as "opinionated" so we rarely give a hard no, but this is why we have a "feedback board with upvotes" approach.

- General usage questions: I have an attitude of fresh eyes often being the best eyes for usability testing. If it's not obvious, what can we do to make it so? We also use Intercom Fin to handle a lot of these level-0-support questions though.