Live data from Hacker News

Ask HN: How to handle open source contributors that do “too much”?

news.ycombinator.com

1–10 of 21 posts

Ask HN: How to handle open source contributors that do “too much”?

#1
Hello everyone,

An open source app of mine is being "hijacked" by a contributor, and I have no idea how to handle this the right way.

In a span of 6 months, they contributed a lot. During these 6 months, I wasn't careful enough while reviewing their PR (because of personal issues), and they took the initiative to change existing features and made the codebase "messier".

Since then, I started rewriting and cleaning everything, but they keep creating PRs with feature changes, adding features without discussing them beforehand, and it's frustrating, since they are creating multiple PRs a week, with more and more changes.

Reviewing their PR is becoming harder and harder, because I feel like I'm wasting my time arguing with them, as we don't have the same "view" of how should the app work.

I feel like I can't say no to them (or I don't know how to do so) because I should be grateful as they helped with some bug fixes, yet I feel like I'm loosing my own project.

How to handle this (without blocking them) ?

Re: Ask HN: How to handle open source contributors that do “too much”?

#2
Listen mate, I really appreciate the help but I feel like our visions aren’t completely aligned. There’s a fork button right here, probably best you click it. If you add anything I like I’ll port it over as well but until then, yeah, make your own project.

Re: Ask HN: How to handle open source contributors that do “too much”?

#3
Tell them your vision of the project's future is different than theirs, and encourage them to fork off and maintain their own version. Then you can take a more measured approach to adopting their contributions, perhaps after others have filed off some of the rougher edges.

Re: Ask HN: How to handle open source contributors that do “too much”?

#4
Like others, explain the situation clearly, but unlike others are suggesting, don't jump to the fork button. Instead, get on a call with them. In the end, you will have to decide if you want to keep accepting their work. Best to talk it through with a non-text medium, video is best, more than half of your communication is lost by not using it.

Also, get over the "I might hurt their feelings" and think more like "I might have to fire this person". On the plus side, you are not impacting their finances or family, just take care to explain your position clearly, oh, and listen first.

Sharing the repo link here might help us help you better.

Re: Ask HN: How to handle open source contributors that do “too much”?

#5
post #4

Like others, explain the situation clearly, but unlike others are suggesting, don't jump to the fork button. Instead, get on a call with them. In the end, you will have to decide if you want to keep accepting their work. Best to talk it through with a non-text medium, video is best, more than half of your communication is lost by not using it. Also, get over the "I might hurt their feelings" and think more like "I mi…

> Sharing the repo link here might help us help you better.

If you do this, it might embarrass the PR author, and PRs might become inundated with HN comments.

I wouldn't share the repo link.

Re: Ask HN: How to handle open source contributors that do “too much”?

#6
Firstly, congrats on having a popular project, caring about contributors, and seeking advice on how to handle this tricky situation.

When giving pushback, try to avoid raising the stakes, i.e. avoid public criticism, don't issue ultimatums.

If you have a private chat, that'd be great.

If not, try to state your concerns as plainly and non-judgementally as possible, from the perspective of your project.

"Hey X, I'm glad that you are and have been contributing so much to the project. There's a few different ways I see the program and codebase evolving, and I'm keen to work together on figuring out that right path.

It looks like there are places that have different visions, and if you could split PRs into smaller PRs, we can more easily find the changes that fit both our visions."

If there truly is disagreement on some PRs, you can be polite but firm, "I can see the value in X because Y, but this compromises Z, which is a core value of the project."

You have merge access, and should also consider whether this contributor is worth the hassle of all of what I just said. (In which case, skip straight to "polite but firm").

Re: Ask HN: How to handle open source contributors that do “too much”?

#7
post #5
post #4

Like others, explain the situation clearly, but unlike others are suggesting, don't jump to the fork button. Instead, get on a call with them. In the end, you will have to decide if you want to keep accepting their work. Best to talk it through with a non-text medium, video is best, more than half of your communication is lost by not using it. Also, get over the "I might hurt their feelings" and think more like "I mi…

> Sharing the repo link here might help us help you better. If you do this, it might embarrass the PR author, and PRs might become inundated with HN comments. I wouldn't share the repo link.

One would hope that the HN crowd is more respectful than this. This is a low traffic story with several offering help

Re: Ask HN: How to handle open source contributors that do “too much”?

#8
post #4

Like others, explain the situation clearly, but unlike others are suggesting, don't jump to the fork button. Instead, get on a call with them. In the end, you will have to decide if you want to keep accepting their work. Best to talk it through with a non-text medium, video is best, more than half of your communication is lost by not using it. Also, get over the "I might hurt their feelings" and think more like "I mi…

This is very true. Learning how to say no in a constructive way is hard. Doing it over text is impossible. The contributor obviously is passionate about your project and that is great. You might be able to channel that to work with your vision. The chances are they'd be grateful for some mentorship if that worked for you both. I suspect it might as you'd get more work done on your project and they'd get to improve as a developer.

I would try to let go of your frustrations with this person (easier said than done). If you do that you can try to maximize what you can get out of this. Possibly a life long friend, probably more work on your project.

Re: Ask HN: How to handle open source contributors that do “too much”?

#9
post #7
post #5

Earlier quoted context omitted.

> Sharing the repo link here might help us help you better. If you do this, it might embarrass the PR author, and PRs might become inundated with HN comments. I wouldn't share the repo link.

One would hope that the HN crowd is more respectful than this. This is a low traffic story with several offering help

[deleted]

Re: Ask HN: How to handle open source contributors that do “too much”?

#10
post #8
post #4

Like others, explain the situation clearly, but unlike others are suggesting, don't jump to the fork button. Instead, get on a call with them. In the end, you will have to decide if you want to keep accepting their work. Best to talk it through with a non-text medium, video is best, more than half of your communication is lost by not using it. Also, get over the "I might hurt their feelings" and think more like "I mi…

This is very true. Learning how to say no in a constructive way is hard. Doing it over text is impossible. The contributor obviously is passionate about your project and that is great. You might be able to channel that to work with your vision. The chances are they'd be grateful for some mentorship if that worked for you both. I suspect it might as you'd get more work done on your project and they'd get to improve as…

Having been one of those people who wanted to help out another project (https://goa.design) where the vision did not align, I left to build something on my own (https://hofstadter.io) and am having way more fun doing it and there were no hard feelings. It's best to not try to force things when the vision is different, as OP describes it
Post reply on HN