Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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.

Post History

84%
+20 −2
Q&A Is it wrong to demand features in open-source projects?

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 soft...

posted 4y ago by Derek Elkins‭

Answer
#1: Initial revision by user avatar Derek Elkins‭ · 2021-02-08T06:33:22Z (almost 4 years ago)
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.)