
Taking a month off from OSS volunteering - liuw
https://snarky.ca/why-i-took-october-off-from-oss-volunteering/
======
antirez
For me it was very stressful to learn how to cope with that, and fortunately
I'm paid at least to do the bulk of the work I do (that is, all the work on
Redis is paid). However once you learn the mental attitude to have towards
this issues, they disappear magically. It's you VS many people, and as the
user base increases, there is _no way_ you can handle issues and PRs. The
contributors need to adapt in order to make your work as simple as possible,
otherwise their issues/PRs will get ignored. I personally cherry-pick among
the ones that are easy to read, understand, general. There is always who will
say, don't you feel ashamed?!!11 Redis has tons of open PRs / Issues! When
people tell you this, always focus on what you did of good and not on what you
can't do well enough. In case of unpaied OSS work, the attitude should be to
do it only to _have fun_ and _learn_. There are no other justifications: IMHO
it's very wrong to donate time to OSS like if it was a charity, OSS is used by
companies doing tons of money and startups that sold for _billions_. Nobody
cared about redistributing back money to authors of the OSS that permitted
them to create (alonside with their great product) this result, so you as an
OSS maintainer should only care to have fun.

EDIT: I think it is very important to outline how in my experience 99% of the
user base is _wonderful_ , splendid human being, nice, willing to help. It's
just that the wrong 1% is very verbal and if you focus on that one is
terrible, but I believe it is hard to find an environment like the
"Underground IT/OSS" scene from the POV of people quality. It's just that's
impossible to get zero-assholes-environments.

EDIT 2: To other OSS maintainers, a trick is to be super gentle with harsh
people. You'll feel much, much better compared to using their own tones.

~~~
orderlyoctopus
Do you think there's room for contributors to OSS outside filing bugs and
making pull requests?

I'm a technical product/project manager by day and a hobby programmer by
night. Things like writing documentation, triaging issues, coordinating teams,
and planning releases is my bread and butter. I'd like the idea of spending
time on an OSS project(s) that I find interesting, but I wonder if this is the
kind of thing that would be welcome or even considered helpful. OSS projects
are passion projects, and it feels like trying to help out uninvited with
management tasks would come across as asserting ownership.

I do try to contribute what I can, but they're small hit and runs -- update
deprecated information in documentation or add some examples, add more
information to bug reports, etc., but I'd like to do more. Just without
offending anyone :)

~~~
jrochkind1
It would be very easy to contribute by writing documentation to most open
source projects, they'd be happy to take it.

Coordinating teams and planning releases.... I think a lot of open source
projects could _use_ help planning releases (release management is incredibly
important), but I'm not sure they'd _take_ it from a stranger they didn't
trust (and they might be right). "Coordinating teams" not as sure how it would
even look or would be needed. But anything that looks like being a "boss",
people are going to be resistant to, esp from a newcomer stranger, for obvious
reasons.

But I bet people will welcome documentation contributions with little
hesitation. For the rest... if you want to try, I recommend taking a product
you're familiar with (as a user, not a developer), and offering your services
being very careful to come from a real service perspective. Your job is to
figure out what they need help with and how they want it done, and help them
do it -- not to tell them what they ought to want to do or how they ought to
want it to be done, not at first even to helpfully _suggest_ it. At least not
until you've built up a lot of trust.

After writing documentation, I think the thing you mentioned people would be
most welcome to and least resistant to would be 'triaging issues' \-- but I
think you'll have to build up some trust (say, by writing documentation!)
before people will be willing to trust you with it.

~~~
voltagex_
>But I bet people will welcome documentation contributions with little
hesitation.

People should treat documentation issues the same way as critical bugs IMO.
Can anyone point me to projects where this is done? e.g. documentation
category on a bug tracker, open issues requesting additional documentation.

~~~
orderlyoctopus
I remember noticing Vuejs using the issue tracker for documentation in the
lead up to their release of 2.0.

FreeBSD also does this, which will surprise no one who has ever read the
FreeBSD docs.

Also, one of the reasons I asked this question in response to antirez is
because the Redis docs are excellent and have been since I first set eyes on
the project three or four years ago. I don't know what he's doing or how he
does it, but whatever it is, it's working.

~~~
antirez
Hello, I write the doc myself for the most part, since I believe the docs
should be only written by persons that wrote the code they are documenting, or
that fully understand it in the subtle parts. I happen to also love to write,
so it's quite fun for me to do documentation, while I understand there are a
seizable amount of programmers that don't like to write documentation a lot.

However to return to your original question of what is possible to do to help,
issues verification/triage is a HUGE thing because the issues are of hugely
mixed quality. Moreover Github does not help by making users not able to label
the issues in order to make them into categories: only the collaborators can
label issues.

Another problem I face is high quality QA, that is, a person that explores
certain parts of Redis to understand where there is a quality problem and how
it is possible to fix it.

Code reviews are also crucial. For a few months I had a contributor, Sun He,
that prevented a number of bugs in Redis by reading each commit and by
understanding non trivial bugs just reading the code. Impressive. Eventually
he got a job after the university and now contributes only from time to time,
but I'll be thankful forever ;-)

------
Klathmon
I have a question for any OSS maintainers:

How should I ask for help/bugfixes/solutions? How can I get across that an
issue is a "showstopper" for us without demanding anything? How can I offer
solutions or fixes or changes up without contributing to the "burnout" that
i've seen many many times from many people that I respect and enjoy the work
of.

Recently I was inadvertently one of those nameless-faceless demanders, and I
had no idea that I was coming across like that until it was pointed out to me.

I want to voice my opinions, my needs, my use cases without coming across as
demanding or winy. And making a PR out of left field generally causes more
issues than it solves since it was made without direction or input from the
maintainer.

~~~
hartator
Start with a small praise and how the project had currently helped you. Even
just a "Thank you for this awesome tool!" goes a long way.

Do a bit of story telling about why you want this or that. Try to make a good
case of it.

Post as most as possible, code, backtrace, steps to reproduce, what did you
tried, etc. In a structured way.

Assume you may be wrong. Use words like "Maybe", "We probably should", "I may
be misguided, but", etc.

Format it correctly, check for spelling and errors.

Finally, reply back when asked for stuff.

It's not that hard, but most people aren't doing it.

~~~
xemdetia
This is just a general front line support problem. A poor problem description
or incomplete problem description is irritating and gets to people. The other
one is the people that only show you step #4 of a procedure they are using and
keep trying to point to that as the root cause while it was really step #2. An
issue report should show from damn near install to the observed problem, or
thorough enough logs/config/stacktrace to give people on the receiving side
enough information on how you got here. I call this the A-B-C-D problem, where
they only keep telling you about something breaking in C but nothing about A,
B or D that feeds in.

The assume you may be wrong attitude to take in problem description is
definitely something I have seen well received as a reporter and a recipient.
Issues that are submitted with a tone of finality and then it turns into a
problem resolved by configuration/FAQ/documentation can be frustrating,
because in the triage you have to ignore such language and verify anyway.

The unassertive language also clues the reader of potential knowledge gaps in
the reporter. Inevitably just by construction of the report

Also this was something that was mentioned in postgres response after I
believe Uber transitioned from the technology to MySQL recently- if you are
doing something massive/slightly insane it helps build a strategy. A
communication issue from VPS host to VPS host for MySQL will require a
different diagnostic strategy than microcontroller to microcontroller MySQL
connection over an TCP/IP on I2C bus duct taped to the bottom of a Honda
Civic.

------
mitchellh
I'm the creator and maintainer of a number of popular open source tools and
projects. I even went on to start and build a company around many of them.
Prior to that though, I was purely just an OSS maintainer during my free time
for 3 or 4 years.

This blog post rings true 100%.

The unfortunate thing is that 99.9% of the community is filled with great,
helpful, happy people. But then the 1 in 1000 person comes along that is...
less than great... and that person puts a raincloud on your day as a
maintainer (or even worse: puts a raincloud on SOMEONE ELSE in the community).
And this person usually manifests themself exactly as this blog post states:
demanding, lacking detail in requests, not understanding, irrational, rude,
etc. They're hard folks to deal with.

I try to remember that THEY are also human. One thing I was taught when I
worked at Apple Retail (yes, retail) is that people are angry for a reason.
Very very very few people are angry purely to hurt you. Almost everyone who is
angry, on the flip side, is angry for a reason and emotions are effecting
them. I try to empathize and understand their pain, try to see what I can do
to help them. This is certainly a challenge, though. ( See my blog post:
[http://mitchellh.com/apple-the-key-to-my-success](http://mitchellh.com/apple-
the-key-to-my-success) )

Disclaimer for the above paragraph: I'm not saying the blog poster here
shouldn't take a month off. They absolutely should if they feel that would
help. The constant berating is very mentally straining.

Something that helps greatly: if you're a happy user, if you had a good
experience, just open an issue that says "Thanks". Some people close it, some
people leave it open. Either way I promise that that little gesture of good
will will really help the morale of maintainers. We don't even mind closing
your non-issue issue. :)

As a maintainer looking at an issue list, we see just that: a list of issues.
Its easy to fall into a trap of thinking everything is terrible and everyone
hates what you do. Seeing happy users on Twitter, at conferences, etc.
reinforces that its not all pain and despair.

So from a maintainer: thank you to the community for being so great! :)

~~~
nickpsecurity
The thing I have trouble reconciling is a few of you saying 90+% percent of
OSS community is great/friendly but the OSS survey in article showing most
projects get virtually no help even if downloaded a lot or with lots of
requests. It would seem most FOSS users were selfish freeloaders who talked
nicely on forums. Your project might attract different types of users, though.

~~~
kazinator
I write OSS, and also use a lot of it without helping it.

That's the idea.

OSS can work just fine if we put together N developers, each working alone on
exactly one of N projects, while using the other N-1 without helping them. The
developer _is_ helping the N-1 by working on his/her project which they all
use.

~~~
nickpsecurity
I like that. I just dont think most FOSS users are doing that. We could start
with number of Apache or Linux users vs number who are FOSS contributors. My
model says the disparity would be multiples or exponentially different.

~~~
kazinator
The throng of non-programming users is valuable; they provide free testing.
Also, they create a feeling of importance.

~~~
nickpsecurity
Testing is objectively valuable so long as they send good bug reports. I
havent seen a metric on amount of gripes vs actionable reports. That would be
interesting data point.

------
heckless
Thanks for writing this. It takes a hard head to be an open-source project
maintainer and taking a step back and evaluating how to contribute to open
source software while keeping it enjoyable is a good thing to do.

I see so much abuse on Github (stuff like "your README is utter garbage" and
other frustration, all over, all the time) and it's really disappointing. I
don't ever expect the issue-reporting community to change so instead
maintainers have to learn how to deal with it, which is unfortunate and leads
to the type of burnout detailed here and in numerous other posts I've seen on
HN.

Don't give in and quit! Ignore the trolls.

------
hrayr
Brett, thanks for your contributions to Python. This is coming from a person
in the majority of silent users who simply enjoy the fruits of your and other
contributor's labor, without complaining and admittedly without giving enough
praise. Big props, and hang in there.

~~~
jamesdutc
Brett, thanks for contributions to Python.

(... and thanks to the other contributors,
[https://github.com/python/cpython/blob/master/Misc/ACKS](https://github.com/python/cpython/blob/master/Misc/ACKS),
and to all people who volunteer their by contributing to open source...)

I am another silent user, someone who lurks on every Python thread on
HackerNews but finds the discussion often too contentious to bear.

I know you personally, and I'm sure I've said this to you in person, but maybe
you'll accept my sincerity if I say it in public:

You bring a certain sensitivity, a level-headedness and moderating influence
to the Python community. Discussion within technical communities is rough,
even when everyone is aligned toward the same goal. Any lurker on #python-dev
can see how quickly discussion can break down.

These communities need people like you, even though they sometimes seemed
designed to grind down people like you.

Double big props, and hang in there!

------
moxious
There's been a lot of discussion over years about open source communities, and
how curating the community is an important part about that.

If people aren't paid in cash, they need to be paid in other things, like
egoboo, kind words, gratitude, whatever.

When people get mistreated while volunteering their time for open source,
looking at that from an economics perspective it's every bit as bad as when a
company decides it'd rather not pay its employees. It's good if programming is
fun, but "fun" doesn't pay the bills, and doesn't advance your career.
Reputation and contribution could though.

But it's hard to fix, because the paymasters (the community) don't always
care. I think in the long run, the true driver of open source is people
scratching their own itch. Most I believe don't do it for altruistic reasons
or even for fun, but because they use this piece of software themselves to do
something productive, and need it to be better.

------
hartator
For maintaining a small OSS tool, it's true that most of the people are rude.

Posting a "don't work with Windows" without any thing more. When asked for a
backtrace or an explanation, copy/paste without formatting or anything else.
Demanding for a feature without making a case for it. Not using any polite or
nice phrasing in a thread.

I don't know the best to react to this. Maybe we should just close their
issues without any explanation with just a link to a guideline or something.
But, when you care about your project, you tolerate the abuse because you
truly want to make your project better despite it.

It's like the rude kid of the article suggesting a new rule, but you actually
find it's not that a bad of idea and deserve some thoughts into it.

It's hard to draw a line.

~~~
heckless
> Demanding for a feature without making a case for it. Not using any polite
> or nice phrasing in a thread.

In virtually every case where I have seen impolite issues filed or even
abusive issues filed, the biggest success has always been when the project
maintainers simply ignore the abuse and respond respectfully, as if the
request had been worded more politely. The abusive issue opener will often
apologize for their tone or simply adopt a different, much more friendly tone.

This is an effective strategy. In the same way that people filing issues need
to remember that maintainers are people and should be treated as people,
maintainers can also remember that people filing issues are people.

There's no need to act adversarially in open source software development.

~~~
richardwhiuk
I'm not sure I agree that is a successful way. In most cases, the person
either remains abusive, or doesn't post anything else.

I think the best thing to do is to just delete all abuse.

------
pipio21
One of the big troubles with OSS volunteering is the current state of
technology to communicate with others on the Internet.

In our company we have been working from home for years. Using the telephone
or teleconference is basic in order to really understand each other.

Only text communication is terrible because basically you filter all the
emotions from the message. The worst thing is that you interpret or
reconstruct those emotions based on your own state of mind. If you are burned
out it is not pretty.

I can't tell you how bad it is when someone takes something trivial on text
and interprets it as an aggression and responds aggressively and escalates and
yet it happens every single day when you put an only text communication center
in place.

The same thing told in another context, in a person to person meeting will be
nothing because we are automatically using our tone of voice and body language
in order to complete the message.

This has to improve some way.

~~~
nine_k
If you know that implied emotions are filtered out, or can be mis-interpreted,
why not add _explicit_ emotions?

Add praise and express gratitude for the project you're talking about.
Expressly state when you have a strong option (preferably backed with data or
something), and where you're humbly suggesting and asking for comments. Stay
away from sounding like you're demanding something, and maybe even stay away
from irony until you've created a good rapport with a person you're
communicating with.

Do not remove all this "useless fluff", and work on adding some more in key
parts of your message, it can improve communication.

------
johnnycarcin
I honestly don't understand why this happens. Do people really not understand
that the OSS products they are using are typically created by people on their
free time and that they don't owe you anything? If you want support pay for
it, either through the OSS product itself or via a 3rd party consultant.

If you are not a developer or just don't have the time, I highly encourage you
to support these projects in other ways:
[https://esheavyindustries.com/2016/02/have-some-extra-
cash-h...](https://esheavyindustries.com/2016/02/have-some-extra-cash-help-
make-your-life-easier/)

For most of the OSS products I use I typically am not knowledgeable enough to
submit code and I really don't have a lot of free time so I send them money or
buy things off of their wishlist. A lot of these products make it capable for
me to do my job and without them I'd likely be in a totally different spot.
Sending them a few bucks a month or buying a book for them seems like the
least I could do.

Just be nice and thankful for the work that these people/groups are putting
out their and help where you can.

------
unvs
I usually check in on open source projects I use and see what is going on in
the issues and pull requests tabs on github. Almost every time I check, there
is someone behaving in a rude and/or entitled way.

Some of these projects have implemented github's issue template, and the crazy
thing is, these people actually just DELETE the entire template before writing
their issue. They can't even be bothered to fill in the few fields the
maintainers ask for.

I had hoped that Github would have translated the issue templates to actual
forms, where you at least HAD to fill in the fields before getting to submit.

------
brettcannon
As the author of the post being linked to, I just wanted to say thanks for all
the kind words being said in this thread that are directed at me. For those
that are curious, I'm still contributing to open source (I'm actually doing
some on my vacation, but it's stuff I want to work on so it's all good). :)

I know the tone is rather dark here in the comments due to the fact that
project maintainers are coming forward and saying how they end up suffering in
a similar way as I have. But acknowledgment is the first step in dealing with
a problem. My hope is we as an overall community of open source can come to
terms with the problem at hand and start to develop solutions. (and if anyone
cares, my current thinking on potential solutions all rely around improving
our communication tools, but that's probably for another blog post :) ).

------
jjn2009
We have likely hit the peak of this open source trend. Many companies rely on
this model for ensuring their product is the most widely adopted however the
individual contributor side of the story always seems to be ridden with
experiences like the one stated in this article.

This sort of correction is necessary, the reason a contributors time is not
valued is because of vast abundance of open source contributions out there
today which people share for free.

------
briankwest
I'm one of the founding members of the FreeSWITCH Project, I've literally had
people call my cellphone and demand I help them for free, because the software
is free, it has free in its name and some how that translates into I must help
them. This article is spot on, When you find the good contributors you help
them, give them empowerment and you'll get rewards as a project, but every now
and then you have that one person come along an just ruin your day over
something that makes no sense at all. Bug reports that are incomplete, when
you close them as incomplete they get reopened with NO additional details.
Pasting logs into word docs and attaching them to the bug, uploading core
files as if thats helpful.

I try my best to stay positive, I now think of those people as potential
customers to help me make living. It does change your view of things. :)

------
satori99
> [...] people have made demands on my free time simply because I previously
> gave them that same gift to help make Python, as if the gift of my free time
> is in perpetuity

A long time ago, I worked for a radio station as an audio engineer. Every
piece of work I was assigned had a hard deadline for delivery or broadcast, so
I often did the easy jobs first and delivered them early to get it out of the
way.

My boss noticed this, and called me into his office one day to explain to me
that if I kept doing this, people would _expect_ that work early every time,
or give me less time to do it, and eventually it would bite me.

I tend to give some thought to managing expectations is most situations now.
Paid or otherwise.

------
msoad
Check out "Issues from hell"[1] Twitter account, they collected a ton of
terrible behavior in open source forums:

[1] [https://twitter.com/issuesfromhell](https://twitter.com/issuesfromhell)

------
pauldix
This resonates with me. I've definitely been discouraged over years of OSS
work by people that are rude or expect free labor. However, I try to remind
myself that these are the vocal minority.

There are many people that are positive and help by contributing feedback,
testing, answering other community members questions, and even submitting code
to the various projects.

OSS can be exhausting at times, but over my career I haven't found anything
that is quite as rewarding. It feels great to have another developer use code
I've written to help get their job done. And that's why I keep coming back to
OSS.

------
nercht12
To some extent, geek culture is self-deprecating. We give away our work and
then, when we receive it, we don't know how to say thank you.

I feel awkward saying thank you on projects. Whenever I go to comment, it's
like I feel the need to offer something in return, even if I don't have the
time or money.

I do sincerely appreciate the many FOSS project contributors out there,
however little I may say so, and I hope that at least a number of devs
consider silence and a high download count to be a sign that everyone is happy
and that they, the devs, are doing a great job.

------
Sukotto
I'm late to the party on this discussion, but did want to say this brings to
mind the similar troubles popular authors can have with their readers.

... and which prompted this wonderful essay/rant from Neil Gaiman "Entitlement
issues" (aka "George R.R. Martin is not your bitch")

[http://journal.neilgaiman.com/2009/05/entitlement-
issues.htm...](http://journal.neilgaiman.com/2009/05/entitlement-issues.html)

------
AlisdairO
Just wanted to offer a counterpoint to the general negativity in this comment
thread: for my small OSS project I've always received respectful
comments/issues on github. Some more or less helpful, but I've never felt used
or abused.

Not intending to cast doubt on any of the experiences here, just to highlight
that there's good experiences to be had too :-). I suspect one difference is
that my project is dedicated towards education. As far as I know no-one is
relying on it for their income.

------
Bahamut
I have learned to detach myself some from open source, as some users are
always going to be terrible, and IMO, more people should make an honest effort
to contribute back to open source. If one gets too invested, it becomes too
easy for negative contributors to affect your mental state, which affects the
quality of solutions implemented.

For example, I encountered a bug this morning in one of the latest releases
that came from the Angular team yesterday. Before opening an issue in GitHub,
I did some deeper investigation in the code to figure out more details as to
what was happening, as it was something that I could not give a nice minimal
reproduction for them to fix as it dealt with something complicated. I posted
the information, and along with help with two other contributors, we narrowed
down the issue to one module. It was frustrating to encounter such breakage
with minor version upgrades on packages, but as an open source maintainer of
some major projects myself, I know it is more counterproductive to lash out at
maintainers who are doing the best they can with the information & resources
they have.

------
mwpmaybe
I've been on both sides and I have to say that the road goes both ways.

When I was getting started with a language last year I found a missing feature
in a module of an open source library and submitted a very simple PR to add
the feature. The maintainer asked me to completely refactor the module. I
admittedly overreacted to this request—as I perceived it to be way too big of
an ask—before settling down and getting to work on it. Then it literally took
almost six months for the maintainer to review and merge my PR because of the
intensity of the refactoring and performance regressions. (I would get some
small piece of feedback, submit a fix or more information, wait weeks and
weeks to hear back again, repeat ad naseum.)

So yes, issue-reporters and PR-submitters can be irritating, demanding, and
disrespectful of maintainers' time, but maintainers can be just as bad.

Postscript: I don't regret the time I spent on it because it was an awesome
learning experience, but it was certainly frustrating at the time!

~~~
dochtman
As a maintainer, I understand that this must have been frustrating for you.

On the other hand: the maintainer will have to maintain the changes you've
contributed ~forever. Effectively, the contribution you're making, something
that you can just throw at the maintainers, will have impact on their
maintenance of the project for a long, long time.

As such, I disagree that maintainers are "bad" for doing this; there's just a
large disbalance between the time your one-off contribution takes and the time
they might have to spend refining it and/or fixing bugs in it. Given that they
might also be juggling a day job and working with a bunch of other
contributors, getting there can take a lot of time.

(Of course, they should still strive to be respectful about it, and as
transparent as possible -- unfortunately, it's often hard to say in advance
how much time it might take.)

------
buovjaga
The "relationships" section of the post did not mention quality assurance team
members. I find that a strong QA team patrolling the bug tracker protects
developers from a lot of noise. My own experience is with desktop software and
I can imagine it might be harder to assemble a large team for a programming
language, but I urge everyone to give it a shot.

I wrote a little something about the subject recently:
[https://inkscape.org/en/news/2016/12/13/bug-testing-
roadshow...](https://inkscape.org/en/news/2016/12/13/bug-testing-roadshow-
hits-inkscape/)

------
elastic_church
I can relate to most of this, and I try to be conscious of this when I come
across a dependency of a dependency that I find out is under maintained and
should be fixed. In many package managers it is difficult to modify sub
dependencies without changing the whole structure of the project.

For some other things, like in the Android Open Source Project, these things
are very intolerable. Google employees mostly have a monopoly on development,
and ridiculous stuff still slips through the cracks and nobody can practically
modify it.

------
nodivbyzero
[https://snarky.ca/how-i-stay-happy-making-open-source-
softwa...](https://snarky.ca/how-i-stay-happy-making-open-source-software/)

------
jquast
I think we could all share plenty of stories of abuse and having our volunteer
time abused or undervalued...

It's very overwhelming to have a large public project that your day job
doesn't care about. When I find those rare moments of free time, and feeling
like writing code, I feel guilty for not contributing it to my employer, and
guilty for letting issues pile up in github, and guilty if I'd rather write
new code.

I feel paralyzed and do nothing, I've mostly ignored FOSS this year, and they
just pile up...

------
pikzen
Sometimes, I wonder if there's a market for a service to tell people off when
they're being rude, inconsiderate or plain dicks. Sod Off as a Service. I just
keep reading and reading examples of OSS maintainers receiving mails just like
the first example given. Always bring me halfway between a laughing and being
angry.

------
j_s
_In order to help others more effectively share the maintenance burden, I need
to stop fixing bugs and focus on helping them with patch submissions._

This is a good takeaway; I hope more maintainers are willing to prioritize
patches.

------
briandear
Sounds like a terrible country. You can't get paid without a registered
business and your employer can tell you what you can't do on your own time?

Why do people vote for those sorts of policies?

~~~
dang
> _Sounds like a terrible country_

That's gratuitous. Please drop the flamebait when commenting here.

We detached this subthread from
[https://news.ycombinator.com/item?id=13233445](https://news.ycombinator.com/item?id=13233445)
and marked it off-topic.

Edit: you've been using HN primarily for political and ideological battle.
That is an abuse of this site. We ban accounts that do it, so please stop.

------
65827
I could always smell this awful elitism and generally treating people like
garbage from even the very early days of Stack Overflow and Github.
Unfortunately any attempts to push back or criticize it will assure you are
never allowed to participate in these self reinforcing "karma" based
communities, so it's taken waaayyy longer for people to come around on this
than it should have.

------
vinceguidry
> When the bug didn't get fixed, they personally emailed me asking me to fix
> it as a consultant within three days. When I said I didn't have the time,
> they then asked me to do it anyway for free because they still had their own
> three-day deadline and shouldn't I just want to help them out?

I feel like we need a professional ethics code to handle situations like this.
To me, if someone is willing to throw money at me to solve a problem, it
behooves me to want to help them out. The only consideration here _should_ be,
"how much." I would have looked at my current obligations, and quoted them a
price at which I would have been willing to drop everything to come up with a
patch for.

His unwillingness to help them out is, in the eyes of the business world,
unprofessional. I get it, we're coders and we do this for fun. But how are we
ever going to get the rest of the world to afford us the same respect that
doctors and lawyers get if we're unwilling to play ball?

If I'm running a business and I need something, I should be able to pay a
reasonable amount of money to get it. What's reasonable as determined by a
negotiation between me and the party providing it. If I went to him and he was
like, I need $10K to do this by Friday, that gives me a baseline. If I balk at
the price, but I can get by if I push it to next Tuesday, can I get it for
$6K?

If he tells me he can't do it at any price, then that means I _can 't rely on
OSS as a pillar of my business_.

These are the problems I wish Stallman would apply his huge brain to solving.
Not saving us from Facebook.

~~~
fabian2k
Not having time is not unprofessional. There are many different reasons why
even throwing money at it might not be enough to get someone to work for you
on short notice.

If your business depends on that piece of software to the degree that you
might need a very quick fix on short notice at an almost arbitrary price, then
you need to pay for a support contract with some company that offers it for
that particular OSS software. That is possible for many big OSS projects, just
like with closed source software.

~~~
vinceguidry
> Not having time is not unprofessional.

Not being able to help someone out _at all_ is.

> That is possible for many big OSS projects, just like with closed source
> software.

It should be possible for all of them. It's not, which is why OSS cannot be
relied upon for business.

~~~
fabian2k
They could have previous commitments to their employer, breaking those without
notice would be seriously unprofessional. They could have private obligations,
which can't be weighed against money. They could be ill, ...

There is really no difference here between OSS and commercial closed source
software. If you require that kind of guarantee, you need to pay someone in
advance for them to make sure they'll have the capacity to help you on short
notice.

~~~
vinceguidry
> There is really no difference here between OSS and commercial closed source
> software.

The difference is you can pay commercial software vendors for support. With
OSS, you often can't.

~~~
rekado
No, you can hire programmers to hack on the software. You don't call the
authors, wave money at them, and tell them to fix a problem for you.

The programmers you hire don't _have_ to be the authors (that wouldn't scale
in most cases anyway), but they may very well become regular contributors.

~~~
vinceguidry
Sure you can hire someone. But it's cheaper to buy commercial software.

~~~
rekado
Free Software does not mean "non-commercial" software. With Free Software you
are not restricted to just one model of getting problems fixed.

It also doesn't seem correct to say that "it's cheaper" to buy software, when
the issue here is fixing problems. Buying a software artifact is unrelated to
getting service. Besides, it may very well be cheaper to hire a person to hack
on a number of software projects than to pay for a service contract for each
of the projects.

~~~
vinceguidry
> Free Software does not mean "non-commercial" software.

If free software cannot work for business then that's exactly what it means.

