Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Is it wrong to demand features in open-source projects?
I have been using open-source software, and the open-source Community is great at maintaining such projects. But I have observed something in smaller open-source projects.
Whenever I demand some feature or complain about some vulnerability, small or big, there is always someone who says "Instead of reporting/demanding this, why not just create a PR with the demands fulfilled".
So, is it wrong to demand changes in open-source projects? Can't the users demand changes and the maintainers/contributors work on it?
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
As you have worded it, for most open source project, particularly small ones, I would say "yes", it is "wrong" to demand features. Or rather, it's extremely rude.
Most of the time open source software is free (as in beer) and, again particularly for smaller projects, done entirely in the developers' free time. In this context, it should (I hope!) be clear that demanding more unpaid work on something you didn't pay for betrays a massive sense of entitlement. You are essentially saying something like: "You know that weekend you were going to spend with your kids? You should instead spend it working on a problem, unpaid, that I care about but probably has marginal value to you." Alternatively, to put it in terms of money, many open source developers are also professional software developers with (in the US) an average annual salary around $120,000. If your feature would require a man-week to implement, you are looking at essentially a $2,500 opportunity cost.
What you can do instead is request features, ideally while (briefly) expressing (genuine) gratitude for the value you've already derived from the software and, even more importantly, doing as much as you can within your abilities to make it easy for the developer to know what you want, why it is valuable, and any additional information that might ease implementation. For example, if you wanted some software to support a new file format, you might do research to try to find libraries that might be appropriate for that project. And even after this, accepting that your priorities are not the developer's priorities. Part of making it easy for the developer means being concise and factual. Long diatribes about how the lack of some feature is turning away droves of users or how its addition will bring in droves of users are not useful and are generally unsubstantiated. Instead, illustrating specific use-cases that you actually attempted to do with the software and how the feature would enable or streamline it would be more factual and useful.
The general principle here is that if you're the one who wants something, then you're the one who should be putting in the work. This is the sentiment behind the "patches welcome" response. If you have the necessary skills, this is certainly the most direct way of addressing the issue. (Though, again, making it easy for the developer applies in this case too. Add tests, match the coding style, make sure it merges cleanly, etc.) If you don't have those skills, you could potentially pay someone who does, possibly the developers themselves. Failing everything else, it is in your interest to remove as many obstacles to the developer implementing your desired feature as you can.
On the flip side, requesting features and, especially, reporting bugs does have some value, and it is completely unreasonable and counterproductive to require all such reports to be accompanied by patches. The "patches welcome" response is usually unconstructive and can easily be dickish, especially when coming from an uninvolved third party. That said, this response is often intended to be off-putting. The goal in these cases is to drive the person "making demands" out of the community. Beyond just the gall at the sense of entitlement, when this is coming from third parties the motivation is to keep the project from being abandoned by attempting to eliminate emotional drain on the developer. (When coming from the developer, it's usually just a conversation ender.)
It is not wrong to ask for changes or features or report problems, so long as you realize that the maintainer of the project is under no obligation to make those changes. You aren't paying them, so you can't tell them what to do. Asking you to make those changes instead of them, plays by the same rules, you are under no obligation to people who are not paying you.
At the same time if open-source project A doesn't meet your requirements and project B does, then you should just go ahead and use project B. If an open-source project isn't responsive to requests and doesn't upgrade with the times then eventually it will be replaced with a project that does or is significantly better.
0 comment threads
"Demanding features" falls under an umbrella called "design". Design work doesn't show up directly in the commits (unless you maintain a design doc) but it is work nonetheless. Suggesting features is volunteer design work.
In principle, the maintainer should welcome such work just as they would welcome code contributions, but there are many reasons why they might not. Code contributions aren't always welcomed either, quality matters to some. FOSS devs can also be quite creative with how they understand "quality". It is silly to spend a bunch of time implementing a feature when the maintainer is just going to ignore or reject your PR - it makes sense to discuss the planned addition first.
Some developers just want to "put their code out there", on public display as it were, without much concern for who uses it. FOSS is more of a self-expression, similar to art, for these. It is evident that it would be silly to demand features from them.
Other developers are motivated in some part by users. They want people to use their software a lot, from which they may derive a personal feeling of accomplishment, professional fame, future income material, volunteer beta testers, volunteer collaborators or something else. This makes the exchange transactional even though no actual money is changing hands. Thus in exchange for using the software the user does get to demand things (small though they may be), because usage has a cost, and the developer derives a benefit from it. Feature requests are a great way to handle this exchange - they help not only the user, but the developer, by making the program more appealing to users and growing the userbase.
Unfortunately some developers do not see it this way and assume that since they are giving something away for "free", the user has no right to complain or demand anything. Sometimes their programs become popular in spite of their attitude and they are able to tyrannize the users with abandon. Often, they wonder why nobody wants to use it and become frustrated. Some bemoan the lack of contributors, but of course contributors often come from happy users. In any case, the negative feedback loop is quite wide and because of this such developers rarely seem to think, "Maybe I would have more users if I was nicer to them?". They instead seem to prefer writing blogs about how open source is unpaid labor and sucks.
I think logically, there is nothing inappropriate about suggesting features in a reasonably polite tone. The exchange from developer to user is obviously not so one-sided as some claim. However, many developers have different opinions and in practice you will always have to see if the person is open to suggestions or not. And if the latter, though you are right to suggest features, the realities of the matter will preclude exercising that right successfully.
0 comment threads
1 comment thread