When you complain about OSS, there is a good chance someone will answer with one of these lines.
It is OSS. Fix it yourself.
If you do not like the direction, participate and change it.
Open a Pull Request before you complain.
They sound reasonable. In many situations, they are. The source is public, issues and Pull Requests are open, and sometimes there really is a path that lets you turn dissatisfaction into change.
But these words are a little too convenient.
They can be an invitation that tells someone the door is open. They can also be a sign used to drive someone outside it. The same sentence can mean both welcome and shut up.
I do not particularly like that double use.
If You Can Participate, You Probably Should
I should make my own position clear first: I work on OSS. I write code, read issues, review changes, and sometimes create my own problems only to find myself chased by them later.
So I know that participation lets you see more. A problem that looked simple from the outside may be tangled with compatibility, performance, maintainability, and its effect on existing users. Sometimes you think one line is all that needs changing, only to discover that this one line is standing on a delicate equilibrium.
If you can participate, you probably should.
If you can open a Pull Request, do it. If you can write a reproduction, write one. If you disagree with a design and can bring an alternative, the discussion will move much further. I genuinely believe this.
But something being worth doing is not the same as being forbidden to speak unless you do it.
Encouragement is not qualification.
Participation in OSS can make criticism more concrete. It is not the price of admission for being allowed to criticize.
If You Dislike Politics, Should You Run For Office?
Carry the logic of "if you do not like it, participate and change it yourself" just a little further, and its strange shape becomes easier to see.
If you dislike politics, run for office. If a movie is bad, make one yourself. If the food tastes awful, walk into the kitchen. If the train is late, get a job at the railway company.
Of course, I am not saying that politics and OSS carry the same weight. I am comparing the shape of the logic, not the objects it is applied to.
Being affected by something is not the same as being able to move to the side that builds it. If criticism requires changing careers, surrendering free time, acquiring specialized knowledge, and learning internal customs, most criticism will die before it is born.
Participating in OSS may not be as dramatic as running for office. Sometimes participation is a one-character fix. But reaching that character may require learning the build, the tests, the history of the discussion, English, the unspoken design policy, and the relationships inside the community.
You may have to read not only the grammar of the repository, but also the grammar of the tribe.
The fact that participation is possible does not mean that participation is cheap.
This Argument Also Comes From A Particular Position
The claim that "it is OSS, so just participate" contains a great deal of positional bias from people who already work on OSS.
That does not mean they are lying. Positional bias is not another word for malice. It only means that the shape of the chair you sit in affects the shape of the world you see.
People who have successfully participated in OSS have experienced problems being solved through participation. They can code. They can prepare a development environment. They have the language needed to enter the discussion. They may already know people in the community. For them, "just participate" is correct advice grounded in experience.
But people who did not participate are hard to see from the world of successful participants. Those who gave up during setup, grew tired of the intensity of the discussion, could not find the time, or left with a discomfort they could not turn into code do not appear in Git history.
Commits receive hashes. Giving up does not.
That makes it easy to overvalue contributions that enter the record and undervalue departures and dissatisfaction that never do. This is less a flaw of character than a bias in the instrument of observation.
And in the world of builders, doing the work becomes currency. That is natural. When decisions need to be made, it also makes sense that the words of people who continuously carry responsibility have more weight.
The danger begins when that currency is exchanged for human worth.
The person who built it ranks first, the person who fixed it comes next, the person who only uses it sits below them, and the person who only complains is worthless. We sometimes create this status chart without realizing it.
At its worst, a record of participation becomes not context for an argument, but an ID card used to look down on someone.
I actually do the work. You do not.
Few people say it this plainly. But sometimes this thin contempt lies underneath "if you have a complaint, participate." I spent the time, wrote the code, and accepted responsibility. You remained outside and contributed nothing but words. The difference stops being a difference in roles and becomes a difference in moral sincerity.
Participation then stops being a proposal for solving the problem. It becomes a footstool for placing oneself one level higher. The words say "participate," but no invitation is really being offered. They merely confirm the speaker's own correctness and quietly deduct points from the person who did not join.
Of course, doing the work carries weight. But that weight belongs in the evaluation of the criticism, not on a scale used to measure the critic's character. A history of contribution is an achievement. It is not a license to speak.
A Common Enemy Is Cheap Glue
This contempt does not remain inside one person.
People doing the work find one another. They understand each other's struggles, recognize each other's work, and nod along to each other's frustrations. That is good in itself. OSS cannot continue through one person alone, and some forms of exhaustion are understood only by people carrying the same responsibility. Solidarity really can save people.
But sometimes that solidarity is built not around a common purpose, but around a common enemy.
We are the ones actually doing the work.
They do nothing but complain.
Once these two lines come together, battle lines form. Authors, maintainers, and contributors stand together as the side that acts, while critical users are placed opposite them as the side that only talks. Before anyone asks whether an individual criticism is valid, they begin by checking who is on this side and who is on the other.
A common enemy is cheap glue. It dries quickly and holds remarkably well. People do not need to reconcile complex goals when disliking the same target already gives them a sense of unity. Their hardship and their righteousness both become sharper in contrast with the enemy.
Unreasonable demands, endless reminders, and harassment that exhaust maintainers do exist. People need to stand together to protect one another from such attacks. I am not asking everyone to endure them alone.
The problem is that the definition of the enemy gradually expands. People making unreasonable demands are placed in the same box as people offering severe criticism. Severe critics are placed in the same box as people who merely said something was hard to use. Eventually, anyone who speaks without participating becomes the enemy.
At that point, maintaining the formation matters more than examining the criticism. A person raising disagreement from inside looks disloyal. A person trying to understand an outside voice looks like someone conceding to the enemy. To preserve unity, the enemy must remain an enemy.
This is not healthy. At the very least, it is not the shape of a community that should last.
A community gathered around what it builds can discuss its purpose. A community gathered around an enemy can only keep talking about the enemy. The former can strengthen as the work grows. The latter must cultivate hostility to preserve its cohesion.
We need solidarity for protection. We do not need battle lines for contempt. A relationship that survives without placing someone on the other side is probably stronger. I do not want to call a community healthy if it would be troubled by the disappearance of its enemy.
Of course, people who actually do the work deserve respect. They spend time, carry responsibility, and continue building things for others to use. That should be recognized fairly.
But that respect should not be proven by belittling people who are not doing the same work. We do not need to lower the floor beneath users and spectators in order to lift builders higher. Respect is not zero-sum.
Praising one person's work and stripping another person of the qualification to speak are entirely different acts. The moment the latter begins while wearing the face of the former, respect becomes a tool for hierarchy.
Spectators Are Not Unfinished Players
Sport obviously needs players. But we do not call spectators lazy players who have not yet stepped onto the field.
Spectators are spectators.
OSS has authors, maintainers, and contributors. It also has users, observers, critics, and people who decide not to adopt it. They do not all need to perform the same role.
Users may not write code. They still use, share, depend, expect, become disappointed, and leave. Those movements build the reputation and ecosystem of OSS. Sometimes they lead to corporate adoption or sponsorship; sometimes they quietly announce decline.
I would not go so far as to say that OSS with no users has no value. A tool for its author alone can be valuable, and so can the joy of building it. But when we speak about communities, ecosystems, or social influence, users cannot be treated as background scenery.
A stage can exist with performers alone. Culture cannot keep moving through performers alone.
An audience is what turns a stage into a world.
The Allergy To Negative Feedback
Negative feedback, in particular, is attacked far too aggressively.
When someone says, "this was useful," "this is wonderful," or "I use this all the time," nobody replies, "then write some code." Nobody checks whether the speaker understands the internals, contributes continuously, or is qualified to make the statement.
But the moment someone says, "this is hard to use," "this change is bad," or "I disagree with this direction," an audit of their qualifications begins.
You use it for free. Stop complaining.
If you dislike it so much, build your own.
You have contributed nothing. Do not act so entitled.
These responses usually do not address the substance of the original complaint. Is it actually hard to use? Who is harmed by the change? What is defective about the direction? Instead of discussing the object, they condemn the act of complaining itself.
This is not an answer to criticism. It is an order not to criticize.
Of course, the delivery may be bad. The facts may be wrong, and nobody is obligated to accept outright disrespect. But poor conduct and a valid point can coexist in the same statement. A dirty envelope does not make the letter inside it blank.
Negative feedback is also rejected so strongly because criticism of something we built can sound like rejection of the person who built it. The more time, responsibility, and friendship we have invested, the thinner the boundary between the work and ourselves becomes. When a stone comes flying from outside, we want to raise a shield before reading what is written on it.
I understand the feeling. But when participants line up their shields and process every negative voice from outside as an enemy attack, they do not create a safe community. They create an echo chamber.
Insiders know the context. They know the design constraints, past discussions, and cost of maintenance. At the same time, they have reasons to justify their own decisions and feelings that make them want to protect their peers. Knowing the context is a strength, but it does not automatically make someone a calm and balanced evaluator.
In fact, when only people who understand each other's struggles nod together, their judgments drift in the same direction. They mistake not hearing disagreement for disagreement no longer existing. They begin to interpret silence inside the circle as consent from the world.
That is why heckling from the sidelines matters.
Heckling is not a specification, a reproduction, or a Pull Request. It can be rough, short, and useless. But it tells us where people who have not adapted to the builders' logic got stuck, what made them leave, and what felt wrong. Precisely because the discomfort has not yet been translated into internal language, it carries information that internal language may have lost.
Some heckling really is meaningless. We do not need to take all of it seriously or reply to every voice. Volume is not proof of correctness.
But the existence of meaningless voices does not make an allergic reaction to all negative feedback healthy. An immune system is necessary. An immune system that attacks everything from outside as a pathogen will damage the body itself.
If there is a point, take it seriously.
Taking something seriously does not mean obeying it, adopting it, or promising a response. It means reading what is being said as content at least once: acknowledging it when it is right, thinking through why it cannot be adopted, or deciding that it is wrong. Do not skip that process because of the speaker's affiliation or contribution count.
A healthy community is not one where negative feedback does not exist. It is one that can metabolize negative voices without creating more enemies.
People Who Only Complain Are Allowed To Exist
Are people who only complain really evil?
I think they are allowed to exist.
You are allowed to say, "this is hard to use" without a concrete solution. You are allowed to say, "this change caused problems for me" without knowing the internals. You are allowed to say, "I do not like this direction" without the ability or time to fix it yourself.
Some things are visible only to users. In fact, knowing too much about the internals can hide certain kinds of inconvenience. A builder may explain the same complexity a hundred times and become used to it; a new user may hate it in a second. That one second of aversion is rougher than a design document and harder to handle than a Pull Request, but it is real as user experience.
Of course, complaints can be wrong. They can be sloppy, misunderstand assumptions, or ignore the needs of other users. A complaint does not become sacred user feedback merely by being a complaint.
It is still allowed to exist.
Incomplete criticism is not an inferior version of a completed fix. They perform different roles. Criticism draws the outline of a problem; a fix reaches into one part of that outline. The person who did the former does not always need to take responsibility for the latter.
The Right To Speak Is Not The Right To Demand Labor
These must be separated.
The right to criticize does not mean the right to make a maintainer fix something for free. The freedom to open an issue does not automatically create an entitlement to priority. You may receive no reply. The issue may be rejected or closed.
Maintainers are free not to fix it. They are free not to explain forever, to protect the direction of the project, and to keep disrespectful people away.
Harassment, orders, endless reminders, and the assumption of free support do not need to be defended as "criticism." They are not opinions. They are unauthorized invoices sent against someone else's time.
At the same time, a maintainer's right to reject that invoice is separate from whether a user's experience is allowed to exist.
There is freedom to speak. There is freedom not to take the work on.
These freedoms do not conflict. The discussion becomes strange only when we try to recognize one and deny the other.
Builders Are Not The Only People Who Matter
People who built something deserve recognition for building it. They spent time, carried responsibility, fixed it through broken nights, read someone else's sloppy issue, and continued dull compatibility work. That labor should not be dismissed.
But having built something is not proof of being right about every question surrounding it.
There are situations where the words of people who did the work deserve more weight. It is also reasonable for final authority to lean toward those who continuously carry responsibility. But the fact that they did the work cannot, by itself, invalidate the content of criticism from outside.
Sweat can be an achievement. It cannot be a rebuttal.
Respecting builders is different from placing them in a higher class. Respecting users is different from accepting every user demand.
Neither side needs to be king.
Conclusion
I work on OSS. That is exactly why I believe participation is worth pursuing when possible. If you find a problem, reproduce it, fix it, discuss it, and, if you can, remain involved. Some forms of understanding are only available through participation.
But that advice must not become a condition of silence.
"Just participate" should be a hand extended toward someone, not a hand placed over their mouth.
The world of OSS does not exist through people who commit code alone. There are people who use it, choose it, reject it, praise it, or only complain about it. There are also people who leave without saying anything.
Builders do not create the world alone. Spectators and users are what place the thing they built inside a world.
Participation is a bridge. It is not a toll gate.
Those who can cross should cross. Those who do may bring back what they saw on the other side. But we should not throw away the voices of those who remained on this bank of the river.
Being open does not only mean that anyone can become a builder. I think it also means that people who do not become builders can still look from outside and say: I like this, I dislike this, something here is wrong.