4 ms·
As somebody with experience in developing many OSS projects of different sizes (Redis, Hping, Jim Tcl, Visitors web analyzer, and many additional smaller ones),
by antirez 5y ago
As somebody with experience in developing many OSS projects of different sizes (Redis, Hping, Jim Tcl, Visitors web analyzer, and many additional smaller ones), I think that the solution is simpler than it appears: just do what you want. When you are inside the flames of a successful open source project, you may think that the solution space is binary: don't do anything, or do everything people are demanding from you. Instead you can just keep doing what you want, cherry picking what issues you want to address, reply to, what features you want to add, and so forth. Just give you a fixed amount of time to spend on the project (in my case most of the time it was "all the time I've in a day, but up to 6/8 max", but it can be even just 10 minutes every day), and in this time do the things you like to do and ignore all the others. A few issues/PRs will be perfectly aligned to what you feel is right and you'll enjoy taking care of them. Others will not, and who cares?
And anyway, doing things this way I was able to write a database that beaten, in the market, products developed with hundreds of developers while I was alone, so there must be some merit in what the original author feels is worth investing into. So, just do what you want, but:
1. Don't fall in the trap of thinking that who asks you for things is doing some kind of mistake or abuse just because (for example) they are not paying you. Nope, they are fine asking for things, you are fine to ignore the requests.
2. Don't fall in the trap that you are not accountable about the quality of the software just because it's free software: do only want you want, but ship finished work that is reasonably well written and well documented. To do what you want, at your own peace and according to your own personal expectation has NOTHING to do with the quality of your work. Software fails, but one thing is to ship terrible stuff just because "Hey it's free", another thing is to do things the way you want, but with love.
3. When people attack you, reply gently saying what you think. Don't get trapped into fights, don't feed the troll, remember that many criticizing you, if you are stealing money from the table providing something free, have specific agendas (but sometimes they are just assholes), and their goal is to mount a big case. Stop them replying carefully and without anger, then let the discussion end, or continue without you.
4. Make good friends in the process. They'll help you immensely when there are hard times. Remember: the smartest people 99% of the times have a big hearth and are the most friendly.
- dimgl 5y agoThis is great advice and it's what I've done with my open source projects as well. The point of open source is that it's just that: it's open and free. People can try demanding things from you, but you don't work for them. So they can fork it and make changes or get lost. I think there's something about seeing a line item on a UI that really breaks people's brains. This is why sometimes having a conversation on Slack can feel different than Zoom or even in person; there's a sort of permanence on these mediums that don't exist in person to person interactions. I think it's similar with GitHub issues. Seeing an issue and getting a notification for it can make repo owners feel inclined to answer. Just don't answer. You don't owe anyone anything.
- arp242 5y agoOver the last year I've been very explicit about this in issues and such that people report (especially feature requests, but also bugs I don't really care about): "Thanks! Sounds good; keep in mind this is a spare time project I wrote for my own reasons, I'm happy working to solve other people's problems too if it improves the project, but I work on it when I feel like it, which may be next week, next year, or never. In the meanwhile, I'm happy to review and merge patches". Often it's closer to next week than never, but sometimes it's not. This sets expectations, and best of all, it just feels very liberating saying it out loud. Some of the stress I had in the past (not just OSS work, also other volunteer work) is having the feeling I was obligated to do stuff; for me personally anyway, this relieves much of it. Thus far, everyone has understood this too; that it's delivered in a friend/positive rather than snappy way (as I've sometimes seen) probably helps. Granted, I haven't maintained some truly "large" projects since I started doing this, but there are a few of non-trivial size with some amount of issues. Personally, I think this is better than outright ignoring, at least for me personally (everyone is different). I will feel guilty if I ignore people, and even a reply like the above removes that guilt because I've clearly communicated expectations. Aside: if you say "I'm happy to merge patches" then you should really do your best to actually do so or not say it at all IMHO (which is also fine). Of course life happens and it's not a hard promise, but you're essentially asking people to volunteer their spare time to write code, and ignoring their code (and time) is not great. I've seen people solicit patches (sometimes very large non-trivial ones), people write them and then ... crickets. Not even a "this patch won't do", just ... nothing. Unsolicited patches is a bit different, I do try and respond as best/quickly as I can out of respect for people's time, but I didn't promise anything beforehand so I don't feel the obligation, and especially for difficult patches I sometimes leave a similar message as above.