Taking a month off from OSS volunteering(snarky.ca)
snarky.ca
Taking a month off from OSS volunteering
https://snarky.ca/why-i-took-october-off-from-oss-volunteering/
186 comments
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 :)
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 :)
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.
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.
This is how I've thought of it as well, why I've been hesitant to do much more so far, and why I'm polling a forum with lots of different maintainers rather than a single person at a single project already.
Because of my skills, I'm not going to stumble onto something by chance where I'm contributing upstream to scratch my own itch and then sticking around. I'm expecting I would need to spend time to find a project that seems like a good fit both ways, and become an active user intentionally where without my side agenda I'd be better off using a larger OSS project or a paid service.
I'm cool with putting that time in to help something grow and to help kindred spirits out. I don't want to put in that time just to be a source of annoyance or frustration to someone who's already done me and the world a solid by putting something cool out into the world.
Documentation is where it seemed to me like the best first step, and what people are saying here as well. As a followup, what's the general consensus on the least bothersome approach? Editing/prettifying existing documentation; appending to existing documentation (adding diagrams or examples); or creating "newbie docs" (how do I install this, how do I compile this on Windows, or aggregating a central FAQ from closed issues); or perhaps something else?
Because of my skills, I'm not going to stumble onto something by chance where I'm contributing upstream to scratch my own itch and then sticking around. I'm expecting I would need to spend time to find a project that seems like a good fit both ways, and become an active user intentionally where without my side agenda I'd be better off using a larger OSS project or a paid service.
I'm cool with putting that time in to help something grow and to help kindred spirits out. I don't want to put in that time just to be a source of annoyance or frustration to someone who's already done me and the world a solid by putting something cool out into the world.
Documentation is where it seemed to me like the best first step, and what people are saying here as well. As a followup, what's the general consensus on the least bothersome approach? Editing/prettifying existing documentation; appending to existing documentation (adding diagrams or examples); or creating "newbie docs" (how do I install this, how do I compile this on Windows, or aggregating a central FAQ from closed issues); or perhaps something else?
> Editing/prettifying existing documentation; appending to existing documentation (adding diagrams or examples); or creating "newbie docs"
I think any of those could be good, whatever the project needs. If it's got existing docs that need editing/prettifying, that's def a natural first step.
I think any of those could be good, whatever the project needs. If it's got existing docs that need editing/prettifying, that's def a natural first step.
>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.
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.
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.
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.
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 ;-)
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 ;-)
well not treating them as critical, but there are many projects that do so.
One scala Project for example: https://github.com/playframework/playframework/labels/docume...
Unfortunatly once they are there not many PRs will address, these, only if their are actually critical. (Well the problem with play is actually that you need to read the README.md of the documentation carefully to make documentation and to understand a little bit of sbt and scala.)
Also it's actually not easy to write understandable documentation for many users. Some people are just too different, so that some actually need a way more detailed view, while for others this would be disturbing and useless noise, the golden middle is hard, especially if you contribute documentation to a framework which includes different libraries, it's really hard to keep the documentation simple.
P.S.: gitlab also treats documentation very seriously. (just to have at least two examples)
Unfortunatly once they are there not many PRs will address, these, only if their are actually critical. (Well the problem with play is actually that you need to read the README.md of the documentation carefully to make documentation and to understand a little bit of sbt and scala.)
Also it's actually not easy to write understandable documentation for many users. Some people are just too different, so that some actually need a way more detailed view, while for others this would be disturbing and useless noise, the golden middle is hard, especially if you contribute documentation to a framework which includes different libraries, it's really hard to keep the documentation simple.
P.S.: gitlab also treats documentation very seriously. (just to have at least two examples)
While I think I know some people who'd take it as trampling on their toes for the reasons you mentioned, I for one would absolutely overjoyed if someone was willing to help with such things—though obviously I have my opinions about them too!
Triaging issues especially can be a big time-sink, and is something that is relatively easy.
How do you tell who you'd be trampling on it and who else would be shouting "YES!" excitedly? I'd just drop an email!
Triaging issues especially can be a big time-sink, and is something that is relatively easy.
How do you tell who you'd be trampling on it and who else would be shouting "YES!" excitedly? I'd just drop an email!
Yes! Yes! Yes!
I see so many opportunities for contribution where a project manager could make such a big difference. This starts with simple things like “I had an hour to spare and the contributor documentation was non-existant, so I did something else” and goes to “this issue would be good to fix, but I don’t have the energy to get little fixes upstreamed into five different projects”.
I’m sure many projects would be lucky to have your help.
I see so many opportunities for contribution where a project manager could make such a big difference. This starts with simple things like “I had an hour to spare and the contributor documentation was non-existant, so I did something else” and goes to “this issue would be good to fix, but I don’t have the energy to get little fixes upstreamed into five different projects”.
I’m sure many projects would be lucky to have your help.
Ive been thinking about contributing with my marketing/business skills. Though Im not sure how receptive people might be. Marketing is such a taboo issue in tech that it might backfire and create a shit storm of incredible proportions around me.
What do fellow HN'ers think?
What do fellow HN'ers think?
I think FLOSS projects do such a bad job at marketing and publicity that you would be doing them an immense favour volunteering your skills in that way. OTOH, increasing popularity increases workload so you would have to be careful about scaling the user community at the correct rate.
I think it totally depends on the lead/project. I've been invited to do so on a project, and I felt I didn't have the time (or deep enough knowledge) to do so.
I would say all help is welcome in successful projects -- it has to be, for longevity
I would say all help is welcome in successful projects -- it has to be, for longevity
If LibreOffice is interesting to you in any way, it has a solid organization making it easy to start contributing.
For triaging: https://wiki.documentfoundation.org/QA
For documentation: https://wiki.documentfoundation.org/Documentation
For marketing: https://wiki.documentfoundation.org/Marketing
The technical docs in the wiki could also benefit from stylistic improvements.
For triaging: https://wiki.documentfoundation.org/QA
For documentation: https://wiki.documentfoundation.org/Documentation
For marketing: https://wiki.documentfoundation.org/Marketing
The technical docs in the wiki could also benefit from stylistic improvements.
Absolutely, here is a bunch of examples from the Debian project:
https://www.debian.org/intro/help
https://www.debian.org/intro/help
Salvatore, for what's worth, every time someone complains about how one shouldn't use project X because it has too many open issues, I just point them to Redis as a counter example: Works wonders; majority of issues peripheral ;)
Open issues aren't a problem. Anything with a sizable user base will have a continuous stream of issues. That's the mark of being popular! People only complain and open issues about things they actually use.
A "bad sign" would be increasing or stagnant issues with no resolution. Say if a project has a single maintainer and said maintainer decides to stop all work on it. There's plenty of examples of projects like that and if you're choosing a library or backend, you need to know what you're getting into.
(For the record, Redis doesn't fall into that category at all!)
A "bad sign" would be increasing or stagnant issues with no resolution. Say if a project has a single maintainer and said maintainer decides to stop all work on it. There's plenty of examples of projects like that and if you're choosing a library or backend, you need to know what you're getting into.
(For the record, Redis doesn't fall into that category at all!)
If issues are being opened faster than they are closed, the number of open issues is going to grow without bound. That's just basic queuing theory.
It's also the case that the average age of open issues will grow without bound. (As the number of open issues grows, eventually you get to a point where more issues are untouched in any given period than are either opened or closed.)
So, it's very easy to get into the state where there are lots of stagnant issues. It's going to happen automatically unless you do something to fix it. Something needs to happen so that either fewer issues are opened or more issues are closed.
It's also the case that the average age of open issues will grow without bound. (As the number of open issues grows, eventually you get to a point where more issues are untouched in any given period than are either opened or closed.)
So, it's very easy to get into the state where there are lots of stagnant issues. It's going to happen automatically unless you do something to fix it. Something needs to happen so that either fewer issues are opened or more issues are closed.
Thanks :)
Well, scratching you own itch seems like a pretty good reason to contribute to OSS even if unpaid, uneducational, and unfun.
What I found (I wrote a pretty large open source project and receive hundreds of emails every day about it) is that most people are only willing to contribute to open source to the extent that it scratches their itch. They feel that their obligation ends as soon as the code is written, and the maintenance of their code falls on you.
So from a maintainer perspective, you have to act like people's contributions are your contributions. You have to evaluate the code as if you have to maintain it later, you have to understand the circumstances surrounding it, etc. You have to be aware of everyone's concerns at the same time and make sure you don't end up messing up other people's use cases without good reason. And more often than not PRs reflect a "selfishness" of sorts wherein it solves their problem but breaks the general case.
In four separate occasions, people tried to take control of my github organization and npm repos by complaining to github and npm support, because they disagreed with the trajectory of the project. Some people seem to have no respect for OSS.
So from a maintainer perspective, you have to act like people's contributions are your contributions. You have to evaluate the code as if you have to maintain it later, you have to understand the circumstances surrounding it, etc. You have to be aware of everyone's concerns at the same time and make sure you don't end up messing up other people's use cases without good reason. And more often than not PRs reflect a "selfishness" of sorts wherein it solves their problem but breaks the general case.
In four separate occasions, people tried to take control of my github organization and npm repos by complaining to github and npm support, because they disagreed with the trajectory of the project. Some people seem to have no respect for OSS.
Exactly that. For this reason in order to merge something I don't just need to like it. I also need to understand the code base line by line otherwise when there are changes to be made is a nightmare.
> In four separate occasions, people tried to take control of my github organization and npm repos by complaining to github and npm suppo
THat blows my mind a bit. Particularly since forking a repository is not exactly a difficult thing.
THat blows my mind a bit. Particularly since forking a repository is not exactly a difficult thing.
This just sounds like an attempt to take control of a popular project. An attack.
[edit] an interesting vector: open source politics
[edit] an interesting vector: open source politics
running a company results in many of the same kinds of situations.
lots of people are crazy. they walk among us!
lots of people are crazy. they walk among us!
Scratching your own itch tends to be fun, though.
The author mentioned receiving an email personally requesting a bugfix due to the requestors' deadline. Now, I don't have any projects as big as Redis I'm building, or even Python - my OSS contributions are here and there small things mostly just for fun and learning and I've been into it for a long time, and I can say I feel it's perfectly reasonable to tell such a person, "Sure. If you send me X BTC at the following address, I will prioritize this for you." In fact I think this should be a common response.
[edit] the significance of my being into OSS for such a long time is I can say I don't think the environment used to be so hostile for maintainers as it is now
[edit] the significance of my being into OSS for such a long time is I can say I don't think the environment used to be so hostile for maintainers as it is now
It happens to me, and there are two consequences: 1) your email becomes kinda of a Twitter timeline, you from time to time cherry-pick emails to reply to, because they are too many that require a personal direct reply, and it is impossible to cope. 2) You have to make a decision, if you want to prioritize for money, you are likely not going to do the best for the user base: it is perfectly reasonable but not my pick since I'm already sponsored to do my work. However it is very likely that you get a money offer to put into the project something you don't like, and this is going to be actively bloating the project. Not an easy one.
Now that does sound like a difficult situation to handle. I'd like to think I'd always choose the high road and say, "code quality first!" But personally I probably would not always do that when there's a strong financial incentive on the line (if I'm going to be honest with myself).
> Sure. If you send me X BTC at the following address, I will prioritize this for you
That sounds like a good recipe for getting into trouble because of tax fraud if it gets public. And even you are in the position to accept the money (e.g. by being self employed) it would not be worth the effort. If you charge a low sum the overhead will make it not pracitable and if it's a large sum no individual will want to pay you and companies will often not be able to pay you.
That sounds like a good recipe for getting into trouble because of tax fraud if it gets public. And even you are in the position to accept the money (e.g. by being self employed) it would not be worth the effort. If you charge a low sum the overhead will make it not pracitable and if it's a large sum no individual will want to pay you and companies will often not be able to pay you.
It's only fraudulant if you don't report it. And you should charge the highest possible sum you can, IMO, or whatever sum you choose if you're being charitable. In such a hypothetical case - it's your project and so the upper limit is the value you place on your own time and energy. Also, since it's OSS anyway, there is no price set to compete against.
Part of the point of setting a high bar would be to either:
1) receive adequate compensation or 2) get the company that can't afford to pay you to contribute in some other manner
Part of the point of setting a high bar would be to either:
1) receive adequate compensation or 2) get the company that can't afford to pay you to contribute in some other manner
Yes, but reporting it may not be simple (depends on your country). Here you would need to have a registered business to be able to charge for it and to report it. And having a registered business besides your primary job requires agreement from your employer.
In the US anyone can be a sole proprietor at any time, at no cost.
Also, if you are already otherwise employed, any such work is basically overtime expert consulting work. It has to pay well, otherwise it does not make any sense for you to shoulder any extra responsibility and hassle of getting things done in the agreed time frame.
I genuinely ask: don't you think that for the people which needs a specific solution and/or are too pushy, you should move to the professional services route and charge accordingly? I am not talking about the random guy but the company which is making money and know that work should be paid.
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.
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.
IMHO:
1) Just ask whatever you want, no limits, but without expecting it to be done. There is just the possibility that it will be done.
2) Provide as many details as possible so that the maintainer does not have to context-switch to understand what's going on.
Point "2" is very important. Example: pull request subject is "fix hash table crash". Only change is a one liner like:
So now good luck with stopping with what you were doing and understanding what happens if ht->used is not 0 in that case, and the corner case that triggered it.
Instead in the original PR description, the contributor shold have written: when the hash table is reset, if there is a running iterator, next will be NULL because bla bla bla. Testing for empty hash table instead bla bla bla.
Now your effort is 30 seconds... Understad, merge, say thank you.
1) Just ask whatever you want, no limits, but without expecting it to be done. There is just the possibility that it will be done.
2) Provide as many details as possible so that the maintainer does not have to context-switch to understand what's going on.
Point "2" is very important. Example: pull request subject is "fix hash table crash". Only change is a one liner like:
- if (next) {
+ if (next && ht->used != 0) {
So now good luck with stopping with what you were doing and understanding what happens if ht->used is not 0 in that case, and the corner case that triggered it.
Instead in the original PR description, the contributor shold have written: when the hash table is reset, if there is a running iterator, next will be NULL because bla bla bla. Testing for empty hash table instead bla bla bla.
Now your effort is 30 seconds... Understad, merge, say thank you.
Also if possible include a unit test in the PR, maybe even in a separate commit.
For example, let's say I'm a project maintainer and I get a PR with two commits. The first commit just adds a test case, and Travis has marked the build for that commit as failed. The second commit includes a fix for that case and Travis shows that the tests pass when run on that commit. That's the sort of PR I can confidently merge without even having to leave GitHub's web UI.
For example, let's say I'm a project maintainer and I get a PR with two commits. The first commit just adds a test case, and Travis has marked the build for that commit as failed. The second commit includes a fix for that case and Travis shows that the tests pass when run on that commit. That's the sort of PR I can confidently merge without even having to leave GitHub's web UI.
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.
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.
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.
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.
Hopefully this Issue/PR [1] I opened today to clarify documentation would make good live example of this :-)
[1] https://github.com/BurntSushi/ripgrep/issues/284
[1] https://github.com/BurntSushi/ripgrep/issues/284
> 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.
This might be good advice in general, I'm not sure, but I mostly see this as just noise and it won't make me more likely to respond quickly or take any action. In terms of politeness, I think the more relevant quality is how entitled you come off as. If you come in saying, "This needs to change because of <downstream product requirement>", it makes me think you probably are thinking of the change in terms of how it helps you. If you come in saying, "This is the problem I'm having, this is the workaround I came up with, but this doesn't seem like the right behaviour because <x>", I'm more likely to figure that you actually took a holistic view and are thinking about how this change would affect all downstream users.
This might be good advice in general, I'm not sure, but I mostly see this as just noise and it won't make me more likely to respond quickly or take any action. In terms of politeness, I think the more relevant quality is how entitled you come off as. If you come in saying, "This needs to change because of <downstream product requirement>", it makes me think you probably are thinking of the change in terms of how it helps you. If you come in saying, "This is the problem I'm having, this is the workaround I came up with, but this doesn't seem like the right behaviour because <x>", I'm more likely to figure that you actually took a holistic view and are thinking about how this change would affect all downstream users.
Other than the bug reproduction instructions it seems like you could train a piece of code to convert requests to a format like this using machine learning. It could save someone from a lot of stress!
(I agree with your point but even solving it this way would provide benefits).
I'm not a maintainer.
That said, I've never had a problem with non demanding, humble, zero pressure questions.
Why do you need to mention that something is a showstopper? This may sound harsh, but: at the end of the day, you have to be responsible for what you produce. That means if there is a showstopper in their project blocking you from getting something done, you, and not them, are responsible for dealing with it. They volunteer to maintain the project for everyone, not fix your problems on your timeline.
That said, I've never had a problem with non demanding, humble, zero pressure questions.
Why do you need to mention that something is a showstopper? This may sound harsh, but: at the end of the day, you have to be responsible for what you produce. That means if there is a showstopper in their project blocking you from getting something done, you, and not them, are responsible for dealing with it. They volunteer to maintain the project for everyone, not fix your problems on your timeline.
The "example" I had in my head when writing that one where I found a pretty nasty bug in a relatively small library I was using.
I opened an issue, but struggled on how to get across the feeling of "If this isn't fixed i'll need to do it myself", but without the demanding feel.
I'm completely okay with a "can't get to it now" and i'll take over and fix the problem in the library myself for myself (making a PR if it makes sense to), or completely replace it with my own code or another library. And I would never fault the maintainer for not having time, or just flat out not wanting to fix it for me.
But having written that out, I see what you are trying to say. There's no need to point out my timelines, or ask for an ETA or anything like that. At the end of the day I'm responsable for my code, so I'd be better off just making the issue about the actual issue, and set a deadline (internally in my team or to myself, not publicly) that if it's not fixed by that time I do it myself.
I opened an issue, but struggled on how to get across the feeling of "If this isn't fixed i'll need to do it myself", but without the demanding feel.
I'm completely okay with a "can't get to it now" and i'll take over and fix the problem in the library myself for myself (making a PR if it makes sense to), or completely replace it with my own code or another library. And I would never fault the maintainer for not having time, or just flat out not wanting to fix it for me.
But having written that out, I see what you are trying to say. There's no need to point out my timelines, or ask for an ETA or anything like that. At the end of the day I'm responsable for my code, so I'd be better off just making the issue about the actual issue, and set a deadline (internally in my team or to myself, not publicly) that if it's not fixed by that time I do it myself.
In your example the answer seems clear to me, communicate that you have a deadline, but are willing to fix this if they are busy and ask them if they have any thoughts on how they would like the issue to be resolved.
Exactly. I am very comfortable saying "please send a pull request" in response to the request for a feature, or the report of a bug. I try to be overtly encouraging, suggesting that when people suggest ideas, they dive in and try to build it.
The best way to scale a project and community is not to try to do everything yourself, and instead encourage other people and empower them to act. They may need assistance in the beginning, but the benefit will pay off in the long term: "If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime" (attribution unknown)
This does require giving up some control. Properly empowering people to contribute means that you need to, to varying gradual extents, respect their judgment and not try to veto or assert too much control. No person will work on any one project forever, and so a gradual and seamless transition of project leadership from one person to another requires a gradual trust in the other's judgment; trust in judgment necessitates room to make mistakes.
If you need something from a project or organization that you are not paying, then do not engage with the expectation that they'll do work for you. Instead, engage as a collaborator by offering to bring something to the table. Point out the bug, offer to fix it, and suggest a possible solution. Or if you just want to point out the bug, that's fine, but don't carry an expectation that someone will volunteer to fix it for you.
The best way to scale a project and community is not to try to do everything yourself, and instead encourage other people and empower them to act. They may need assistance in the beginning, but the benefit will pay off in the long term: "If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime" (attribution unknown)
This does require giving up some control. Properly empowering people to contribute means that you need to, to varying gradual extents, respect their judgment and not try to veto or assert too much control. No person will work on any one project forever, and so a gradual and seamless transition of project leadership from one person to another requires a gradual trust in the other's judgment; trust in judgment necessitates room to make mistakes.
If you need something from a project or organization that you are not paying, then do not engage with the expectation that they'll do work for you. Instead, engage as a collaborator by offering to bring something to the table. Point out the bug, offer to fix it, and suggest a possible solution. Or if you just want to point out the bug, that's fine, but don't carry an expectation that someone will volunteer to fix it for you.
First and foremost, be nice. Secondly, you should assume that anything you "need" will not be built by anyone but you. If you end up with a "showstopper" in OSS, it is time for helpful contributions. Either that or you should find a different solution. A helpful contribution might including opening a civil dialogue about a feature. "Is this a feature that the project could consider within scope? How could I go about adding that feature?" Ask for guidance; don't demand solutions.
How should I ask for help/bugfixes/solutions? How can I get across that an issue is a "showstopper" for us without demanding anything?
"Can I hire you to fix this? If you're not available, can you suggest someone else I could hire?"
It doesn't even matter if I want to get paid (and for small things I'll often encourage people to make a donation to the FreeBSD Foundation instead); the fact that you're offering to pay for work communicates "this matters to us" far more clearly than "OMG THIS IS SO BROKEN WHY CAN'T YOU FIX IT ALREADY???".
"Can I hire you to fix this? If you're not available, can you suggest someone else I could hire?"
It doesn't even matter if I want to get paid (and for small things I'll often encourage people to make a donation to the FreeBSD Foundation instead); the fact that you're offering to pay for work communicates "this matters to us" far more clearly than "OMG THIS IS SO BROKEN WHY CAN'T YOU FIX IT ALREADY???".
Invest some more of your time into your request. Like said before about context. The less the maintainer has to switch into the context of the problem and try to understand what is the underlying problem (which is often the case) the better.
Always read into the projects contribution guidelines (if any) and read into the project development structure (tests/CI, style guidelines, architecture, bug report templates). Most of the times there are ways to take load of the maintainers. Take example from other contributions and similar features in the project to 'feel' the projects architecture/design/style and always look at the bigger picture of your proposed change/request.
Don't make it about fixing your specific problem but about improving the project in general for everyone.
And like said before, you can ask for anything, but should not take an expecting/demanding attitude. After all these people are already saving you tons of time and money.
Always read into the projects contribution guidelines (if any) and read into the project development structure (tests/CI, style guidelines, architecture, bug report templates). Most of the times there are ways to take load of the maintainers. Take example from other contributions and similar features in the project to 'feel' the projects architecture/design/style and always look at the bigger picture of your proposed change/request.
Don't make it about fixing your specific problem but about improving the project in general for everyone.
And like said before, you can ask for anything, but should not take an expecting/demanding attitude. After all these people are already saving you tons of time and money.
IMO, if you end up in that situation, you need to invest more effort into figuring out a good solution from the library perspective & maybe even be willing to spend the time to implement it - that is the only way you can effect positive change in a more guaranteed fashion towards something that will solve your pain point.
Problem is, if you don't come up with a solution, there's no guarantee that the maintainer(s) will be willing to act on it (depending on severity, risk of impact to other users if a change is made with [insert issue], priorities, etc.). If you invest effort towards figuring out a solution/figuring out what is wrong, it helps maintainers dramatically. If it is a persistent pain point, it may be even worthwhile to have a developer devote some time to becoming a maintainer of the project itself, so it derisks your business.
Problem is, if you don't come up with a solution, there's no guarantee that the maintainer(s) will be willing to act on it (depending on severity, risk of impact to other users if a change is made with [insert issue], priorities, etc.). If you invest effort towards figuring out a solution/figuring out what is wrong, it helps maintainers dramatically. If it is a persistent pain point, it may be even worthwhile to have a developer devote some time to becoming a maintainer of the project itself, so it derisks your business.
> How should I ask for help/bugfixes/solutions? How can I get across that an issue is a "showstopper" for us without demanding anything?
While I know that from experience that these situations can be frustrating and even costly, why should your showstopper put an onus on anybody but you in absence of a support agreement?
I think here you can certainly ask and explain your situation. But if the answer is "no, I can't right now", your response needs to be to find someone with the knowledge, time and willingness to make the change on a fork of the original repo/source. This may require a contract or other arrangement.
It may or may not ever get upstreamed - because upstream has to consider whether a given approach to a fix is in line with what they want for the direction of the project. Regardless, though, it ensures you get the fix that is a critical showstopper for you.
While I know that from experience that these situations can be frustrating and even costly, why should your showstopper put an onus on anybody but you in absence of a support agreement?
I think here you can certainly ask and explain your situation. But if the answer is "no, I can't right now", your response needs to be to find someone with the knowledge, time and willingness to make the change on a fork of the original repo/source. This may require a contract or other arrangement.
It may or may not ever get upstreamed - because upstream has to consider whether a given approach to a fix is in line with what they want for the direction of the project. Regardless, though, it ensures you get the fix that is a critical showstopper for you.
Don't demand, just explain. Stay positive, don't whine or despair, just explain.
File as _good a bug report as you can_, which means taking _extra time_ on your side to do so. The ultimate is a bug report with a failing test case and/or demonstration app.
By the time you're there, you're often more than half a way to actually fixing the bug and sending a PR/patch, which is of course great too, but not neccesary to be a good bug reporter.
But do as much work as you can when filing the bug to save as much time as you can from the responder. Clearly describe the context and problem, what happened that you think was wrong, what you expected to happen as 'right'. And actual code demonstration in the form of failing test or demo app is _amazing_.
File as _good a bug report as you can_, which means taking _extra time_ on your side to do so. The ultimate is a bug report with a failing test case and/or demonstration app.
By the time you're there, you're often more than half a way to actually fixing the bug and sending a PR/patch, which is of course great too, but not neccesary to be a good bug reporter.
But do as much work as you can when filing the bug to save as much time as you can from the responder. Clearly describe the context and problem, what happened that you think was wrong, what you expected to happen as 'right'. And actual code demonstration in the form of failing test or demo app is _amazing_.
I'm not a maintainer, but if it's a showstopper, then it seems like you should just get a developer to write a patch no? You could probably ask the maintainer whether they can help do this, but if not, just ask for (potentially paid) assistance so that they can help your developer get up to speed on how to fix it.
In the worst case you would just have a separate fork until the patch is accepted upstream, assuming that happens at some point.
In the worst case you would just have a separate fork until the patch is accepted upstream, assuming that happens at some point.
I always thought the norm, when dealing with an open-source maintainer, is that you fix the problem and offer a patch to them. I generally won't just E-mail a maintainer or file an issue, and ask them to fix a bug in their own software for me.
Also, there's no such thing as a "show-stopper" in OSS. The show has already happened. The software is already released.
Also, there's no such thing as a "show-stopper" in OSS. The show has already happened. The software is already released.
How are things different with non-OSS software?
If you use a proprietary software application and there is a "showstopper", what happens?
If you use a proprietary software application and there is a "showstopper", what happens?
Well at that point it's a 2-way street. I'm going to ask for a solution or direction as I'm paying for it.
However with OSS I'm not. And while i'm more than fine with a "wontfix" or something similar (at the end of the day if the software won't solve my problems, that's okay, I'm not forced to use it, you aren't being forced to maintain it), I'd like to know how I can at least ask without contributing to the problem.
And even if I wanted to "pay" with contributions, they aren't free for the maintainer either. I know all too well how a well intentioned fix or change can end up causing more work and annoyance than an issue asking would have.
However with OSS I'm not. And while i'm more than fine with a "wontfix" or something similar (at the end of the day if the software won't solve my problems, that's okay, I'm not forced to use it, you aren't being forced to maintain it), I'd like to know how I can at least ask without contributing to the problem.
And even if I wanted to "pay" with contributions, they aren't free for the maintainer either. I know all too well how a well intentioned fix or change can end up causing more work and annoyance than an issue asking would have.
Why not change the relationship?
Find a contributor - on the team or not - working in that area and ask about their rates and what it would take to hire them. Some will not be interested but some will be.
At that point, it's a patch but created by someone active in the project. The worst case is that you can apply it yourself. Not great but immediate problem solved.
Long term, when you go back to the core team, you have a patch that has been tested and used, built by someone in their community, and you're not making a demand but helping address a gap (real or use case specific).
(I've worked on and managed OSS projects for 10+ years and this works pretty consistently. It requires a little more work up front but you end up with a better relationship with the maintainers and a growing network of people who you can contact for specific issues.)
Find a contributor - on the team or not - working in that area and ask about their rates and what it would take to hire them. Some will not be interested but some will be.
At that point, it's a patch but created by someone active in the project. The worst case is that you can apply it yourself. Not great but immediate problem solved.
Long term, when you go back to the core team, you have a patch that has been tested and used, built by someone in their community, and you're not making a demand but helping address a gap (real or use case specific).
(I've worked on and managed OSS projects for 10+ years and this works pretty consistently. It requires a little more work up front but you end up with a better relationship with the maintainers and a growing network of people who you can contact for specific issues.)
>Well at that point it's a 2-way street. I'm going to ask for a solution or direction as I'm paying for it.
>However with OSS I'm not.
Open source software is not the opposite of free (as in money) software. Saying this not just for you (maybe you knew it and used the term loosely) but for others too since I often see this wrong use of terms, sometimes even among people who one might think should have known of it.
There can be (and is) for-pay open source, free open source, for-pay proprietary and free proprietary software - all four possibilities. The two dimensions are orthogonal, sort of.
The fact that one or two out of the four kinds may predominate, does not change the above points.
May seem pedantic, I know, but isn't, really, IMO, and I think is worth clearing up this misconception.
Edit: typos.
>However with OSS I'm not.
Open source software is not the opposite of free (as in money) software. Saying this not just for you (maybe you knew it and used the term loosely) but for others too since I often see this wrong use of terms, sometimes even among people who one might think should have known of it.
There can be (and is) for-pay open source, free open source, for-pay proprietary and free proprietary software - all four possibilities. The two dimensions are orthogonal, sort of.
The fact that one or two out of the four kinds may predominate, does not change the above points.
May seem pedantic, I know, but isn't, really, IMO, and I think is worth clearing up this misconception.
Edit: typos.
Yes, that's a good point. Red Hat Enterprise Linux is open source software, for example, but many companies still pay for RedHat's support services, because the task of doing for yourself what they do for you can be complicated, especially where it comes to understanding, ingesting, and building security patches and things like that.
I get my boss to call the regional sales manager for our account, and say we're paying lots of money and we're gonna find a way to stop unless they can fix or provide a workaround for the bug. If it's truly a "showstopper".
You tell the people who sold you non fuctional software to fix the problem.
That relationship does not exist with OSS projects.
That relationship does not exist with OSS projects.
microsoft/oracle aren't gonna jump whenever some random customer says... I've had good to great experiences with msft support, but our 50 licenses or whatever just don't matter.
Create an issue along the lines of what many people have suggested already. At the end ask if the maintainer would be open to a PR for the issue. If they are go write that PR, if it truly is a "showstopper" it should be a no-brainer to spend the time on that PR.
>How can I get across that an issue is a "showstopper" for us ... ?
If it's costing you money and you're an IT shop, I'd hope you could task a dev to spend an hour or two to fix the issue and provide a patch.
If it's costing you money and you're an IT shop, I'd hope you could task a dev to spend an hour or two to fix the issue and provide a patch.
The solution is to get more personally involved. They don't owe you anything.
While that's true, even contributions can contribute to the burnout, especially when they are made without any input from the maintainers.
The classic "massive PR that changes how something fundamentally works" comes to mind. And while I'd hope i'm not going to do something quite that big, throwing a bunch of code at them and saying "put this in?" feels much worse than asking. Not to mention that it will end up being a waste of my own time as well.
The classic "massive PR that changes how something fundamentally works" comes to mind. And while I'd hope i'm not going to do something quite that big, throwing a bunch of code at them and saying "put this in?" feels much worse than asking. Not to mention that it will end up being a waste of my own time as well.
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 )
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! :)
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 )
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! :)
There is a nice canonical document called "How To Ask Questions The Smart Way" that you can point people to, who ask questions in technical communities and need to be educated on how to do so properly: http://www.catb.org/~esr/faqs/smart-questions.html
Is there a canonical document for "How To Engage With Open Source The Smart Way"? Seems like it'd be useful to have a document like that explains these issues, that you can simply refer people to, without having to explain them every time in a one-off way.
Is there a canonical document for "How To Engage With Open Source The Smart Way"? Seems like it'd be useful to have a document like that explains these issues, that you can simply refer people to, without having to explain them every time in a one-off way.
> 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)
I find this to be so true. Both as a condo board members and someone who volunteers time for an open studio event.
(everyone is great in the building but there are those 2 new complainers/threateners ...and they have had a chilling effect on everything). The feeling in the building changes because of those 2. Try not to let that happen.
Be polite people! It makes a big difference.
I find this to be so true. Both as a condo board members and someone who volunteers time for an open studio event.
(everyone is great in the building but there are those 2 new complainers/threateners ...and they have had a chilling effect on everything). The feeling in the building changes because of those 2. Try not to let that happen.
Be polite people! It makes a big difference.
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.
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.
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.
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.
The throng of non-programming users is valuable; they provide free testing. Also, they create a feeling of importance.
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.
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.
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.
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.
Brett, thanks for contributions to Python.
(... and thanks to the other contributors, 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!
(... and thanks to the other contributors, 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!
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.
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.
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.
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.
I think closing an issue with a link to a post guideline is in order. Have in the guideline that "any post closed with a link to this thread may be resubmitted, provided offending commentary is left out" etc
I don't run any OSS projects myself, but I can't imagine anyone would fault you if you called-out people who demonstrate the behavior you're describing. If not a direct response to their rudeness, maybe a request that they comply with some basic guidelines when posting issue (guidelines you'd of course have to post).
I think this gets you unquestionable justification for declining to respond to rude questions, but it also serves as declaring norms for people who may just be ignorant to OSS norms (or even regular social norms).
I think this gets you unquestionable justification for declining to respond to rude questions, but it also serves as declaring norms for people who may just be ignorant to OSS norms (or even regular social norms).
> 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.
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.
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.
I think the best thing to do is to just delete all abuse.
Sometimes I think every issue submission form should be a multi-page wizard that starts with a few questions, like “Do you understand that this software is being maintained by people in their spare time, free of charge, and will you promise to be civil in your requests? Agree/Cancel”, before they can even reach an insta-complaint text field.
As long as you're not paying the party producing $software, I don't think it should matter whether they're doing it in their spare time, or during job hours, or as their primary task. You're benefiting from their work. For free. Behave.
Not that you shouldn't behave if you're paying for the work, but in that case you can expect more investigatory work from the providing party.
Not that you shouldn't behave if you're paying for the work, but in that case you can expect more investigatory work from the providing party.
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.
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.
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.
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.
This is a brilliant point. Programming has always been a fundamentally collaborative discipline and of course communication is paramount to proper collaboration. And it's easy to forget this when you're spending hours alone mired in code.
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...
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.
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...
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.
[deleted]
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.
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.
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 :) ).
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 :) ).
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.
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.
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. :)
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. :)
[deleted]
> [...] 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.
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.
Check out "Issues from hell"[1] Twitter account, they collected a ton of terrible behavior in open source forums:
[1] https://twitter.com/issuesfromhell
[1] https://twitter.com/issuesfromhell
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.
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.
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.
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.
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...
... 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...
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.
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.
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.
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.
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!
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!
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.)
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.)
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...
I wrote a little something about the subject recently: https://inkscape.org/en/news/2016/12/13/bug-testing-roadshow...
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.
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.
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...
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...
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.
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.
This is a good takeaway; I hope more maintainers are willing to prioritize patches.
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?
Why do people vote for those sorts of policies?
> 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 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.
That's gratuitous. Please drop the flamebait when commenting here.
We detached this subthread from 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.
For the first part it matches Australia. You are required to have an ABN to reclaim tax on anything. Of course most people would just handle things via cash payments.
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.
> 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.
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.
Saying "no" to work that you cannot do in the timeframe requested is a eminently professional response. It happens all the time in the business world. It is unprofessional to accept work that you cannot perform.
> 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.
That is a false dichotomy. With OSS, you are the only person that can block your use of that software.
Ironically, your argument applies in spades to commercial software: try asking Microsoft if they are willing to change something in Windows for you. Then demand it be completed in three days. When they refuse, do you have the option to fix it via an independent company, a contractor, or yourself?
> 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.
That is a false dichotomy. With OSS, you are the only person that can block your use of that software.
Ironically, your argument applies in spades to commercial software: try asking Microsoft if they are willing to change something in Windows for you. Then demand it be completed in three days. When they refuse, do you have the option to fix it via an independent company, a contractor, or yourself?
> With OSS, you are the only person that can block your use of that software.
In theory I could build my own railroad. Enough patents have expired. In practice, I need engineers, because there's not enough time to learn everything.
In theory I could build my own railroad. Enough patents have expired. In practice, I need engineers, because there's not enough time to learn everything.
That's the same entitlement the author complained about.
Even if you're paying, you're not entitled to shit from the devs except a polite no in response to a "do this for cash please".
Even if you're paying, you're not entitled to shit from the devs except a polite no in response to a "do this for cash please".
I sometimes feel like I'm living an crazy-land. Any other sector of the economy, somebody contacting you, personally, offering cash over the barrel to do something you do every single day of your life, is a great day.
I mean, if you have reason to not take them seriously, that's fine, whatever. But only a programmer would actually be insulted by a serious offer. Boggles my mind.
I mean, if you have reason to not take them seriously, that's fine, whatever. But only a programmer would actually be insulted by a serious offer. Boggles my mind.
The blog author was insulted by (1) the person demanding work for free after he turned down doing it for money, and (2) on the demanders schedule.
It's any professionals right to say, "No, thanks." For whatever reason. There's nothing unprofessional about so doing. Your assertion that just because you offered money someone is obligated to take it -- or do anything for that matter -- is the aforementioned entitlement.
Perhaps he/she was on vacation. Or wanted to see his / her kids. Or wasn't in the mood. Or had other clients that were paying less but were in a long term relationship that is more important/valuable than a one day consulting fee. Or didn't feel like dealing with the accounting hassle of taking a one day fee. Or had an employer that isn't a fan of employees moonlighting. Or just wanted to stare at paint on the ceiling. Any of the above are perfectly good reasons to say no thanks, and that's the end of the obligation, full stop.
It's any professionals right to say, "No, thanks." For whatever reason. There's nothing unprofessional about so doing. Your assertion that just because you offered money someone is obligated to take it -- or do anything for that matter -- is the aforementioned entitlement.
Perhaps he/she was on vacation. Or wanted to see his / her kids. Or wasn't in the mood. Or had other clients that were paying less but were in a long term relationship that is more important/valuable than a one day consulting fee. Or didn't feel like dealing with the accounting hassle of taking a one day fee. Or had an employer that isn't a fan of employees moonlighting. Or just wanted to stare at paint on the ceiling. Any of the above are perfectly good reasons to say no thanks, and that's the end of the obligation, full stop.
Because they have a different mentality. Other types of people wouldn't give you something for free, much less something they slaves hours over making. And you somehow think these same people are like everyone else?
But with OSS you are not starting from scratch, you've got a (presumably) working base to start from. You don't have to learn everything, just the part you want to improve/fix. I don't think the railroad analogy helps.
Elsewhere in this thread you asserted that "there's a price", and you don't particularly care about cost. Very well: Hire engineers and pay them a market rate.
Cheaper to just buy commercial software.
Except then what if you need THAT software updated?
You contact the vendor, which is a capitalistic enterprise and so will generally entertain your needs and either provide you with the support you need, at a price, or point you towards authorized alternative service providers.
I'm aware that this paradigm couldn't possibly work with the OSS production model, but there's no reason the community couldn't band together and come up with something better than "hire an engineer or go fuck yourself."
With a little bit of creative vision, I think the FOSS world could make a ton of money. But good luck herding those cats.
I'm aware that this paradigm couldn't possibly work with the OSS production model, but there's no reason the community couldn't band together and come up with something better than "hire an engineer or go fuck yourself."
With a little bit of creative vision, I think the FOSS world could make a ton of money. But good luck herding those cats.
>> With a little bit of creative vision, I think the FOSS world could make a ton of money.
Notably, I have considered this, and as I was reading this thread, I was reminded of the BitCoin effort[1] by OpenWhisper Systems that appeared on HN not too long ago. The thing is, it's hard to get money-making models to work for "free (libre) software" in an era of increasing entitlement. That said, if there were another such system like that of the BitCoin one (but not using BitCoin or Paypal like everyone seems to resort to), I'd definitely be interested.
[1] https://whispersystems.org/blog/bithub/
Notably, I have considered this, and as I was reading this thread, I was reminded of the BitCoin effort[1] by OpenWhisper Systems that appeared on HN not too long ago. The thing is, it's hard to get money-making models to work for "free (libre) software" in an era of increasing entitlement. That said, if there were another such system like that of the BitCoin one (but not using BitCoin or Paypal like everyone seems to resort to), I'd definitely be interested.
[1] https://whispersystems.org/blog/bithub/
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.
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.
I very much agree with this.
(My employer pays me to work on a free software project that we depend on.)
> 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.
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.
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.
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.
> 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.
The difference is you can pay commercial software vendors for support. With OSS, you often can't.
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.
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.
Sure you can hire someone. But it's cheaper to buy commercial software.
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.
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.
> Free Software does not mean "non-commercial" software.
If free software cannot work for business then that's exactly what it means.
If free software cannot work for business then that's exactly what it means.
> But it's cheaper to buy commercial software.
Not once you start needing bespoke customizations, which is why companies generally start hiring programmers to hack on open source projects for them.
You'll pay through the nose when contracting a commercial company to do special snowflake work to their product just for your needs.
Not once you start needing bespoke customizations, which is why companies generally start hiring programmers to hack on open source projects for them.
You'll pay through the nose when contracting a commercial company to do special snowflake work to their product just for your needs.
This is why companies like RedHat exist in the first place.
>It should be possible for all of them. It's not, which is why OSS cannot be relied upon for business.
What's with this entitlement? It really rubs me the wrong way. Don't look a gift horse in the mouth, etc etc.
What's with this entitlement? It really rubs me the wrong way. Don't look a gift horse in the mouth, etc etc.
[deleted]
> His unwillingness to help them out is, in the eyes of the business world, unprofessional.
I disagree entirely that it's "unprofessional" to turn down work you don't want to do.
And I'm not sure I've ever seen someone suggest that before.
We have no "professional" responsibility to take jobs we don't want to take, for whatever personal reasons.
I don't think any other profession works that way either. Maybe doctors who have a professional obligation to not let people die. But lawyers, engineers, any other profession I can think of, have no professional obligation to take any job offered to them as long as the client is paying enough. That's just not a thing.
I disagree entirely that it's "unprofessional" to turn down work you don't want to do.
And I'm not sure I've ever seen someone suggest that before.
We have no "professional" responsibility to take jobs we don't want to take, for whatever personal reasons.
I don't think any other profession works that way either. Maybe doctors who have a professional obligation to not let people die. But lawyers, engineers, any other profession I can think of, have no professional obligation to take any job offered to them as long as the client is paying enough. That's just not a thing.
The beauty of OSS is that there are plenty of people willing to play ball, and they all can. So, in your hypothetical, one project maintainer is unwilling to quote you a price. Big whoop. Approach a company that professionally offers support for this project. Send a general RFQ to the appropriate mailing list and see who bites. There is an entire market worth of solutions.
Your hypothetical seems to be stuck in a vendor-client mode of thinking, with the maintainers just vendors-by-another-name, the implication being that they wholly control the ability to modify the software in question. If that were the case, 'no' would admittedly be a deeply unprofessional answer, and your conclusion would make sense. However, maintainers are not vendors. They're arbiters of what the public project is, but they have no control over what you do with the project in the confines of your domain. Acceptance of a patch into the public project is not a precondition for using it.
Your hypothetical seems to be stuck in a vendor-client mode of thinking, with the maintainers just vendors-by-another-name, the implication being that they wholly control the ability to modify the software in question. If that were the case, 'no' would admittedly be a deeply unprofessional answer, and your conclusion would make sense. However, maintainers are not vendors. They're arbiters of what the public project is, but they have no control over what you do with the project in the confines of your domain. Acceptance of a patch into the public project is not a precondition for using it.
He did say he had no time to help though, and I think this is a legitimate thing to say.
In my mind, it's similar to walking into a high class restaurant and being told that no, they don't have any tables available for the next three days. If you wanted the reservation for tonight, it was your responsibility to know to book far in advance. You can't decide on your own that you're willing to pay $10k for that table tonight and expect the restaurant to bargain/compromise without any consideration for staff workload, fire hazards imposed by an extra table, restaurant reputation, etc.
The restaurant has the right to refuse service. This doesn't mean it's unfit for business or an unreliable food venue (since you'd certainly be guaranteed a table if you had you made a reservation). It just means your expectations are out of line with reality.
In my mind, it's similar to walking into a high class restaurant and being told that no, they don't have any tables available for the next three days. If you wanted the reservation for tonight, it was your responsibility to know to book far in advance. You can't decide on your own that you're willing to pay $10k for that table tonight and expect the restaurant to bargain/compromise without any consideration for staff workload, fire hazards imposed by an extra table, restaurant reputation, etc.
The restaurant has the right to refuse service. This doesn't mean it's unfit for business or an unreliable food venue (since you'd certainly be guaranteed a table if you had you made a reservation). It just means your expectations are out of line with reality.
I think you're getting hammered on this because you have a very money-centric way of looking at OSS. For some people, sharing code/knowledge is for fun, not money.
>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.
No one is asking you to make anything a "pillar of your business"! If you choose to, great - you should also think about arranging for some sort of support (either in-house devs, a company with expertise in the area, or some kind of arrangement with the author). You don't get to come along later and basically demand support in return for some cash. I think it's the "demand" part of your ethics code people have a problem with - "offer cash" or "ask nicely", folks will perhaps agree with.
I love dogs and give away free puppies, and you take one no-strings-attached (express or implied). A year later your dog throws up in the backyard and you want me to drive over and clean it up for $100. No thanks. If you up the offer to $100K, I might do it. Heck, I'll clean out the cat litter box too. But that's nothing to do with the free puppy - if you offer $100K to anyone capable, they'll come by and clean it up too.
>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.
No one is asking you to make anything a "pillar of your business"! If you choose to, great - you should also think about arranging for some sort of support (either in-house devs, a company with expertise in the area, or some kind of arrangement with the author). You don't get to come along later and basically demand support in return for some cash. I think it's the "demand" part of your ethics code people have a problem with - "offer cash" or "ask nicely", folks will perhaps agree with.
I love dogs and give away free puppies, and you take one no-strings-attached (express or implied). A year later your dog throws up in the backyard and you want me to drive over and clean it up for $100. No thanks. If you up the offer to $100K, I might do it. Heck, I'll clean out the cat litter box too. But that's nothing to do with the free puppy - if you offer $100K to anyone capable, they'll come by and clean it up too.
You're essentially arguing that OSS shouldn't be considered as a viable alternative for businesses looking to solve problems.
That's fine if you want to just do it as a hobby. But if you want to make a living, you're going to have to intersect with the business world somehow.
That's fine if you want to just do it as a hobby. But if you want to make a living, you're going to have to intersect with the business world somehow.
To pick two examples, restaurants and tattoo artists can get booked up months in advance. When you ask about availability for tomorrow evening, they won't quote a price, they'll say "sorry, we're full".
You might be able to start a negotiation with them, if you're willing to spend way more than the default, but they won't start it for you. And they might say "no, not for any money" (which might mean something like: "I'm pretty sure my price is higher than you're willing to pay, and I don't want a reputation that I'm willing to balk on my commitments for money").
You might be able to start a negotiation with them, if you're willing to spend way more than the default, but they won't start it for you. And they might say "no, not for any money" (which might mean something like: "I'm pretty sure my price is higher than you're willing to pay, and I don't want a reputation that I'm willing to balk on my commitments for money").
That's a good point.
But if Frank Sinatra or POTUS wanted to buy up your entire restaurant and force you to invalidate all of the bookings for that evening, you'd accommodate them, right? There is a price you can buy a professional at.
But if Frank Sinatra or POTUS wanted to buy up your entire restaurant and force you to invalidate all of the bookings for that evening, you'd accommodate them, right? There is a price you can buy a professional at.
If you did that, wouldn't the customers whose already agreed-upon reservations you just ditched be rightfully upset, and call your behaviour "unprofessional"?
I think the professional response here would be "sure, I'll sell the restaurant to you, but only after I had a chance to fulfill the obligations I entered into, as otherwise my professional reputation gets tarnished".
I think the professional response here would be "sure, I'll sell the restaurant to you, but only after I had a chance to fulfill the obligations I entered into, as otherwise my professional reputation gets tarnished".
Your professional reputation should have a price, equal to an amount of money that would make it so you don't have to ever work in that field again.
You can explain to your customers that POTUS bought you out and offer a generous gift, paid for by POTUS.
You can explain to your customers that POTUS bought you out and offer a generous gift, paid for by POTUS.
More or less, but they aren't necessarily going to admit that unless you can credibly signal that you're willing and able to pay their price.
Brett probably did have a price (say, a billion dollars), but the person in question didn't make the right signals, probably because they weren't willing or able to pay the price.
Brett probably did have a price (say, a billion dollars), but the person in question didn't make the right signals, probably because they weren't willing or able to pay the price.
Have you ever tried to get a fix for a commercial product?
Your whole post is so out of connection with reality that I don't even know where to start.
Your whole post is so out of connection with reality that I don't even know where to start.
>I feel like we need a professional ethics code to handle situations like this.
>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?
I would love for you to point out the part of the Hippocratic Oath where doctors agree to personally call on patients at any time of day or night--as long as they're offered enough money. Or an Attorney/Lawyer's Oath that has a clause where they must take any client at any time if they're offered a generous enough consulting fee.
>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?
I would love for you to point out the part of the Hippocratic Oath where doctors agree to personally call on patients at any time of day or night--as long as they're offered enough money. Or an Attorney/Lawyer's Oath that has a clause where they must take any client at any time if they're offered a generous enough consulting fee.
No. It is unprofessional to expect 'How much' to be the only consideration.
I don't understand your logic here. Cash is the driver of business.
Wikipedia says a "A profession is a vocation founded upon specialized educational training, the purpose of which is to supply disinterested objective counsel and service to others, for a direct and definite compensation, wholly apart from expectation of other business gain"
Wikipedia says of "professional ethics",
> Some professional organizations may define their ethical approach in terms of a number of discrete components.[5] Typically these include:
> Honesty > Integrity > Transparency > Accountability > Confidentiality > Objectivity > Respectfulness > Obedience to the law > Loyalty
Your idea that the main point of professional ethics is to require someone to take a job if their client is paying enough money... is a fairly novel one.
Yes, a professional by definition gets paid for your work. However, the whole point of professional ethics is generally a professional's ethical responsibilities to consider things _other_ than money. That's the ethics part.
I'm pretty sure you won't find your idea in any ethics course in any school or any ethics code in any profession. It's just not a thing.
Wikipedia says of "professional ethics",
> Some professional organizations may define their ethical approach in terms of a number of discrete components.[5] Typically these include:
> Honesty > Integrity > Transparency > Accountability > Confidentiality > Objectivity > Respectfulness > Obedience to the law > Loyalty
Your idea that the main point of professional ethics is to require someone to take a job if their client is paying enough money... is a fairly novel one.
Yes, a professional by definition gets paid for your work. However, the whole point of professional ethics is generally a professional's ethical responsibilities to consider things _other_ than money. That's the ethics part.
I'm pretty sure you won't find your idea in any ethics course in any school or any ethics code in any profession. It's just not a thing.
Business, however, makes a pretty lousy driver of life.
How much were you paid to post that?
And if you were in a coma for three days, how much would I have to pay you to leave the coma and work on fixing a bug for that time instead?
And if you were in a coma for three days, how much would I have to pay you to leave the coma and work on fixing a bug for that time instead?
I don't post on HN as a part of my business. If I did, then you better believe I would have already worked out how much my time spent on HN is worth to it.
There is life outside of business. But inside business, cash rules.
There is life outside of business. But inside business, cash rules.
Value is the driver of business. Cash is a vehicle for value, but is often valued far less than other vehicles.
but for someone that does this for passion it is not business. So your cash becomes coloured paper.
If a business sets itself up to depend upon a free open-source project, that business is responsible for understanding what the dependency really means to the business.
In this case, that means understanding who maintains the project, how to go about receiving help, perhaps looking at a history of how other requests were handled, and ultimately knowing what the options are (e.g. does the business have the means to maintain internal experts for all software dependencies, or even an internal fork for emergency patching, etc.?).
Otherwise, a business that “needs something” can wait in line.
In this case, that means understanding who maintains the project, how to go about receiving help, perhaps looking at a history of how other requests were handled, and ultimately knowing what the options are (e.g. does the business have the means to maintain internal experts for all software dependencies, or even an internal fork for emergency patching, etc.?).
Otherwise, a business that “needs something” can wait in line.
> I can't rely on OSS as a pillar of my business.
'professional' people don't need $10k to be your personal bitch on a 3 day deadline. if you asked me, i would hang up the phone. not even worth the oxygen to respond, because you don't even exist in my world.
try cold calling a corporate lawyer, or surgeon, to do that. the realistic price is more like $50k, and anyone with half a brain or a shred of personal dignity is going to ask for it up front and with no contract.
'professional' people don't need $10k to be your personal bitch on a 3 day deadline. if you asked me, i would hang up the phone. not even worth the oxygen to respond, because you don't even exist in my world.
try cold calling a corporate lawyer, or surgeon, to do that. the realistic price is more like $50k, and anyone with half a brain or a shred of personal dignity is going to ask for it up front and with no contract.
My point is that there's a price. It doesn't matter that it's high. Just that there is one.
That's sort of a useless point. For, say, a billion dollars, most people would do just about anything. That's not very useful.
there is most definitely NOT "always a price". a person's time is their own. take your bs and bugger off.
there isn't always one. some people are rich, remember?
[deleted]
So you just get off on it?
> 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.
To some extent, it's already solved: you can pay for commercial support on many Open Source products if you want to, but those services are from other providers. If you open a GitHub issue or send a message to a maintainer's personal email address then almost by definition you are not asking for a business support arrangement.
I actually think that a lot of these issues would be seriously helped if GitHub issues could make a clear distinction between code contributions and support requests.
> 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.
To some extent, it's already solved: you can pay for commercial support on many Open Source products if you want to, but those services are from other providers. If you open a GitHub issue or send a message to a maintainer's personal email address then almost by definition you are not asking for a business support arrangement.
I actually think that a lot of these issues would be seriously helped if GitHub issues could make a clear distinction between code contributions and support requests.
[deleted]
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.