[wpietri]

Has anybody written a guide on how to survive having a successful open source project?

I happened to have something [1] get a little usage recently and it took effort not to get sucked in. There were people with questions and needs! And I like helping people! But I also have a life to lead, so I set myself some clear boundaries and worked to consciously accepted that the project wouldn't operate at the standards I'd have for myself if it were my job.

It occurred to me that when I got started in the industry I didn't have the boundary-setting skills I do now, and that I easily could have worked to hard and too long, burning myself out, especially if my project were as popular as this was. It'd be nice to have a guide from OS project leads on ways to keep the project sustainable over the long term.

[1] https://github.com/wpietri/sucks

[aikah]

> Has anybody written a guide on how to survive having a successful open source project?

No need for a guide. Close the issue tracker. Only accept pull requests, problem solved.

[wpietri]

I don't think that's a very good approach.

The contributors I got for my project all first appeared in the issue tracker and we had a few interactions before they decided it was worth their time to write code. That makes sense to me. I would be unlikely to submit a pull request until I was reasonably sure that it was welcome and and that the person receiving it would be a good person to collaborate with.

[aikah]

> I would be unlikely to submit a pull request until I was reasonably sure that it was welcome and and that the person receiving it would be a good person to collaborate with.

The person you collaborate with do not owe you anything, and it goes both ways. If a PR is rejected, then its author is free to fork the project. But you can't have it both ways, you can't complain about people potentially abusing issues then think there is a special technique to limit the problem, while keeping an issue tracker opened, because there isn't.

Closing the issue tracker will ensure only people capable of fixing issues will collaborate to a project.

[wpietri]

I understand the theory you're expressing, I just think it's pretty far from optimal.

Closing the issue tracker might have the effect you describe, but will also unnecessarily alienate people who would be excellent contributors with a very moderate investment.

I personally didn't "complain about people potentially abusing issues", so I'm not sure where that's coming from. What I'm interested in is helping less experienced project maintainers find healthy ways to cope with having a successful project.

But given your confidence on the topic, surely you can show us the successful open source project you are running along these lines?

[iofiiiiiiiii]

I also like the "just give maintainer rights to people who submit good PRs" approach I have heard of. Used it successfully on one of my open source projects that I no longer cared about.