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