Why We Engage in FLOSS: Answers from Core Developers(arxiv.org)
arxiv.org
Why We Engage in FLOSS: Answers from Core Developers
https://arxiv.org/abs/1803.05741
62 comments
If you're on a phone, here's an HTML version of the article: https://www.arxiv-vanity.com/papers/1803.05741/
Brilliant! I'm never reading an arxiv PDF again!
This is great.
Do you know what software is being used to automate the conversion from pdf to html?
Do you know what software is being used to automate the conversion from pdf to html?
Their Show HN has the answers: https://news.ycombinator.com/item?id=15534580
Thank you!
I've never understood it. I've only had horrific experiences with my open source efforts. From the simplest cases like being ignored on PRs and tickets to mockery in social circles for algorithmic mistakes to finding out my work was enabling bad people to finding out people were misrepresenting my employment status while using my work in violation of the license, I don't think I've ever once had a positive experience with open source as a producer. Hell, I never even knew my extensions to the clojure time library were even being used until another maintainer who had added some incremental stuff over my work disappeared.
I wish I could go back in time and tell my younger self it was all a waste of time and I shouldn't do it. Maybe then I could be more positive about it now that I'm better at writing software.
I wish I could go back in time and tell my younger self it was all a waste of time and I shouldn't do it. Maybe then I could be more positive about it now that I'm better at writing software.
You have had a lot of negative responses (unjustified in my opinion), so I hope my comment makes it through.
I have written two medium sized projects, one of which is quite popular.
I had great fun writing the software, but maintaining it in public is hell. OSS has turned into a popularity contest, with people associating themselves with projects quite publicly (conference talks) but doing little work.
Generally, there is little respect for creators, a lot of useless bickering and talking and self promotion.
I've come to the same conclusion that it is a waste of time.
I have written two medium sized projects, one of which is quite popular.
I had great fun writing the software, but maintaining it in public is hell. OSS has turned into a popularity contest, with people associating themselves with projects quite publicly (conference talks) but doing little work.
Generally, there is little respect for creators, a lot of useless bickering and talking and self promotion.
I've come to the same conclusion that it is a waste of time.
> From the simplest cases like being ignored on PRs and tickets
Yeah, this can be irksome when trying to lend a hand. As a maintainer of a few projects I try to put in a big effort to make PRs easy as you do have someone interested in rather directly helping the project.
PRs also open up some opportunities to help guide new contributors which can be fun within itself (everyone has to start somewhere). In the best case scenario being friendly with PRs can result in a single drive-by patch turning into a more long term collaboration.
I do also try to address other tickets, though I do admit that some just fall through the cracks. Many times the first submission will contain incomplete or inaccurate information and it takes a lot of work from both parties to document what the problem is and how to resolve it (even before touching any code). I do think it's great to see people trying to out a project by documenting issues in tickets, but sometimes it just takes too much energy at the end of the day to 'properly' address them when a project has many users, but few devs/contributors.
> I've only had horrific experiences with my open source efforts.
It's a shame that's been your experience. In an ideal world open source communities help people learn, build cool stuff, and scratch an itch, but it doesn't always work out.
Yeah, this can be irksome when trying to lend a hand. As a maintainer of a few projects I try to put in a big effort to make PRs easy as you do have someone interested in rather directly helping the project.
PRs also open up some opportunities to help guide new contributors which can be fun within itself (everyone has to start somewhere). In the best case scenario being friendly with PRs can result in a single drive-by patch turning into a more long term collaboration.
I do also try to address other tickets, though I do admit that some just fall through the cracks. Many times the first submission will contain incomplete or inaccurate information and it takes a lot of work from both parties to document what the problem is and how to resolve it (even before touching any code). I do think it's great to see people trying to out a project by documenting issues in tickets, but sometimes it just takes too much energy at the end of the day to 'properly' address them when a project has many users, but few devs/contributors.
> I've only had horrific experiences with my open source efforts.
It's a shame that's been your experience. In an ideal world open source communities help people learn, build cool stuff, and scratch an itch, but it doesn't always work out.
> From the simplest cases like being ignored on PRs and tickets [...]
Yes, that's unfortunately a big problem in FLOSS. It will take a big effort to change that. But I think there are some communities who take mentorship seriously that are incrementally improving this.
> to mockery in social circles for algorithmic mistakes [...]
That's 100% unacceptable.
Did this happen on a public mailing list? If so, can you post a link?
> to finding out my work was enabling bad people [...]
I can't figure out what this would mean, or how it is relevant to open source as opposed to proprietary software.
> to finding out people were misrepresenting my employment status while using my work in violation of the license, I don't think I've ever once had a positive experience with open source as a producer.
Those last two seem exceptional. But you should report the person who was mocking you for making a mistake. That kind of behavior has no place in FLOSS and should be stamped out.
Yes, that's unfortunately a big problem in FLOSS. It will take a big effort to change that. But I think there are some communities who take mentorship seriously that are incrementally improving this.
> to mockery in social circles for algorithmic mistakes [...]
That's 100% unacceptable.
Did this happen on a public mailing list? If so, can you post a link?
> to finding out my work was enabling bad people [...]
I can't figure out what this would mean, or how it is relevant to open source as opposed to proprietary software.
> to finding out people were misrepresenting my employment status while using my work in violation of the license, I don't think I've ever once had a positive experience with open source as a producer.
Those last two seem exceptional. But you should report the person who was mocking you for making a mistake. That kind of behavior has no place in FLOSS and should be stamped out.
> I can't figure out what this would mean, or how it is relevant to open source as opposed to proprietary software.
It's not unique to open source.
> Those last two seem exceptional. But you should report the person who was mocking you for making a mistake. That kind of behavior has no place in FLOSS and should be stamped out.
There is a reason I switched away from the MIT license. Someone unrelated was using my name and my work to give their startup legitimacy. It paid off, too, they are a sustainable company now. Not much I can do about it.
It's not unique to open source.
> Those last two seem exceptional. But you should report the person who was mocking you for making a mistake. That kind of behavior has no place in FLOSS and should be stamped out.
There is a reason I switched away from the MIT license. Someone unrelated was using my name and my work to give their startup legitimacy. It paid off, too, they are a sustainable company now. Not much I can do about it.
I don't see how a different license would have helped you here? The license has no influence on someone misrepresenting your relationship with his company, that's just not covered in software licenses.
You probably switched to GPL to make your software less directly usable for companies?
You probably switched to GPL to make your software less directly usable for companies?
The 3-clause BSD license includes:
"Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
"Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
> From the simplest cases like being ignored on PRs
You're not entitled to having your PRs merged, or even having anyone look at them. PRs not of particular interest to those maintaining the project simply get low priority. Especially with volunteer work, time is limited and while your PR might appear large and of importance to you, it may not look like that from other perspectives.
You're not entitled to having your PRs merged, or even having anyone look at them. PRs not of particular interest to those maintaining the project simply get low priority. Especially with volunteer work, time is limited and while your PR might appear large and of importance to you, it may not look like that from other perspectives.
This feels like you were forcing yourself to contribute for whatever reason.
The best results are when you are genuinely interested in your work and in the process of making software better.
The best results are when you are genuinely interested in your work and in the process of making software better.
Some of the projects were in fact my original work. I was genuinely interested.
I get similar negative feedback for writing, often. I don't write issue reports on github because I'm tired of people being angry at me for reporting problems or being derisive because I don't have the workarounds they didn't write down.
I get similar negative feedback for writing, often. I don't write issue reports on github because I'm tired of people being angry at me for reporting problems or being derisive because I don't have the workarounds they didn't write down.
This sort of thing varies wildly from project-to-project. I've had a range of experiences from the type you describe to developers bending over backwards without prompting.
Could you provide some links so we can all see exactly what behaviors to avoid?
The OpenSSL business. Everyone and their uncle were suddenly expert programmers who would never have written a bug into code.
People sucked so bad at reading code, sucked so bad at writing an SSL library, and sucked so bad at auditing the code they depended on. And yet the OpenSSL guys were supposedly incompetent.
People sucked so bad at reading code, sucked so bad at writing an SSL library, and sucked so bad at auditing the code they depended on. And yet the OpenSSL guys were supposedly incompetent.
On the other hand, there are plenty of people who aren't going to bother even looking at your software unless it's open source, especially in certain domains. (That Apple released Swift as open source, for instance, is evidence of this, since they are generally not very positively oriented towards open source.)
How are you experiences of other volunteer work?
I've done volunteer teaching and some volunteer civil work and those were fun, mostly. Especially the teaching part. Is your thought, "Perhaps this person just doesn't enjoy volunteer work?"
Funny, I've had the exact opposite experience. Maybe you were just trying to associate with poorly-led projects?
Edit: Not all open source projects have shitty leaders, but some do, and it's not always obvious which ones those are until you've invested some non-zero amount of time/effort into it.
Edit: Not all open source projects have shitty leaders, but some do, and it's not always obvious which ones those are until you've invested some non-zero amount of time/effort into it.
Perhaps, I should not be surprised the first response here is, "Well maybe that's your fault for not having a crystal ball which can predict the actions of strangers." That attitude is part of the problem. Similarly, "My experience was fine, so clearly your bad experience needs to be invalidated" is a toxic attitude.
Well, there are literally millions of people who don't share your same experience, so rather than claim that everyone is wrong and open source development doesn't work, maybe you are doing something wrong. Just a suggestion, because it totally does work for many people. Maybe you just have to find the right group of people to work with. There are a few shitty projects, but you'll find bad apples in many areas of life.
> so rather than claim that everyone is wrong
I didn't. This is your inability to tolerate a different viewpoint. I didn't say you had a bad experience, just that I can't relate to the good ones. I qualified every statement with _I_, _my experience_, and _feel_ and you're still willing to stand up and argue with me about it.
And that is, in fact, a toxic attitude. You're arguing that I'm neither allowed to have nor relate negative experiences.
Stop doing that. Stop doing what you're doing right now. It serves no purpose other than to further embed this toxic attitude into a community you obviously love and want to represent positively.
I didn't. This is your inability to tolerate a different viewpoint. I didn't say you had a bad experience, just that I can't relate to the good ones. I qualified every statement with _I_, _my experience_, and _feel_ and you're still willing to stand up and argue with me about it.
And that is, in fact, a toxic attitude. You're arguing that I'm neither allowed to have nor relate negative experiences.
Stop doing that. Stop doing what you're doing right now. It serves no purpose other than to further embed this toxic attitude into a community you obviously love and want to represent positively.
Stop interpretting everything as a personal attack. It makes it seem like you were the bad apple, by immediately conflating contradictory statements and experiences into personal attacks. I would not want to work with such a person, in an open source project or otherwise.
I merely suggested that your bad experiences might have been because of the projects you worked with, so a general statement of "open source bad" might be a bit extreme because many others have had positive experiences. I'm sorry you had a shitty experience working on open source projects. That sucks for everyone. Not all open source projects have shitty leaders, but some do, and it's not always obvious which ones those are until you've invested some non-zero amount of time/effort into it.
I merely suggested that your bad experiences might have been because of the projects you worked with, so a general statement of "open source bad" might be a bit extreme because many others have had positive experiences. I'm sorry you had a shitty experience working on open source projects. That sucks for everyone. Not all open source projects have shitty leaders, but some do, and it's not always obvious which ones those are until you've invested some non-zero amount of time/effort into it.
> Not all open source projects have shitty leaders, but some do, and it's not always obvious which ones those are until you've invested some non-zero amount of time/effort into it.
If this was your intent, then I apologize for misreading it. But being very clear: this is not how the original text of your post read.
If this was your intent, then I apologize for misreading it. But being very clear: this is not how the original text of your post read.
Now he's contributed his impression and every comment is browbeating him or criticising him. Sounds like he got very unlucky. Wouldn't it be worth it to discuss how that could be mitigated?
Also, people always forget the rest of that phrase: A bad apple spoils the bunch. Pretty important nuance!
Also, people always forget the rest of that phrase: A bad apple spoils the bunch. Pretty important nuance!
Your original comment is pretty toxic. What do you want to imply by your original anecdotal comment other than grandstanding? This is a research article, and you could suggest that the researchers look at more negative aspects of open source that could affect developers but to say basically open source is terrible is ridiculous
How is relating my experiences adjacent to the subject of the article, as someone who has in fact released two rather large open source projects (one with a fair amount of ongoing traction) toxic?
Just because it documented experiences that were negative?
The responses so far:
- It's your fault for doing it (true, but unhelpful).
- Maybe you should care (I released the original work, I cared enough)
- Even talking about adjacent experiences is inappropriate and and you should stop. (yours)
Just because it documented experiences that were negative?
The responses so far:
- It's your fault for doing it (true, but unhelpful).
- Maybe you should care (I released the original work, I cared enough)
- Even talking about adjacent experiences is inappropriate and and you should stop. (yours)
If they're doing research, they'd need the negative reports for accuracy. KirinDave would be one data point among others in that. We know they exist since Nadia Eghbal did collect that information:
https://medium.com/@nayafia/how-i-stumbled-upon-the-internet...
If anything, people should see the big picture of the range of experiences they might have so they're not being misled into getting into something that's a gamble. It might be good for them, it might be really bad, and it might be something in between. FOSS promoters don't usually sell it that way, though.
https://medium.com/@nayafia/how-i-stumbled-upon-the-internet...
If anything, people should see the big picture of the range of experiences they might have so they're not being misled into getting into something that's a gamble. It might be good for them, it might be really bad, and it might be something in between. FOSS promoters don't usually sell it that way, though.
Since you don’t give verifiable links to examples so we can judge for ourselves, and your reported experiences don’t match the majority’s, the rest of us are more or less forced to believe the simplest explanation:
There’s a known principle that goes “If you think that everyone around you is an asshole, they’re not the assholes, you are.”. This would be the simplest explanation in this case, since we don’t know anything else about you.
Of course, you could easily remedy this by posting enough examples to change our minds, but until you do, Occam’s razor must reign supreme.
There’s a known principle that goes “If you think that everyone around you is an asshole, they’re not the assholes, you are.”. This would be the simplest explanation in this case, since we don’t know anything else about you.
Of course, you could easily remedy this by posting enough examples to change our minds, but until you do, Occam’s razor must reign supreme.
If you find yourself feeling the need to call someone an asshole and require evidence of someone else's personal experiences, consider that leaving well enough alone is the right approach.
Especially when that person is politely reporting experiences with behavior that from my eyes, resembles yours exactly.
Especially when that person is politely reporting experiences with behavior that from my eyes, resembles yours exactly.
Or they were just unlucky in their in their interactions (I doubt many people would claim that all interactions in Open Source are good), or perceive some things differently than others, or ...
there's more than enough Open-Source maintainers complaining about bad interactions. Indeed many of the parents complaints are also reflected in the study as things people experienced as barriers to contributing. Luckily for many of them the good outweighs the bad, but that doesn't mean those for which it doesn't are automatically assholes.
It's especially bad to justify this broad brush with "minority experience".
there's more than enough Open-Source maintainers complaining about bad interactions. Indeed many of the parents complaints are also reflected in the study as things people experienced as barriers to contributing. Luckily for many of them the good outweighs the bad, but that doesn't mean those for which it doesn't are automatically assholes.
It's especially bad to justify this broad brush with "minority experience".
Sure, there are many possible explanations, but what I wrote was the most likely one.
Nothing I can do can change the outcome either way, teddyh. I suspect you've already decided how you feel about me.
People are seeing a candid discussion of subjective experience as an indictment of theirs. This is another action I regret. I thought perhaps a related but dissenting viewpoint would have value to the conversation, but I guess not. This conversation itself is an example of the kind of negative experience I'm talking about.
I'm sorry my post offended you. It wasn't my intent.
People are seeing a candid discussion of subjective experience as an indictment of theirs. This is another action I regret. I thought perhaps a related but dissenting viewpoint would have value to the conversation, but I guess not. This conversation itself is an example of the kind of negative experience I'm talking about.
I'm sorry my post offended you. It wasn't my intent.
I've had good and bad experiences trying to get code merged and in the end all I really care about is that people get to benefit from the labor of love of teaching myself to code.
Had people merge significant chunks of code without even a pat on the head but also had my name in the credits of one of the Blender Institute movies so in the end it probably all cosmically balances out.
I don't ascribe malicious intent to the bad experiences (nor really consider them "bad" but (mostly) just people being annoying for whatever reason) so don't take offence, just realize people have different priorities than me. Though in one case I did actively avoid working on a part of the code base that one particular dev was in charge of due to multiple "bad" experiences, I have better things to do than beg for code reviews and feel "lucky" when I get them -- actually...the best thing with working with software geared towards artists is you can outsource the begging to the people who directly benefit from the feature since they need it yesterday to finish their project.
--edit--
Bloody hell, replied to a flagged subthread...
Had people merge significant chunks of code without even a pat on the head but also had my name in the credits of one of the Blender Institute movies so in the end it probably all cosmically balances out.
I don't ascribe malicious intent to the bad experiences (nor really consider them "bad" but (mostly) just people being annoying for whatever reason) so don't take offence, just realize people have different priorities than me. Though in one case I did actively avoid working on a part of the code base that one particular dev was in charge of due to multiple "bad" experiences, I have better things to do than beg for code reviews and feel "lucky" when I get them -- actually...the best thing with working with software geared towards artists is you can outsource the begging to the people who directly benefit from the feature since they need it yesterday to finish their project.
--edit--
Bloody hell, replied to a flagged subthread...
> Nothing I can do can change the outcome either way, teddyh.
On the contrary, I told you exactly how to change my mind (and that of others): Point to examples that we can read for ourselves and decide that yes, you really were treated badly in all these cases. That really would change minds.
> I suspect you've already decided how you feel about me.
Again, you are mistaken. You are just some random anonymous person on the internet; you could very well be an asshole; what do I know? But if that is the most likely explanation of your reported experience, then sure, why not. I can easily use that as a working hypotheses, because I have no vested interest in having a good opinion about you; I don’t care about you at all; I don’t even know you, so I have no strong opinion about you. I do care about people reading your description and (even though you were careful enough to not do so yourself) generalizing your experiences to the whole of the community, and being discouraged thereby.
You must understand that when you write something along the lines of “I had only bad experiences doing X, and I wish I could travel back in time to tell myself to not ever do X.”, it will be taken as a generalized advice to everyone, and be more or less rightly criticized as if it were such.
If you instead had written about the same experiences using words like “People can have bad experiences too; I only had bad experiences doing X, and therefore I gave it up. Was I just unlucky?”, I believe that people would be much more open to either agree or disagree. But that is not how you presented it.
> I'm sorry my post offended you. It wasn't my intent.
Not offended. Just worried that people might draw unlikely conclusions from your limited sample of experiences (especially when the submitted article is an actual scientific paper about this very issue).
On the contrary, I told you exactly how to change my mind (and that of others): Point to examples that we can read for ourselves and decide that yes, you really were treated badly in all these cases. That really would change minds.
> I suspect you've already decided how you feel about me.
Again, you are mistaken. You are just some random anonymous person on the internet; you could very well be an asshole; what do I know? But if that is the most likely explanation of your reported experience, then sure, why not. I can easily use that as a working hypotheses, because I have no vested interest in having a good opinion about you; I don’t care about you at all; I don’t even know you, so I have no strong opinion about you. I do care about people reading your description and (even though you were careful enough to not do so yourself) generalizing your experiences to the whole of the community, and being discouraged thereby.
You must understand that when you write something along the lines of “I had only bad experiences doing X, and I wish I could travel back in time to tell myself to not ever do X.”, it will be taken as a generalized advice to everyone, and be more or less rightly criticized as if it were such.
If you instead had written about the same experiences using words like “People can have bad experiences too; I only had bad experiences doing X, and therefore I gave it up. Was I just unlucky?”, I believe that people would be much more open to either agree or disagree. But that is not how you presented it.
> I'm sorry my post offended you. It wasn't my intent.
Not offended. Just worried that people might draw unlikely conclusions from your limited sample of experiences (especially when the submitted article is an actual scientific paper about this very issue).
> On the contrary, I told you exactly how to change my mind (and that of others): Point to examples that we can read for ourselves and decide that yes, you really were treated badly in all these cases. That really would change minds.
Consider for a moment what you're asking me to do: name names. In several cases, for events over 5 years old. You're asking me to expose myself to more contention and argument to convince you that my feelings are not dirty lies that slander the OSS community.
The most respectful thing I can do for all parties is relate my experiences. If you find them to be so outrageously implausible that you feel the need to call me an asshole, there's not much I am willing to do that will change that. You're right, I could link to examples of people behaving badly (and inevitably, cases where I have behaved badly because those exist). But there is very little upside in that for me.
Like I said, this demand predetermines the outcome. It asks me to shoulder more commentary like this for the dubious promise of your personal approval. That's not a very compelling value proposition. Add to that that your tone disinclines me to believe you're actually asking in good faith, and I have absolutely no reason at all to reopen these topics.
Consider for a moment what you're asking me to do: name names. In several cases, for events over 5 years old. You're asking me to expose myself to more contention and argument to convince you that my feelings are not dirty lies that slander the OSS community.
The most respectful thing I can do for all parties is relate my experiences. If you find them to be so outrageously implausible that you feel the need to call me an asshole, there's not much I am willing to do that will change that. You're right, I could link to examples of people behaving badly (and inevitably, cases where I have behaved badly because those exist). But there is very little upside in that for me.
Like I said, this demand predetermines the outcome. It asks me to shoulder more commentary like this for the dubious promise of your personal approval. That's not a very compelling value proposition. Add to that that your tone disinclines me to believe you're actually asking in good faith, and I have absolutely no reason at all to reopen these topics.
I’m sorry, I did not mean to ask for anything you were unwilling to do; your initial text did not give the impression that you were unwilling to name names, it just lacked details or links – on the contrary, you even named “my extensions to the clojure time library”, which could conceivably be used by somebody to look up said details, so I did not see anything to indicate you wanted to avoid “naming names”.
Certainly, nobody can force you to name names if you don’t want to, but vague accusations (such as yours) towards a community deserves to at least be questioned and probed for evidence. Some people would say to not say anything which you’re not prepared to back up with evidence, but I’m not sure I would go that far. Unsubstantiated claims have some value if presented carefully and tactfully. But you appeared to be neither; you seemed to make sweeping generalizations (while carefully not literally doing it), but not giving examples or even details. This style is a non-working strategy for effecting change, which I would assume to be the goal of us all.
> Add to that that your tone disinclines me to believe you're actually asking in good faith
I’m sorry to hear that; I did not mean to give such an impression. I would certainly say that I believe myself to be acting in good faith, such as it is; my goal is to give people what I believe to be a reasonably accurate picture of what kind of treatment they can expect from contributing to FLOSS, to counter the view they might get from your initial comment.
In conclusion: There is a good possibility that you were merely unlucky, either with individual authors or toxic projects. That is simply a slightly more unlikely explanation than the simplest one which I gave. Please don’t be offended by it; I actually only offered it as a motivation for you to disprove it by giving us examples, so we might see for ourselves, and I fully expected you to simply give a few links to end the matter. Since you won’t (for reasons I fully accept), the discussion took an unexpectedly unproductive turn, and I am sorry for that. I never accounted for the possibility of you to not wanting to give details or references, but I should have.
Certainly, nobody can force you to name names if you don’t want to, but vague accusations (such as yours) towards a community deserves to at least be questioned and probed for evidence. Some people would say to not say anything which you’re not prepared to back up with evidence, but I’m not sure I would go that far. Unsubstantiated claims have some value if presented carefully and tactfully. But you appeared to be neither; you seemed to make sweeping generalizations (while carefully not literally doing it), but not giving examples or even details. This style is a non-working strategy for effecting change, which I would assume to be the goal of us all.
> Add to that that your tone disinclines me to believe you're actually asking in good faith
I’m sorry to hear that; I did not mean to give such an impression. I would certainly say that I believe myself to be acting in good faith, such as it is; my goal is to give people what I believe to be a reasonably accurate picture of what kind of treatment they can expect from contributing to FLOSS, to counter the view they might get from your initial comment.
In conclusion: There is a good possibility that you were merely unlucky, either with individual authors or toxic projects. That is simply a slightly more unlikely explanation than the simplest one which I gave. Please don’t be offended by it; I actually only offered it as a motivation for you to disprove it by giving us examples, so we might see for ourselves, and I fully expected you to simply give a few links to end the matter. Since you won’t (for reasons I fully accept), the discussion took an unexpectedly unproductive turn, and I am sorry for that. I never accounted for the possibility of you to not wanting to give details or references, but I should have.
If someone expresses positive experience, do you demand link of proof too? If no, why the difference? Why should negative experience cross higher tresold then positive one?
Since you’re asking me directly, I will answer.
The easy answer would be to say that it is because one experience is very likely and widely reported to be the most common one, and the other is not. “Extraordinary claims requires extraordinary evidence”, and all that. But, while mostly true, it isn’t the best answer, and it is slightly misleading, as “proof” isn’t really what is needed.
The more correct answer is that good experiences would not require anything to change, but bad experiences suggests that something needs to change, and links to specific instances would help in determine the exact cause of the problem. It’s not proof, per se, that is needed, it’s references and sources, in a scientific sense – if the reports of bad experiences were assumed to be accurately made in good faith, it still wouldn’t be helpful, since barely anything can be analyzed to determine any cause of action, since there are no details.
The easy answer would be to say that it is because one experience is very likely and widely reported to be the most common one, and the other is not. “Extraordinary claims requires extraordinary evidence”, and all that. But, while mostly true, it isn’t the best answer, and it is slightly misleading, as “proof” isn’t really what is needed.
The more correct answer is that good experiences would not require anything to change, but bad experiences suggests that something needs to change, and links to specific instances would help in determine the exact cause of the problem. It’s not proof, per se, that is needed, it’s references and sources, in a scientific sense – if the reports of bad experiences were assumed to be accurately made in good faith, it still wouldn’t be helpful, since barely anything can be analyzed to determine any cause of action, since there are no details.
As a core contributor of some very popular github projects, I get a ton of emails from researchers wanting me to fill out surveys. It would be nice if it was somehow centralized instead of a lot of independent people trying to do the same work over and over.
With respect to community surveys, I think they can be a good thing, but they're annoying when it looks like the author is on a fishing trip rather than trying to identify the answers to a few new specific questions.
Usually my off-the-cuff response is "What are you trying to understand which isn't already discussed heavily?". New areas of research and some small amount of redundant work is fine, but too often everyone covers the same base without aiming to take a deeper dive on something new.
Usually my off-the-cuff response is "What are you trying to understand which isn't already discussed heavily?". New areas of research and some small amount of redundant work is fine, but too often everyone covers the same base without aiming to take a deeper dive on something new.
There is the plus that, if they all arrive at the same results, that gives greater confidence in the conclusion. Redundancy also has its good side.
From the article (fig. 13a)
Motivations: - To improve the project because I am using it - To have a volunteer work - I have interest or expertise on the project domain
Project characteristics: - Friendly community - Availability of the project leaders - Unit tests
Barriers: - Lack of time of project leaders - Large and complex project - Unclear, complex or buggy code
Motivations: - To improve the project because I am using it - To have a volunteer work - I have interest or expertise on the project domain
Project characteristics: - Friendly community - Availability of the project leaders - Unit tests
Barriers: - Lack of time of project leaders - Large and complex project - Unclear, complex or buggy code
I think the converse would be very interesting as well: Why do people dis-engage?
The paper also addresses that at section 3, Barriers[1]:
- Large and complex project
- Lack of time of the project leaders
- Non-clear, complex or buggy codebase
- Lack of time of the own contributor
- Inappropriate design or architecture
- etc.
In addition to people dis-engaging, it's interesting to see both in this paper and in other literature what factors can create feedback loops.
For instance a project which loses a few contributors could result in the other contributors getting overloaded/burnt-out, which could then repel new contributors, thus forming a negative feedback loop.
Usually when I see these sorts of papers come up I try to look at both the short term actionable items to-do/to-avoid as well as other notes which impact more long-term project/community health. There are a bunch of cool papers in this space and it's neat to see the slightly different views each one comes up with.
For instance a project which loses a few contributors could result in the other contributors getting overloaded/burnt-out, which could then repel new contributors, thus forming a negative feedback loop.
Usually when I see these sorts of papers come up I try to look at both the short term actionable items to-do/to-avoid as well as other notes which impact more long-term project/community health. There are a bunch of cool papers in this space and it's neat to see the slightly different views each one comes up with.
Figure 9.b seems to have a problem with sampling? Half numbers of core contributors are plotted even though they (thankfully) don't correspond to the samples.
No, the negative lobes just show how contributor numbers are whole numbers. Natural, even.
Yes, but do we need that information? It could be the case of any integer graph. Either just plot the samples, or curve them. Don't curve them with intermediary values, that means even less than a trend curve.
Edit: okay maybe the violin plot as it is shown has the correct density information. I disregarded that aspect of the plot.
Edit: okay maybe the violin plot as it is shown has the correct density information. I disregarded that aspect of the plot.
[deleted]
My takeaway from the paper (read two months ago) was that core contributors looking to encourage more core contributors should focus on making great software which will have dedicated users some of whom might be motivated to help project eventually as a core contributor.
I'm on the other end of the spectrum, I have a bunch of low popularity projects on Github (Python, C, Puppet, a little bit of Perl). Low popularity meaning above 0 users, but users can be counted on your fingers.
My motivation are often the following:
* I've encountered common issues at work that are generic (ie not tide to the functional domain of my employer), with no time to spent on it at work, as a consequence I chose to implement the thing on my free time and open source it because it kind of frustrated me.
examples:
- web UI to manage DNS zones content, (previously the team was managing their dev boxes IPs in an excel sheet).
- web UI for LDAP management, with a simple notion of "Roles".
- tools to convert Visio files (specially stencils) to SVG as my company wasn't big on buying Visio licenses, and I was under Linux 99% of the time anyway.
- a generic enough puppet modules to manage samba.
* To learn new stuff or be better in a specific language. I've a bunch of project like that, were part of the goal was to unrust my skills or to learn how to setup unit test, continuous integration and code coverage. This is the way I learned pytest, cunit, gcov, Jenkins, Travis-ci, CMake.
Sometimes my motivation are a little weird. One time, I've created an empty repository with a description and didn't start the implementation of what I had in mind. Someone stared it out of nowhere, and I felt compelled to actually implement it. It did learn me in the end that if you want a good "ini" like parser in C, OpenSSL is quite decent with a permissive license.
Another time, I created a very rough Python library to display histograms in ASCII. I just dump it on GitHub with no setup.py, nearly no documentation and everything pretty much unorganized (initially, it was an half baked stat module for an IRC bot). Someone submitted a PR righting the thing (proper layout, a setup.py file, the thing being published on pypi and some rst documentation). I accepted the PR gladly (and a few others after that) and I felt compelled to add at least some unit tests.
This library code is absolutely horrible (even me, the creator, I spent a few days figuring out all the edge cases), bu strangely enough, it's my most successful library/tool (yay, a whooping 81 stars \o/) and people do contribute to it.
It brings me to another point: external contributions.
From what I've experienced, people will more often create issues than submit PRs. That's ok, but it can also be a little bit of a strain if your are the sole maintainer of a project as I am. I know that on some of my projects, issues can be left unanswered for months if not years.
For PRs, you are more likely to receive PRs if your language is easily accessible. On my Python projects, I got a bunch of PRs, some of them far beyond simple bug fixes (ex: implementing new really interesting functionalities, like color support in the previously mentioned ASCII graph library). In my C projects, I almost never get PRs, and I'm guessing the language is a huge barrier, even if, in my opinion, the code is far more readable and structured than some of my Python projects. An interesting mix of the 2 is actually a Samba Puppet module. I've a bunch of Puppet DSL code, where I've received ton of PRs, but I've also a little ruby code (type providers), this one I almost never get PRs for.
Lastly, for a bunch of my project I feel a little culpability since I don't maintain them appropriately, there is a bunch of my projects where I lost interest in the subject (example, my puppet module: I don't use Puppet anymore). But at the same time, I feel a little responsible for all the people asking me questions or submitting bugs to these projects.
PS: why fundamentally do I contribute in Open Source? Mostly because of: hey, I've implemented this, it was useful to me at some point, it might be useful to other people, why should I keep it private? Other people could pick it up, and use it to do some incredible things.
My motivation are often the following:
* I've encountered common issues at work that are generic (ie not tide to the functional domain of my employer), with no time to spent on it at work, as a consequence I chose to implement the thing on my free time and open source it because it kind of frustrated me.
examples:
- web UI to manage DNS zones content, (previously the team was managing their dev boxes IPs in an excel sheet).
- web UI for LDAP management, with a simple notion of "Roles".
- tools to convert Visio files (specially stencils) to SVG as my company wasn't big on buying Visio licenses, and I was under Linux 99% of the time anyway.
- a generic enough puppet modules to manage samba.
* To learn new stuff or be better in a specific language. I've a bunch of project like that, were part of the goal was to unrust my skills or to learn how to setup unit test, continuous integration and code coverage. This is the way I learned pytest, cunit, gcov, Jenkins, Travis-ci, CMake.
Sometimes my motivation are a little weird. One time, I've created an empty repository with a description and didn't start the implementation of what I had in mind. Someone stared it out of nowhere, and I felt compelled to actually implement it. It did learn me in the end that if you want a good "ini" like parser in C, OpenSSL is quite decent with a permissive license.
Another time, I created a very rough Python library to display histograms in ASCII. I just dump it on GitHub with no setup.py, nearly no documentation and everything pretty much unorganized (initially, it was an half baked stat module for an IRC bot). Someone submitted a PR righting the thing (proper layout, a setup.py file, the thing being published on pypi and some rst documentation). I accepted the PR gladly (and a few others after that) and I felt compelled to add at least some unit tests.
This library code is absolutely horrible (even me, the creator, I spent a few days figuring out all the edge cases), bu strangely enough, it's my most successful library/tool (yay, a whooping 81 stars \o/) and people do contribute to it.
It brings me to another point: external contributions.
From what I've experienced, people will more often create issues than submit PRs. That's ok, but it can also be a little bit of a strain if your are the sole maintainer of a project as I am. I know that on some of my projects, issues can be left unanswered for months if not years.
For PRs, you are more likely to receive PRs if your language is easily accessible. On my Python projects, I got a bunch of PRs, some of them far beyond simple bug fixes (ex: implementing new really interesting functionalities, like color support in the previously mentioned ASCII graph library). In my C projects, I almost never get PRs, and I'm guessing the language is a huge barrier, even if, in my opinion, the code is far more readable and structured than some of my Python projects. An interesting mix of the 2 is actually a Samba Puppet module. I've a bunch of Puppet DSL code, where I've received ton of PRs, but I've also a little ruby code (type providers), this one I almost never get PRs for.
Lastly, for a bunch of my project I feel a little culpability since I don't maintain them appropriately, there is a bunch of my projects where I lost interest in the subject (example, my puppet module: I don't use Puppet anymore). But at the same time, I feel a little responsible for all the people asking me questions or submitting bugs to these projects.
PS: why fundamentally do I contribute in Open Source? Mostly because of: hey, I've implemented this, it was useful to me at some point, it might be useful to other people, why should I keep it private? Other people could pick it up, and use it to do some incredible things.
Saying FLOSS instead of "open source" is like saying "LBQTXRSABCFGHKWPÖ" instead of "queer". Putting more letters doesn't make it more inclusive or anything, it just makes you look less serious.
That's actually a reasonable analogy, but I think we only seem "less serious" to those who have their mind set on ignoring the movement from the get go.
To me open source just conveys the idea of "free shit". Saying "FLOSS" conveys the idea that this is actually a culture, with beliefs and ideologies. Much like everyone can identify as queer, but being an LGBTQ+ militant requires belief if not outright dedication to a certain family of ideologies.
Now if having beliefs or being a militant for a particular cause makes you "less serious", well, agree to disagree.
To me open source just conveys the idea of "free shit". Saying "FLOSS" conveys the idea that this is actually a culture, with beliefs and ideologies. Much like everyone can identify as queer, but being an LGBTQ+ militant requires belief if not outright dedication to a certain family of ideologies.
Now if having beliefs or being a militant for a particular cause makes you "less serious", well, agree to disagree.
Open-source does not convey the same idea as free software.
And LOSS wouldn't work out quite as well as FOSS or FLOSS :)
Some people care a lot about the difference between Free Software and Open Source. That seems especially important when studying people's motivations.
A lot of people you call "queer" consider that a term of abuse, especially from outsiders. "Serious" people seem to have settled on LGBT, LGBTQ, or "gender and sexual minorities" anyway.
A lot of people you call "queer" consider that a term of abuse, especially from outsiders. "Serious" people seem to have settled on LGBT, LGBTQ, or "gender and sexual minorities" anyway.
Except that FLOSS isn't missing anything. The acronym isn't going to get any longer.
To be fair, "open source" is a very broad term and everyone has a different sense for what it means. I don't believe the restrictions of AGPL make it an open source license in spirit ("source-available" is probably the better term), but FSF seems to think it is.