Taking a month off from OSS volunteering
snarky.ca
snarky.ca
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.
[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
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.
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
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.
THat blows my mind a bit. Particularly since forking a repository is not exactly a difficult thing.
[edit] an interesting vector: open source politics
lots of people are crazy. they walk among us!
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!)
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.
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 would say all help is welcome in successful projects -- it has to be, for longevity
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.
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!
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.
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.
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)
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.
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 ;-)
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?
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.
What do fellow HN'ers think?
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.
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.
If you use a proprietary software application and there is a "showstopper", what happens?
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.
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.)
>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.
That relationship does not exist with OSS projects.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Also, there's no such thing as a "show-stopper" in OSS. The show has already happened. The software is already released.
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_.
"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???".
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.
In the worst case you would just have a separate fork until the patch is accepted upstream, assuming that happens at some point.
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! :)
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.
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.
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 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.
(... 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!
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.
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 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).
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 think the best thing to do is to just delete all abuse.
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.
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.
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.
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.
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.
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 :) ).
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 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. :)
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.
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.
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.
... 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...
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.
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.
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!
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.)
I wrote a little something about the subject recently: https://inkscape.org/en/news/2016/12/13/bug-testing-roadshow...
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.
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...
This is a good takeaway; I hope more maintainers are willing to prioritize patches.
Why do people vote for those sorts of policies?
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.
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.
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?
There is life outside of business. But inside business, cash rules.
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.
'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.
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.
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.
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.
The difference is you can pay commercial software vendors for support. With OSS, you often can't.
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.
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.
If free software cannot work for business then that's exactly what it means.
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.
What's with this entitlement? It really rubs me the wrong way. Don't look a gift horse in the mouth, etc etc.
> 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?
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.
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.
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.
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 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.
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.
>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.
Your whole post is so out of connection with reality that I don't even know where to start.
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").
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.
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.
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".
You can explain to your customers that POTUS bought you out and offer a generous gift, paid for by POTUS.
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.
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 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.
>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.
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.
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.
> 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.