Open-source projects thrive on community participation and collaboration. As a maintainer, how you respond to help requests can make or break the user experience. Here are some key points to implement if you want to ensure you alienate your users.
I recently had an experience where I was trying to add an open-source project to a .NET Maui project I’m working on. After several attempts to compile the code, following the sample code and documentation, I contacted the maintainer via a GitHub issue report. The exchange that followed left much to be desired.
While I ultimately was able to piece together the missing link and get the code compiled, it left a sour taste in my mouth. Moreover, it prompted me to write a new blog post after a long hiatus.
So with that in mind, let’s look at some ways an open-source maintainer can alienate their users:
1. Ignoring Requests Completely
The fastest way to alienate your users is to ignore their requests for help. When users reach out, they often do so because they’re stuck or frustrated. Acknowledging their issues promptly shows that you value their contributions and are committed to improving the project. Since you want to alienate them, make sure you ignore them.
2. Responding with Condescension
It’s easy to forget that not everyone has the same level of expertise. Responses that come off as condescending or dismissive can discourage new contributors. Strive to never provide clear, respectful, or patient explanations. Condescension is a surefire way to alienate users!
Assume everybody who contacts you is a complete moron and treat them accordingly. People should inherently know everything you know, so of course condescension is warranted.
3. Being Overly Defensive
Criticism can be hard to swallow, especially if it’s about something you’ve worked hard on. Responding defensively to feedback can create a hostile environment. We want that! Be sure to use that criticism as an opportunity to fire back at the stupid users. Defensiveness creates animosity and puts others on guard as well. What better way to way turn people off than that?
4. Providing Vague or Unhelpful Answers
Users often seek help because they need specific guidance. Replies that are vague or only partially address the problem can be frustrating. Whatever you do, don’t provide clear, detailed instructions or direct users to appropriate resources. The longer you keep the user engaged with vague and unhelpful answers, the more soul-sucking the result! Keep them on the hook as long as possible, ruin their day!
5. Not Following Up
After providing initial assistance (wait, you didn’t actually assist, did you?), make sure to ghost the user after this. If you check on them to make sure their issue has been resolved, you might make them think you care about their experience and give the impression you are dedicated to providing ongoing support. If you don’t follow-up, the idiots probably won’t contact you again, right?
6. Overpromising and Underdelivering
Make all the promises you can’t keep. If you commit to fixing an issue or adding a feature, be sure not to follow through. Failing to meet expectations can damage your credibility and trust within the community. Extra points!
7. Neglecting Documentation
Good documentation can reduce the number of help requests and empower users to resolve issues independently. Whatever you do, make sure your documentation lacks detail, is out-of-date, and is hard to access. Direct users to it when appropriate, then laugh when they can’t find the answers they’re looking for.
If a user suggests something is added to the documentation, tell them this is an open-source project and they’re free to contribute. After all, you don’t have time for that.
8. Lack of Transparency
Whatever you do, never be transparent about your availability and the project’s roadmap. If you’re unable to address certain issues immediately, don’t tell the user. Users appreciate honesty and are more likely to be patient if they understand the situation. We can’t have that!
9. Being Inflexible
Every user is different, and their needs can vary. Flexibility in your responses and solutions can go a long way. Never be open to alternative suggestions nor willing to adapt to better serve your community. Remember, this is your project, so it’s your way or the highway!
10. Forgetting to Say Thank You
Finally, never express gratitude. Thanking users for their contributions, feedback, and patience fosters a positive and collaborative environment. That is anathema to what you’re striving for.
Pretend you helped the user with your previous responses and then act appalled when they finally respond in kind matching your energy. Works every time.
Conclusion
Rest assured that following any or all of these bullet points will successfully alienate your users. Conquer all ten of them and you’ll be the open-source asshole God! Remember, how you interact with your users reflects on the entire project, so strive to make every interaction negative!
Additional Resources
- 8 ways not to do open source – opensource.com
- How to ask for support from an Open Source Project – Maddy Miller
- Open source etiquette – mdn web docs
- How to Code Review Effectively – The Seeley Coder
0 comments on “How to Alienate Your Users: An Asshole’s Guide For Responding to Help Requests in Open Source”