Hacker News new | ask | show | jobs
by notzorbo3 3127 days ago
Ways I deal with this as an open source maintainer of various projects:

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

5 comments

It would be nice if github made it easy for people to assign a $ bounty to every issue and when it's marked complete payouts are automatic. There are a bunch of issues in various open source projects where I would easily drop $100 on a bounty.
I believe this is what bountysource.com is for. I haven't tried it, though, and I'm not sure how completion is evaluated.

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

Three days ago:

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/

This is potentially a great idea. It doesn't necessarily have to be a github feature. It could be a third party platform, kind of a Patreon or Kickstarter for open source bugs.

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.

I'd be worried that this might create an expectation to work on issues people were willing to pay for, whether that makes sense or not. I've seen a lot of this in commercial software, if a paying client want a feature then it get's added no matter how much sense it makes. Then every other customer has to deal with the feature bloat whether they want it or not.

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.

I run a support forum for an open source project.

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.

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

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

> 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 agree. Sometimes, I explain that the feature request can be implemented, but not for free. I flag such issues with the "needs sponsoring" tag.
I very much agree with your first point, largely because, would you fancy that, that's the original *nix philosophy.
I'm curious; What are your open source projects? (And thanks for your comments, very interesting and resourceful.)