How I stay happy making open source software
snarky.ca
snarky.ca
I was always very greatful for any comment my project received - Especially negative/constructive ones.
I didn't get much feedback early on so there weren't many opportunities to improve.
SocketCluster was never about the code. It was always about creating a useful tool. It has gone through many refactorings and changes in technical philosophy. Seeing steady improvement in the product and the dedication of the community is what keeps me happy.
I was very fortunate that the project got so much traction. It did help me with my career. I owe it to everyone who clicked that star button on Github to keep going.
GitHub: https://github.com/SocketCluster/socketcluster
Website: http://socketcluster.io/
That said, I would agree with you that the ROI (at least in the medium term) is not worthwhile. If you want cash, you are probably better off working on your own commercial project or working for clients.
Your code is not you and neither is your project. As maintainer you are not responsible for fixing all bugs (we at GitLab Inc. are, but that is another story). If people care to complain it is OK to ask them to contributing a fix or showing the advantages of a different approach.
This will help you to keep the 'correct mental direction', which is that YOU provide the additional value and the issue poster wants something from you.
Also if you are the maintainer, put a warning to people with too strong words and throw them out of your mailing list if a second violation occurs. Also newer 'mailing lists' (like discourse.org) help here with flagging capabilities, edit buttons and more.
Try to ensure that the discussion stays 'emotionless' and without sarcasm or if you allow it do so only with emoticons ;)
I've related this before, but I've had some super negative experiences with very entitled people. One person was a professor for whom I continued to build stats software for 18 months after leaving university. He actually repeatedly called me screaming when I was too busy to do some custom work for him on his timeframe. After giving him 10+ hours a week of free work for a year and a half because I thought the software was interesting and I believed in the work the various labs were doing.
I also work on a bit of open source software that I wrote that implements a high performance (threaded and heavily beaten on with vtune) ml algorithm.
I think the solution, particularly for small projects or individuals, is to preemptively cut people off. After many negative experiences, when I get bug reports or requests, if the reporter hasn't put in a reasonable amount of work already, I just killfile the email address and move on with my life. Even a small fraction of negative people was ruining any interest I had in working on my project: I'd open the tag in gmail, read a nasty or demanding email, and lose all motivation.
If people don't preemptively respect my time, I have no use for them. If they don't like that, they can have a full refund of everything they've paid me =P
Agreed that it's best to cut off things like this early. Some programmers need to learn the value of their own time -- and act accordingly. If you don't respect your own effort, other people never will.
Compare with: "Sure, I'd love to do that. I can spend about 10 hours on that this week and that will cost you $1000. Who do I address the invoice to?"
That should sort the wheat from the chaff pretty quickly.
Just be glad you got out with only 800+ hours lost to him. People like him can cost other people their lives!
I am pretty permissive about contributing to big projects. I feel like an outcast. So I choose to spend my time working on private projects whenever I get a minute. I guess I am just one of the few cynical negative developers out there.
We need something like "Code Triage" (codetriage.com) but instead of giving people old / aging tickets to fix, this service would alert people of negative comments.
I'm assuming it would have an ML algorithm which would flag comments if overall sentiment of the comment was negative. So people would sign up for github / bitbucket / etc. projects they're familiar with, and would then start receiving emails if negative comments were being posted. They could then help by more or less shielding the project owner from the negativity and hopefully preventing the complainer from going on rants across the web shaming the project or being negative in general about the project.
Eventually you realise it's either you or them. That's when you've mastered it.
I'm a freshman when it gets to maintaining an open source project (just started with one, it's on my user page), and am very interested in getting savvy on how to feel or judge things, hence I found your image welcome. I wouldn't know whether it's wrong or right, but I find it welcome as it's strong, i.e. sticks around, my mind will compare it to real-world situations in the future and figure out over time whether it's correct.
I think what the image points out is that you're ultimately doing your own decisions, for your own benefit, and not doing it for anyone else unless you decide so. And I'd think that this is correct: I did believe that open source is something to improve the world, and standing against closed-source software, and hence if I saw that open source software was lacking, it felt wrong, and led me in a couple occasions to give strong statements to open source developers, which I guess were received exactly like the negative, demanding inputs criticized here. So I'm guilty of this myself. So now, while I realize that the other side (the user) wants to be appreciated, too and not doing that will lead to project failure (both of which might be the reason leading to the down votes here), it would be wrong to let that suck out your energy. And the picture of the cowboy primarily needing to survive himself seems fitting.
(PS.: I think what I'm advocating to accept here is more "either you or me are going to survive", and not so much "either you or me are going to die". These are not equivalent if there's a middle ground where there are other outcomes than dying. Anyway, the OP points out even better solutions anyway, too.)
(Edit: thanks for the replies, I've appreciated them all.)
About what you said, most projects, if not all, will be struck by hordes of users asking for all kinds of things, some of them will be reasonable, some of them will not. Never hesitate to say NO to a user, even if he's written a patch already. Never merge things out of pity.
Another important thing: if the project grows large enough, it'll attract collaborators that, despite their best intentions, screw up often. Obviously you must be friendly towards them, but be sure to make it clear when they've screwed up.
You will also find collaborators that not only screw up often, but also defend themselves and think they are always right. Do not hesitate to make it clear that that's not the place for such behaviour and if they don't improve kick them out, outrightly or in a subtle way.
Perhaps the point (of the cowboy image, perhaps with regards to self reliance) is that you can tell them that you decide, since you started the project and are still its leader, and that since you think the contribution is screwed up, you won't merge it. This explanation does not contain anything about the contributor's behaviour. Well I guess I don't know about what that part of your example entailed :)
Anyway, thanks for the comment!
I don't doubt that this is what you've found to be true, but I agree with how nostrademons put it, it's self-fulfilling.
Open source projects don't have to be adversarial, though some of them certainly are. What sets the projects listed here apart from the more adversarial projects?
It's sort of like when someone says, "99% of humanity is too sensitive!" The ONLY people who say that are people who go around pissing off other people on a regular basis and it never occurs to them that the problem might be with their own social skills and not 99% of humanity.
So, when someone's response to someone else getting upset over jerks on the Internet is "you should get thicker skin", it's easy to jump to the conclusion that it's coming from a troll rather than someone honestly trying to help a fellow adult. Based on this comment it sounds like you meant it in good faith and were just trying to help the OP out.
If you believe that the open-source world is filled with mean people who will grind you down and the only way to avoid this is to give as good as you get, you will behave in a way that ensures that only people who are mean, aggressive, and tactless will gravitate to you. Nobody wants to work on a project where the lead is looking for the slightest sign of misbehavior to jump on people. So it becomes a self-fulfilling prophecy: people who can firmly but patiently & politely establish norms of behavior that attract patient & polite people, while people who believe it's a Wild West where everyone's out to get you establish cultures where it's a Wild West where everyone's out to get everyone else.
Most people would rather work in the former culture than the latter, and so in the interest of not establishing more cultures like the latter, they downvoted the grandparent post.
When you open source a project you do so so other people can work with you and help you with your "baby", so it would make no sense to jump on people at random. Everybody makes mistakes. But you must be prepared to face toxic people, because believe me, you will face them. And in that case, you mustn't put your ass up: you must get rid of them.
"If you don't have a thick skin, you'll have to grow one, and if you can't grow one, they'll just eat you alive. Eventually you realise it's either you or them. That's when you've mastered it."
Subsequent comments of yours have been more reasonable, but the text of what you wrote in your original comment certainly implies a combative, us-vs-them mentality.
Taking that comment as a sign of combativeness is definitely a signal of thin skin. Does that count as irony? Probably not.
A code of conduct shows that you (as a project leader) or your community can't deal with human issues using common sense, so you need a list of guidelines for that. So codes of conduct are better avoided.
This is just a trade-off one chooses in running a community, and some people choose one and others the other. It doesn't have to be a Clash of Civilisations debate.
Users who don't have experience leading projects may not realize that this dying happens, they may only ever see surviving projects.
Now of course a surviving project that is also friendly is the best, no doubt about that, but the question how to achieve this is going to be partially independent. (The cowboy image may be more fitting for the fact that some projects die, and less fitting for how you achieve for it not to die.)