Hacker News new | past | comments | ask | show | jobs | submit login
How I stay happy making open source software (snarky.ca)
115 points by ingve on Nov 30, 2015 | hide | past | favorite | 34 comments



I've been working on a realtime framework for 3 years. It got 0 attention for the first year. Then I repackaged it and renamed it and it got some traction. The community only started up one year ago. Before that, it was just me.

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/


If you don't mind me asking, can you expand a little on how it has helped your career? I've thought about creating some ambitious open source projects before, but I always imagined it would be purely for fun/technical advancement because the ROI from a purely monetary standpoint (increase my salary by being a known expert?) would be small compared to spending the time doing "real" work for clients.


I've had promising start-up founders reach out to me with job offers and/or invite me to their offices (got them on my Skype). It also opened up a lot of possibilities when looking for jobs.

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.


Happy SocketCluster user here. Thanks so much! SC removes so many headaches from my life.


When people complain about GitLab I always try to give a positive response, thanking them for their feedback and trying to address their point. People complain because they care about you getting better. As the project matured the expectations are higher so there are more complains. Which means I say sorry a lot more. But as the project matures people are also no longer expecting the CEO to care and say sorry anymore. So when I respond to a complaint the tone of the poster frequently changes. Some of these initial complainers have turned into fans and contributors of the project.

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.


One recommendation if something does not work as expected and people claim that it should (be it positive or negative): as the creator, never ever say "sorry"!

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


Agreed. Saying "sorry" brings out the worst in some people. If you pay attention, you'll sense a shift in the power dynamic, and some jerks out there will become more hostile, belittling, and demanding. It's better to just focus on what can be done to move things forward.


tl;dr: negative people can suck all the joy out of software development, particularly when doing the less enjoyable parts such as support/bug fixes for free. The author has some suggestions, but I think they work best for larger projects.

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


Your professor is a sociopath. You're right to steer clear from him. Personally, for someone like that... I wouldn't work for them even if I was paid $1M... I'm a bit different though. :)

Just be glad you got out with only 800+ hours lost to him. People like him can cost other people their lives!


Jesus! What a horror story. I don't get how the professor concluded that he was entitled to your time like that.

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.


People become entitled like that, basically because you let them by repeatedly allowing them to take your time for free.

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.


Yup! This is also applicable for people who won't pay you back with their time, either! What helps some people is to have plenty of stuff going on in your life so that it's easier to say no because there actually are a ton of compelling things you want to spend your time on...


My preference in the last ~2, 3 years is rule out language contribution. Because I am not familiar with compiler and language design, when I make comments I feel like people just think "this guy is stupid." This negativity is so strong I feel depressed. Actually, Python mailing list is a really good example how the community discussions are both fruitful and disastrous at the same time. One question can go into so several sub topics into 200 replies and just more tangential talks. At some point people don't reply to comments you make (but you made that same damn comment before the other person did!), and you feel like like a victim of "you are not one of us."

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.


This blog post made me think:

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.


Github needs a ignore user list for project where the issues and pull requests from a use just get ignored. So those mean people don't know they are being ignored but are ignored.



The hard truth is that open source software is the wild west; 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.


I'm wondering why you're getting down votes. Maybe someone who down votes could explain?

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


Comments like the grandparent are neither true nor false, but rather self-fulfilling.

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.


It is hard to believe that the leader of a project would look for "the slightest sign of misbehavior" to "jump on people".

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.


I'm responding to these sentences in your original post:

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


I read the text of the first comment as a warning to be prepared that the world is full of people who aren't part of the "code of conduct" culture wars, and so it's best to know that assholes may just come down on you.

Taking that comment as a sign of combativeness is definitely a signal of thin skin. Does that count as irony? Probably not.


I must say also that if you need a code of conduct, you are on the wrong track.

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.


Codes of conduct are just an effort to constrain conversation to a known-good state instead of attempting to achieve a state that permits all good conversation at the risk of permitting some bad. It's the equivalent of `-Wall -Werror -Wextra`. Your compiler will then reject some valid programs, but it will also prevent some unfortunate situations.

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.


Common sense doesn't scale. That's just a simple, observable fact. Relying upon it is asking for capricious leadership that grows increasingly opaque (and probably less satisfactory) as time passes.


I'm getting downvoted by people who don't like the reality, I guess; I'm just pointing out the truth as I have experienced it myself.

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.


It sounds like you are trying to give honest, pragmatic advice, in which case your downvotes are unfair. However, usually when people give that particular advice what they're really saying is that the bad behavior from other people is OK and that the person who feels bad because of it just needs to lighten up.

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.


> "I'm getting downvoted by people who don't like the reality, I guess; I'm just pointing out the truth as I have experienced it myself."

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?

https://news.ycombinator.com/item?id=10642500


> Do not hesitate to make it clear that that's not the place for such behaviour

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!


It's not an immutable rule. Communities get the behavior they tolerate.


I didn't downvote your parent, but I suspect the downvotes are for the apparent assumption that negativity is natural and inevitable, and the right thing to do is to give in to the system yourself. Many people believe this is the wrong approach, and that a better approach is to find or build better communities.


PS. I think there's also another aspect that made me like the image: the dying per se. A lot of open source projects are simply going to die, aren't they, and you don't want that as the author/maintainer, it's a part of your life after all. So the question very much becomes, it's either that project is going to die (with that part of me) or I'm going to protect it.

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


This seems like a non-optimal equilibrium. Any way we disrupt that?


First step: get everyone to agree that they must never use linux again. It is made by a Bad Person so it is a Bad Thing and anyone who uses it supports the Bad Person and becomes a Bad Person themselves.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: