HN Theater @HNTheaterMonth

The best talks and videos of Hacker News.

Hacker News Comments on
The secret life of open source developers

media.ccc.de · 102 HN points · 0 HN comments
HN Theater has aggregated all Hacker News stories and comments that mention media.ccc.de's video "The secret life of open source developers".
Watch on media.ccc.de [↗]
media.ccc.de Summary

A common question seen on many open source mailing lists is “When will you guys fix my bug? It is critical to my company!”...

HN Theater Rankings

Hacker News Stories and Comments

All the comments and stories posted to Hacker News that reference this video.
Sep 25, 2019 · 102 points, 37 comments · submitted by chippy
jchw
There are many reasons why I use open source, but far and away one of the biggest reasons is simply the power it gives you as a user. I know it’s a cliche but if there's a problem you want fixed, you really can go and fix it, and everyone else benefits. Once you have a full community, this becomes extremely powerful.

The thing is, though, I really only work on things in a more selfish manner. For example, I’ve been contributing a bit to a very cool project called Kaitai Struct. But as cool as it is, I’m contributing for myself, on things I personally care about.

If you work at a company and you are bickering with open source maintainers, you’re really missing the point of open source. If it’s costing you money, then it was making you money. Give a tiny bit of effort back, and you benefit yourself and incidentally everyone else too. It’s a win-win, and you won’t get blocked on Twitter. If you/your company genuinely can’t spare the expense of spending a few engineer hours a week on FOSS, but also can’t afford to buy support contracts or pay for commercial software, that really seems like a problem, doesn’t it?

Disclaimer: I probably do not do enough open source work to really speak with authority. If you want to judge for yourself, I am jchv on Github.

wiz21c
Hmmmm I dunno...

You make software available to other people, for free. But it's for them to use it (else, what's the point ?). So you're exposing yourself to users and users behave like users.

It's not because you give away something for free that its value (and the way that value is recognized, for example, by being polite) is any different.

The only thing you get by making it is the right, as a creator, to make it the way you want. That's the freedom you get (and what a beautiful one). But it doesn't give you any power on those who'll use it (well, except for the license); in particular, you have no power to make the users polite.

Now, of course, I prefer to talk with people who are polite and who express gratitude for the work I do for free. And of course I don't like rude people. But making FOSS doesn't change the human nature of you users. Even if you put hard work in it, you sacrifice a bit of your life...

So, the overall tone of the presentation seems a bit off to me. I would have preferred something like : here's why we do it, what motivates us, the success, the failures,... But the user, well, they just are what they are, software can't fix that.

(in case you wonder, yes, I've made some open source projects, one success, on failure and guess what, the success, at least to me, was measured by the number of users).

mugsie
> in particular, you have no power to make the users polite.

So very (and unfortunately) true. However they also have no power to make you do the thing they need straight away, or ever.

> Even if you put hard work in it, you sacrifice a bit of your life.

And this is bad. We need to move the needle away from this. It is incredibly exclusionary

I am a younger person, no kids, in a job where I was able to negotiate for open source maintenance time. By making "sacrifice" a requirement it makes it off putting for someone with kids, or working in a job that has them working long hours, or working multiple jobs.

> But the user, well, they just are what they are, software can't fix that.

No, software can't fix it. but highlighting the problem, and letting people possibly see what they are doing is not useful may change the user.

I have been a maintainer of a project for a long time, and I get everything from people pinging me in our IRC channel, to DMing me, to asking if I give them my skype ID so I can call into a bridge to help them debug an issue at midnight. We need to highlight this is not OK.

Personally, I really like the PowerDNS rule for open source support [1] - it sets expectations, and the base requirements from someone looking for help.

> the success, at least to me, was measured by the number of users

That is a valid metric, but just one. I personally measured the success of the project based on what people were using it (e.g. I would rather wikimedia vs 20 startups), but that metric is really person specific.

1 - https://blog.powerdns.com/2016/01/18/open-source-support-out...

mikekchar
> By making "sacrifice" a requirement it makes it off putting for someone with kids, or working in a job that has them working long hours, or working multiple jobs.

I think I understand what you are saying, but perhaps you are talking at cross purposes with the OP. I don't think anyone thinks that sacrifice is required from the perspective that you owe it to anyone to do anything in particular. But, as you know from maintaining a project, what you do is always a trade off.

Even if you negotiate time for open source maintenance in your work, you may suffer in your career compared to the person who focuses only on climbing the ladder. In fact, I do not allow my work to pay for my free software work -- because freedom is the thing I want from that work. People who pay usually expect something in return and I seriously am not inclined to give it to them (especially since the demands are usually after the fact).

There are many people who think you can have it all. If you spend hundreds of hours working on free software, working on not-free software, playing video games, watching reality shows, typing replies into HN, etc, etc, that time is spent. That's time you don't get to spend with your kids. Or your spouse. Or walking in the woods.

It's important that people who choose to do these things actually choose, I think. It's all too easy to get to a certain age and realise, "Well, crap. That's not what I wanted to have done".

So, yes, it's a sacrifice. You don't get to do it for free. Someone with kids, or working in a job that has long hours, or working multiple jobs often will not choose to spend hundreds of house writing free software. They have more important things to do, and that's totally OK.

laumars
> So, the overall tone of the presentation seems a bit off to me.

I can see why you might think that but I think everyone is entitled a platform to vent their frustrations on from time to time. They didn't come off rude and I think their comments are ones worth making. However I do agree it was very focused on their bad experiences with user/community interactions.

pgeorgi
> But it's for them to use it (else, what's the point ?).

The point is to have the software yourself. If it helps somebody else, all the better - but, like building a community, that's not necessarily the point.

thrower123
That's probably the only really sustainable way to have open source without making it into somebody's job.

Make what you want or need for yourself, and share it with other people. But be under no obligation to place their needs over your own.

notacoward
> The point is to have the software yourself.

That's certainly not true enough of the time to make such a general statement, and I contend it's mostly untrue. A lot of developers create OSS that they can't really use themselves. For example, I'm a maintainer for an OSS scale-out filesystem. I have no personal use for such a thing. The company that originally created it had no internal use for it, and the company that acquired them actively resisted its use internally. A lot of OSS has management or monitoring components, or integrations with other software, that the developers themselves don't use. Having the software yourself can't be a motive in these cases. Believe it or not, most OSS is written because the developers expect to make money from it and/or because they believe it will make the world a better place - not because they themselves use it.

pgeorgi
Right, I should have phrased it better: it's about self-interest. That interest _can_ be use of the software for yourself, and you're right, it can be selling support for the software or in open core models, selling add-ons.

I suppose "make the world a better place" can be a motivation as well (though I don't think it'll last very long for any individual unless they're RMS, maybe). There may be personal curiosity or education as motivation as well.

I don't think percentages between the motivations even matter for what the presentation is about (because it certainly isn't about users that pay for service contracts).

So there are transactional situations (support contract, other payments), there's "better world" idealism, and there's immediate self-interest ("I use this stuff myself").

Users being pushy on a communication medium demanding work from others with no fulfillment of these motivations that would back the demand doesn't even make the world a better place (pushy people != better world), so there's nothing in it for the devs.

Which gets back to the point of the presentation: if you want something fixed, step in (do it yourself, pay somebody to do it for you, ...). You can ask nicely, and that might even work at times, but you're not entitled to anybody agreeing to that kind of one-sided transaction.

notacoward
> it doesn't give you any power

The mistake is thinking it's about power. It's about aligning goals. A lot of the individual motivation for OSS is about making the world (what the developer believes is) a better place. Things that contribute to that vision are welcome; things that distract from it are not. The first category includes detailed bug reports and feature requests consistent with the software's existing direction. The second includes vague bug reports and requests for features that the developers don't believe in. Try demanding that security software should include a back door and see what kind of reception that gets.

The problem isn't that asking developers to do things for you is rude by itself. You can ask politely, they can decline politely, end of story. It's not even that pestering developers after such a refusal is rude, even though that's obviously the case. The problem is that such an approach isn't very effective. If you can convince the developers that fixing your problem is consistent with their own vision of how to make the project fulfill its existing goals, that's much more effective than mere badgering. If you want someone to do something for you, in any context, it's better to have them think of you as a collaborator than as someone who just makes demands.

ratmice
not sure it is about aligning goals, It seems more like maximizing collaboration in spite of diverging goals, and doing so without compromising upon them.

If your goals, and their goals either conflict or do not intersect, either one or both compromise, or dont -- and can't... In theory neither holds any more power than the other. In practice and politics collaboration as a social activity is subject held beliefs by one or both parties which distort this aspect of equal power.

shashankp
Right, so once you start "aligning goals", the concept of power and power itself just snaps out of existence, and the contributor ceases to be a human being and transcends into a divine roadmap.
neves
I'm curious: where the "secret life of" comes from? The earlier example that I could find was "the secret life of plants" a Stevie Wonder music.
Jur
My guess is it's meant as a hint at the misunderstanding from OSS-users with how open source developers benefit and contribute, which is unlike a commercial product or company
pramsey
I'd guess "The Secret Life of Walter Mitty", which is actually about his daydreams, his internal secret life, not some real world life behind closed doors.
lsofzz
Definitely a good refresher video. There is absolutely no doubt in my mind that its important to re-visit what we take for granted every single day and at the least be appreciative of all the amazing value open source software community brings.
tonyjstark
I once got a mail for a free software I published: "You're product sucks, I don't like it, why are you even doing this? There are much better alternatives out there.".

So what to do with that? I have to admit that this mail really stung for a while. Maybe I should have asked, why it sucked for this person, but then, why should I care about someone rude?

It didn't take me long to learn that some percentage of people tend to behave badly, especially on the internet and I can't do anything about it. I don't even exclude myself, I also wrote things to support addresses that I regret now. Overall, when I release something in the open now I do it because either I don't care, it's good for my image or I hope that people like it. I ignore rude comments and enjoy the happy ones. You would hope that people that know about OSS would be more considerate but they just aren't, free-loaders exist everywhere, it's a human problem, but it's also no reason to not stay idealistic.

EDIT: typo

userbinator
My usual response is "Then go use those alternatives instead of bothering me. It works fine for me."

The majority of the things I "throw out there", I know perfectly well will not be useful to a significant number of users, and that's fine. I just do it because it costs very little, and someone might find it useful.

(In case you were wondering, I'm not going to show the stuff I've put out here for a variety of reasons, sorry.)

derekp7
I would be happy if I could find an appropriate way to get more visibility for one of my open source projects (a snapshot backup system, called Snebu). My problem is that I don't want to feel spammy by throwing out references whenever an opportunity comes up (like I just did here), however on the flip side the more people that use it, the more support tickets that will come in that may ask for things that are outside of the design scope. And I would feel bad if I can't make something work for everybody.
sprash
> So what to do with that?

Negative feedback is the only form of valueable feedback. If you want to make your software better you should listen to negative feedback. Of course negative feedback often comes with emotional baggage but you should be above that kind of thing. The right strategy is actually to ignore positive feedback (because it is mostly worthless) and ask the people that give you negative feedback for more specifics and to be more precise about what they don't like.

lordgrenville
No, being abused by someone is not valuable and even very mature, confident people find it hard to handle emotionally. Negative feedback is helpful if presented politely or neutrally. Otherwise the form destroys the value of the content. (And by the way, positive feedback can be very valuable as well.)
sprash
> even very mature, confident people find it hard to handle emotionally.

One of the defining qualities of being "mature" and "confident" is to be able to fade out the emotional components and concentrate on the substance. This is the essential quality that seperates children from adults.

If you are fazed by some comments of random people on the internet then you are neither "mature" nor "confident". You either got to grow up or you will have a hard time.

> positive feedback can be very valuable as well.

Only for marketing, which you won't need if your product is good anyways. For example nobody did any "marketing" for git (except that Linus called his competitors "stupid and ugly" which was actually more like anit-marketing) but git is used by everybody because it is generally really good.

mmmrk
> If you are fazed by some comments of random people on the internet then you are neither "mature" nor "confident". You either got to grow up or you will have a hard time.

Not sure if you're trying to troll here, but being fazed by negativity is a perfectly normal human response. Framing it as a matter of maturity or confidence seems disingenuous to me. One can be trained to handle it better and turn it around or into something productive (i.e. conflict training for health care professionals) but the response remains.

imtringued
Why does negative feedback come with an obligation to slave away for a person that doesn't even care about what you are doing?
sprash
If you want your product to be good you have the "obligation" to listen to negative feedback. But you don't have the "obligation" to make a good product. If you don't care about your product you are going to ignore the feedback anyways.

> a person that doesn't even care

This is a misconception. People giving emotially loaded negative feedback actually "care" about your product much more than the average user.

unionpivo
> Your product sucks is not "negative feedback". It useless statement.

If you are paid and want to go fish to see if you can turn that into actual feedback, go ahead. It will take a lot of time and energy to pull something out, that will be useful. Posting your project to hn, various reddits or just twitter will get you a lot of more constructive feedback for less effort.

Besides I don't like rude people, responding to them just validates to them, that rudeness pays.

hnlmorg
Negative feedback can fall into two categories:

* constructive - which are polite and informative

* deconstructive - which are basically just someone being an arsehole.

The former stuff can be great at time but the examples being discussed fall firmly in the latter category.

sprash
Getting actually constructive feedback is super rare. When you ask emotionally engaged poeple to be more specific and precise about their problem they usually rationalize their anger and stop being angry when they actually notice what exactly they are angry about.
hnlmorg
Constructive feedback shouldn't be angry nor emotionally charged. That's just bad feedback.

I also don't think constructive feedback is super rare either. But I guess it depends on the project. eg some projects might have an appeal to different communities who are less often less patient with maintainers.

I think it's also worth remembering that maintainers do also need to be patient with the community. Sometimes I've seen maintainers not handle themselves well even when that feedback is PR fixing a bug or security vulnerability and there's no comment, suggestion nor anything else about the existing code base. In those instances you either just have to accept the maintainers vision (even when you disagree with it) or fork their project and maintain it yourself (which I've had to do before).

Ultimately though, most people I interact within OSS are friendly enough.

mugsie
Those sort of emails are really hard to deal with, especially when it is something you spent a lot of time working on.

I like the idea from the talk of just blocking them outright.

megous
I learened not to engage. It only ever once turned out, that the user actually spent quite a bit of time and contributed something as a result of me engaging futher and not just ignoring the e-mail. I guess some people may just be grumpy for whatever reason, and it will bubble up in the conversation.

But I don't usually care for the positive words that much either. I guess it's nice that my sw is helping someone, and whatnot, and great, but it's usually just a preface to some request or issue someone's having, often times solvable by reading the man page, or using --help, or checking if there's a newer version and trying that before bothering the authors.

The only people that stand out are those that just send a thank you without anything else. Quite rare.

What'd probably be more interesting to receive is just a thank you note and some info about what the user is using the sw for. That might as well be inspirational, at the very least, and perhaps an opener for some collaboration. I think I received such a message 2-3x in the last 15 years. Very rare! Maybe people need a bit of probing in the README to send such messages. :D

Isamu
>What'd probably be more interesting to receive is just a thank you note and some info about what the user is using the sw for.

Good idea, I will try to start doing that.

fenomas
I got a weird reverse one a few years back, to the effect of "your result is great, best I've seen, but the code is awful and I think you're not a good developer". What can you do? I just said something like "thanks, if you have any specific feedback please open an issue".

One thing that's nice about getting this via GitHub is, at least the rude comment maybe gets a couple of :thumbsdown:s on it, which can help you brush it off.

mikekchar
The internet is such a vacuum, though. Having someone actually read your code at all is kind of like a massive compliment. That they take the effort to email you about how much they hate it... In a weird way, it's kind of gratifying.

Great artists are never recognised in their time ;-) But seriously, I think you can think of it the same way. Would an artist ever make a new work if they didn't think they could make something better than their previous work? So there will always be truth about the deficiencies in a work. But can the reviewer understand the good parts?

Sometimes I get great pleasure in pieces of code that I wrote that I think nobody else will appreciate. It's kind of like an inside joke. If someone can't see it, it's not really unexpected -- perhaps more surprising if someone does see it.

I try to enjoy the fact that someone read my code. The hate mail is just the proof :-D

jp_sc
My answer would've been "fuck you", followed by blocking said user in all my repos.
hnlmorg
I used to really care about my own code quality in OSS but these days I just think it's a miracle if I manage to write any code (for the same reasons described in that video: full time job + family and other social obligations, eg I also do volunteer work most weekends).

The way I see it, writing working code is more important than writing "good" code most of the time. That's not to say I don't try and follow some degree of standards. My code usually contains a crap load of tests, definitely tries to follow the language idioms, etc. But I just don't try and get clever where I don't need to. Sometimes this means code isn't well optimised - however I can pick that up in a subsequent bug fix if that particular feature proves useful / popular.

Thus I have had one or two people comment before saying "it's not very well coded" and I usually just reply "it's very much living project where some code is working POC and other code has been rewritten and improved (sometimes many times over). However if you have any specific concerns or tips, I'd welcome them. Or better yet, chuck me a PR"

noonespecial
Funny thing about that: Complainers always seem to think that the code that they could have written but didn't is better than the code that you could write and did. The trifling fact that theirs does not, in fact, exist never seems to register with them.
HN Theater is an independent project and is not operated by Y Combinator or any of the video hosting platforms linked to on this site.
~ yaj@
;laksdfhjdhksalkfj more things
yahnd.com ~ Privacy Policy ~
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.