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.
Comments on Is it wrong to demand features in open-source projects?
Parent
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?
Post
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.)
1 comment thread