The secret life of open source developers [video]
media.ccc.de
media.ccc.de
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
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.)
I like the idea from the talk of just blocking them outright.
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
Good idea, I will try to start doing that.
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.
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"
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
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.
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.
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.
> 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.
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.
* 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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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...
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.