Why We Engage in FLOSS: Answers from Core Developers
arxiv.org
arxiv.org
Do you know what software is being used to automate the conversion from pdf to html?
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.
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.
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 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.
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.
Also, people always forget the rest of that phrase: A bad apple spoils the bunch. Pretty important nuance!
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)
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.
The best results are when you are genuinely interested in your work and in the process of making software better.
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.
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.
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.
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.
You probably switched to GPL to make your software less directly usable for companies?
"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."
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 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".
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.
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).
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.
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.
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.
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...
Especially when that person is politely reporting experiences with behavior that from my eyes, resembles yours exactly.
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.
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.
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.
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.
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
- 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.
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.
Edit: okay maybe the violin plot as it is shown has the correct density information. I disregarded that aspect of the plot.
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.
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.
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.