This article is also available in Traditional Chinese.
Supporting open source projects is very different from traditional customer support. In open source, there isn't a traditional business/customer relationship. People will fall into the horrible "customer is always right" pattern often and it is going to be your job to help educate them on the culture around open source.
For a longer and more constructive view on this, check out my new article Creators, Contributors, and Collaborators on the GitHub Community Forum.
I don't know how it is in the rest of the world, but the United States has a real problem with the customer is always right. Many people have turned this adage into a bludgeon to use against customer service people to get their way. There was also a trend in businesses in recent decades to "treat everyone that depends on your work as a customer" that exacerbated this attitude as well. In traditional production methodologies, a customer brings something to the table which balances out all of these drawbacks that is absolutely necessary to the process: money. Money is the fuel on which the traditional production engine runs and being a customer is about consuming, expecting, demanding or taking ... in return for the money that you give.
But that's not how open source works. Open source specifically removes money as the incentive and replaces it with enlightened self-interest. I volunteered many, many hours working on Atom before being hired by GitHub because I wanted a product like Atom to exist in the world. I wanted it to exist because I wanted to use it myself. Open source is successful because enough people want these things badly enough that they will volunteer their time to make them happen. They will volunteer their precious free time to contribute effort instead of money. This collaboration is the fuel that turns the crank of the open source engine.
Collaboration can take an infinite number of forms from designing interfaces, to reproducing bugs, to writing documentation, to guiding discussions, and yes, even writing code. Collaboration is defined as: "the action of working with someone to produce or create something". Collaboration is about giving, working, producing, or creating ... and in return you get the benefit of something awesome that everyone helped build.
In supporting an open source project, you want to incentivize collaboration. And while you don't want to specifically discourage customers or consumers, you want to show them that the path to getting what they want is to become a collaborator.
The main competitor to Homebrew isn't Mac Ports, it's spending time with my wife or my dog.
— @mikemcquaid
Because there is no customer there is, theoretically, no way for people to demand they get their way. But that doesn't mean that they won't resort to various forms of emotional blackmail to try to get what they want without investing their own effort.
Examples:
- "I can't use [the software] until [some feature] is added"
- "I'm going back to [some other software] until this is fixed"1
- "I can't believe that this is [current year] and [the software] still doesn't [offer some feature]"
- "If you want [the software] to succeed, you should make [the software work like I want]"
The best response to these attempts is simply no response at all. It's essentially the community management equivalent of "it is our policy to never negotiate with terrorists".
One of the major reasons why open source is so successful is that anyone with the spare time, patience and expertise can help improve it. It is true that not everyone will have all of those requirements or have them in sufficient quantity. But perhaps they know someone who does? Maybe they could pay to have what they want implemented? There are lots of options for people who actually want something valuable rather than just want something for nothing.
While the code may belong to everyone, the project itself belongs to the owners. Often these are the people that originated it or have been anointed by the original owners.
Footnotes
-
Multiple people employing this particular tactic have admitted to me that it was an empty threat. They had no intention of using some other editor. ↩