Live data from Hacker News

Why We Engage in FLOSS: Answers from Core Developers

arxiv.org

51–60 of 63 posts

Re: Why We Engage in FLOSS: Answers from Core Developers

#51
post #32

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.

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.

Re: Why We Engage in FLOSS: Answers from Core Developers

#52
post #25

Earlier quoted context omitted.

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 anyt…

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 experienc…

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

Re: Why We Engage in FLOSS: Answers from Core Developers

#53
post #48
post #2

If you're on a phone, here's an HTML version of the article: https://www.arxiv-vanity.com/papers/1803.05741/

This is great. 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

Re: Why We Engage in FLOSS: Answers from Core Developers

#54
post #32

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.

Open-source does not convey the same idea as free software.

And LOSS wouldn't work out quite as well as FOSS or FLOSS :)

Re: Why We Engage in FLOSS: Answers from Core Developers

#55

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…

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.

Re: Why We Engage in FLOSS: Answers from Core Developers

#56
post #32

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.

Except that FLOSS isn't missing anything. The acronym isn't going to get any longer.

Re: Why We Engage in FLOSS: Answers from Core Developers

#57
post #44
post #38

Earlier quoted context omitted.

> 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 o…

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.

Re: Why We Engage in FLOSS: Answers from Core Developers

#58
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.

Re: Why We Engage in FLOSS: Answers from Core Developers

#59

Earlier quoted context omitted.

> 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…

> 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…

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?

Re: Why We Engage in FLOSS: Answers from Core Developers

#60
post #40

Earlier quoted context omitted.

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.

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.

Post reply on HN