1. Severely restrict the scope of the project (i.e. do one thing and do it well) 2. Don't feel guilty about saying "no" 3. Realize that people have no malicious intent or are lazy when they request <feature X that takes two months>. It's just like a normal customer in a business: they often have no idea of the cost and difficulties in implementing things. That's okay, it's my duty to inform them of that. 4. Refuse pull requests for features that I don't feel like maintaining. I always try to keep people from wasting their time and ask them to confer before implementing a feature.

I don't feel animosity towards people who (even rudely) request such things. But they can expect a short reply in the form of "I'm sorry, that feature is outside the scope of the project / is going to take too much of my time."

Seems problematic to let the bounty-poster decide if something is completed, but also to put it on a third party to put in the time to verify for various pieces of software they might not be familiar with (and worse to put it on the second party who implements).

BountySource suspended from GitHub | https://news.ycombinator.com/item?id=15747328

Useful discussion on the concept there; they were temporarily suspended for not supporting opt-out.

Whisper Systems supports auto-Bitcoin for suspended pull requests. https://signal.org/blog/bithub/

But I think the platform would need to be scalable in some way. Maybe no one will fix it for your $100, but maybe if the bounty were crowd funded, it would get fixed when the bounty got high enough to be worthwhile for the amount of time and effort involved.

When I was an active participant on Cyburbia, the site owner was paying for hosting out of pocket and he was resistant to commercializing it and was equally resistant to taking donations. He talked about commercialization as "becoming a sellout" and taking donations as "I don't want to do a PBS style begathon annually." He worked for the government and seemed just unable to wrap his head around good monetization.

People would complain that the site was slow and kludgey. As it got more popular, the level of hosting service he could afford was not really meeting demand. He would crab at complainers that they needed to be more appreciative of the free service that he was paying for out of pocket and make it clear he could not afford more.

I felt there was an obvious solution: Post a page saying it takes $x to cover better hosting for a year. I can't afford that out of pocket. If you want to see site performance improve, kick in a few bucks. When it hits $y, I will upgrade the hosting service. Then point people to that page when they complained.

I see a lot of potential for your idea. It could be a means to turn complaints into a money stream to help improve open source without victimizing contributors.

As someone who did a lot of volunteer work over the years, I came to resent the idea that I should do everything for free. If we value this stuff, we should be willing to pay people to work on it. Finding a means to do so even though it is voluntary can be challenging, but shouldn't be show stopping. We just have to be creative.

It's also the root cause of a lot of technical debt, "we added this misfeature years ago because 1 client wanted it, so now we have to support it". It's important there is a proper funnel for what features should be added.

The maintainer does something similar and it can annoy some people to get no for an answer but it keeps things sane. The software has been going well for 8+ years now (with one change of maintainer in that time).

We also implemented a Feature Request forum and people generally use it. Plus 'Issues' are turned off on GitHub. So things generally funnel very well through the forum/mailing list and you know that a post in the Feature Request forum will request a feature, so you can mentally prepare for it.

That helps address the under appreciated mental cost for dealing with an open ended inbox.

If you don't know whether the new message is related to 1.) expression of gratitude, 2.) complaining, 3.) feature request, etc., you have an added amount of anxiety when opening the message to figure out which kind it is.

> you have an added amount of anxiety when opening the message to figure out which kind it is.

I'm pretty sure thats a symptom.

"I'm glad you liked it, I have X hours to dedicate to project Y this month. If you'd like, I'm willing to work on that feature for you under terms Z".

People _pay_.

You'd be surprised just how much of Chromium and other open ssource projects is written by consulting companies paid by third parties to solve a use case.

From our experience (http://sheetjs.com/, our major open source library is https://github.com/SheetJS/js-xlsx), even with multinational corporations, they move heaven and earth to find another free solution, or spend in-house time to hack together a solution and try to sucker you into helping them, but paying is by and large the last option.

If I could find a way to say "Yeah, we can get 'support' for this open source library for $xxx per month" my life would be much easier.

[1] https://fund.django-rest-framework.org/topics/funding/

[2] http://www.encode.io/reports/february-2017

I work at a company with less than 500 people and for IT open source is evil.

I've seen people been told by IT to find another software that does the same thing but paid, and we have a law that mandates us to prefer FLOSS when possible...

The problem is getting single open source maintainers to commit - and followthrough - with support. They are often way too busy with their job to actually be professional with support and adhere to even a loose SLA.

The best ones who pay are those who directly reach out with a paid offer; which shows that they definitely have explored the market (most likely than not) and you are the best option :). The better than the best and great to work with clients are those who just reach out to you directly, only very rarely would happen!!!

even say one can do it 'better'

Then offer to take up the maintainer role. Debian has institutions to deal with unresponsive maintainers.

For reference, I’m the (co)maintainer of over 80 packages in Nixpkgs. IIRC, I submitted my first PR within roughly a month of using NixOS. Before NixOS, I had used Ubuntu for 4 years. How many packages did I maintain there? Zero. It’s just too difficult to track down the right project, figure out the arcane build/packaging setup, contact the maintainers, etc.

just like several dev over the years implemented privacy conscious options to restric the referer(sic) header just to have google employees silently remove them later on?

well, I guess it can work if the feature you are paying for is not to improve privacy at the expense of google's Ad business.

all added and vanished at random points in time.

I do not understand your point of view. Should we stop saying thanks in our daily life? Because it does not really do anything for anyone....

To me the following two messages give off two totally different vibes:

'Hi, can you implement <Feature that takes a month of work>? Thanks!'

'Can you implement <Feature that takes a month of work>?'

The reason it bothers me because it sounds like an order to someone who is delivering a service for you, e.g. 'Can I have another drink? Thanks!'? That's not a 'thanks'.

and

> 'Can you implement <Feature that takes a month of work>?'

Are very differently loaded questions! The first one very much indicates no concern about the implementers time, and is very often seen coming from people that have no idea the complexity of the work involved with the "Thansk!" indicating the implementer would automatically accept it regardless of their own priority, while the second one is way more innocent and open for a reply back with "not sure if I have time for that atm".

EDIT: In short, it's a matter of etiquette, the same way nobody wants to deal with a complete fucking asshole (sorry, personal scars here...).

Something like:

> I really like NAME-OF-PROGRAM. Thanks for making it! > > One thing that would make it even better for me would be FEATURE-X. What do you think?

would be much better.

Putting some effort into the request/suggestion also helps. Eg. giving a well written rationale/use case. Saying why existing-feature-Y isn't enough, etc.

- Feature requests should follow ((list your rules)). All requests that don't follow the rules will be ((closed|ignored))

- ((The maintainers of this project)) will only add new features ((at their leisure)). If you cannot contribute a pull request for ((feature X)), make a feature request ((following the rules on item 1)) and wait. Please do not be impatient.

- If you can implement ((feature X)), please do so and open a pull request.

My personal experience is that dealing with third-party code, merge conflicts and waiting for responses can be even more draining than writing code, so there's that.

(Sometimes I'll answer communication from those who don't get it right, almost always they are high-profiled individuals you occasionally have to break a rule for. [I also usually regret it. Maybe I'll learn someday.])

The best remedy I find is to know exactly where I stand. Is it something I am interested to work on? maybe, if enough users show interest. Or maybe not. And then communicate clearly to set the expectations.

Want this feature? Sure, either do it yourself or hire somebody from freelancer.com or something. Or at least help me refine the requirements from your vague "this is not working exactly like I want". But yeah, even that is taking energy away.

Related to that, I wish github had an auto-close issue feature that would be triggered if the user hadn't replied for a month.

EDIT: but I also get a lot of really good and respectful feedback. I don't want to push these people away because of my previous snarky comments.

Perhaps deliberately modest marketing would work better at attracting the right kind of users?

If those users are mad because you won't do free work for them they are entitled jerks.

If those users are mad because your marketing made promises it doesn't keep and they wasted their time learning/installing/integrating your project based on lies, you are the jerk.

Some open source projects are aware of the number of users but focus on getting contributors, so that they can make the product better. They are sharing the workload of solving a common problem so others can stand on their shoulders.

Some focus on user numbers, because then they can be famous, or they have a connected business that will make more money.

These are groups that will work very differently and respond to users differently. They have simply chosen similar software licenses.

There isn’t space for an infinite number of libraries in a niche. So if you show up you are occupying space that someone else can’t. Sort of like if your friends throw a party and you decide to throw one on the same day. Kind of a dick move if you don’t have a really really good reason (like it’s your birthday).

Additionally is nearly impossible to sell a library now. It wasn’t always that way, but that’s the world we live in now, in large part because of FOSS. Writing it in-house or using FOSS are pretty much my only two options. So FOSS has to be some significant fraction of the quality of a commercial alternative because we can’t have those anymore. Without any attempt at sufficiency, FOSS effectively makes the world a worse place.

As a user, I have no longer a way of knowing whether an "open source" project's main developers are doing stuff in their free time or on company time. So, I don't see anything wrong with asking for features. Asking for features is how software evelves, whether closed source or open source. If you have a problem with it, put a disclaimer "unmaintained" in the README.md (because not wanting to tirage requests amounts to not maintaining the software).

He didn't discard the notion of non-paying users asking for features at all.

Edit: typo

"Hi, I use your app and it's wonderful."

So far so good.

It's immediately followed by

"But it would be perfect if it had <niche feature only needed by that person's individual use case> "

This kind of feedback is wealth.

Even if the use case seems very individual, maybe a useful generalization of it can be found which still covers that case but is of broader use.

I'm 99% sure you meant this purely in the context of your earlier statemetn ("hey, implement this, plz"), but I just wanted to say a plain ol' thanks for me helps a lot in my motivation for doing my OSS projects. Knowing people actually use my shit, and enjoy it is nice :)

So a genuine "hi there, thanks for all your work, I've been using your lib for months and its awesome" is an annoyance to you? You must be fun at parties.

A 'thanks' does not do anything for me. I don't write a library for other people's appreciation, I write it because I want to, because I can, and because I have my own interests for it.

Insofar I am interacting with other people on the project, the only thing that does anything for me is if they contribute something.

Appreciation is not worth anything to me but I am also deeply introvert and not very social, I simply do not care. I can appreciate most people feel different (by observation) but I build technology because I want it to exist and do things, not to be thanked.

> Honestly, being thanked in any shape or form does nothing for me, Id rather have users be more considerate of our time and not abuse issues and the community for supporting their laziness.

You’re warping the argument by calling the response a straw man. I agreed with GP on feeling annoyed by thanks that are actually feature requests, but they went on to say that all thanks was unwelcome. Nothing was taken out of context.

Answer with an estimate based on your hourly rate.

If you don't want to work on the feature (i.e. you're uninterested), it's better to be honest about it.

If you do want to work on it, but your time would be better spent on anything else, and you're willing to work on it for money, first ask if the requester is interested in paying for it and then give your estimate.

The difference between a feature request and a client approaching a freelancer/company is that in the latter case, the other party initiates the conversation with a clear expectation of paying — they only have to decide if they like the terms and price.

Being uninterested to do it for free: Yes. But when I am interested to do it for money, giving an upfront estimate based on the hourly rate is the most honest way imaginable to me.

I would rather say that asking to "implement <Feature that takes a month of work>" for free exudes several more magnitudes of arrogance.

Not all users are at the same level of experience as you (a maintainer); this doesn't make them lesser people or even lesser developers (sometimes they're just good in a different problem space than yours), but it makes their expectations a lot less realistic. Don't offload your annoyance on the requester — sometimes they don't know that their request is significantly harder than they think.

I give/gave an estimate based on my hourly rate so that this misconception is cleared of as directly as possible. If you want it for free, you better convince me that it is worth the opportunity cost for me to implement it.

You seem to be setting up a few strawmen here.

I admit that I may be reading too much into the dynamic at play here.

To be precise, naturalgradient did not say anything about the intrinsic value of users, but his/her comment says "people who have never contributed anything" and "supporting their laziness", both valid sentiments. The complaint is that the user is inconsiderate; I'm positing that it's better long-term to teach those users to be better users and eventually good maintainers. It's wishy-washy, but the good attitude of maintainers and other users is what taught me how to behave in open source.

If your policy is to charge for features, please disclaim it in your README. It's not a wrong practice, but you should set up the correct expectations.

-

Because this is HN: For anyone looking for brass, this problem is muck and there's a product opportunity here.

I wouldn't want to assume that someone asking for a feature is willing to pay for it. I also wouldn't want to make an offer unless I'm serious about doing it if they say yes.

But, if you are doing contract work, letting people know it's an option seems like a good thing?

Perhaps I'm advocating for a frivolous courtesy versus a fully rational process. Maybe the rational process works better than my suggested approach, but my intuition says no, and would prefer that it be done in a way that communicates "I can help you, but money is a requirement", not "I really wish you would fuck off, but here's an alternative".

Worse case they have to add something and put my request in some sort of backlog. I always say thanks when I ask someone for help though. But I never flat out ask for new features because for all I know they already have a defined way of solving the problem I have.

As a maintainer, seeing it every does tend to annoy me a bit. I always try to remind myself people dont usually mean ill though. All bets are off if people continue to disregard the framework for engagement though.

Most people are a bit surprised I do this but are generally receptive after the initial explanation.

My main philosophy in these interactions is just to treat people professionally while being stern on things out of scope.

$$$? Beer?