5 ms·

We are using two nice OS Python libraries on a project at work right now but I think I’ve found a bug in one of them. It has caused us lost time in development

We are using two nice OS Python libraries on a project at work right now but I think I’ve found a bug in one of them. It has caused us lost time in development and could also trip us up again. I consider it part of my job to figure out how to fix it and send a PR if I think it’s good enough quality. The idea of saying ‘we can’t do this because of a bug in X’ didn’t really cross my mind - because that’s the whole point of open source is it not? I can open up the source and debug and figure out a workaround or a fix. Just because you’re not paying for it doesn’t mean it’s free, you’re still going to have to do some work.

wildmanx 6y ago
It is free. It's so free that you are not just not paying, you even have the freedom to fix the issue yourself. And contributing the fix upstream is not selfless either. You don't want to keep dragging the patch along with every new release. You want it upstream so that you can forget about it. Just as much as the maintainer can now fix a bug which somebody else for free reported and even contributed a patch. Refusing to even listen is mindbogglingly stupid. Of course there can be disagreement about whether the bug is worth fixing or whether the patch is a good solution. But that's a different story.
- davesque 6y ago
  It's not stupid. It's just a matter of how much time the maintainer has and how they wish to spend it. People who submit PRs forget that they are the only person, at the time of submission, who understands what their PR does without any further effort. Maintainers have to spend time (away from their day job or leisure time or whatever) understanding your work and not getting paid a cent for it. For a popular project, spread that effect across a thousand or so users.
  - wildmanx 6y ago
    What I called stupid is "refusing to even listen". Of course you are not getting paid for it. Just as little as the guy sending you a patch. If you want you issue tracker to be pay-only, would you be fine with allowing people to submit patches that you can only open after paying? The "not getting paid a cent for it" is just flipping the entitlement problem around. The person reporting a bug is not entitled to a fix, nor even to be heard (even though, as I claim above, ignoring them is usually not the smartest thing for a maintainer to do). Neither is the maintainer entitled to get fixes attached to bug reports, or even a certain quality in bug reports themselves. All of this is voluntary, nobody is entitled to anything. But what you can do is foster a good culture. If you incentivize high quality bug reports, for example if somebody shows they made an effort when reporting the problem and you respond with a positive answer, then people see this and adjust their behavior accordingly. If you accept pull requests, especially high quality ones, especially those where everything is well-explained, well-structured and the maintainer's comments are addressed, people will tend to adjust and do it like that more. Just as much as if you are and asshole about bug reports, you'll likely not get high quality ones or even fixes any longer. Likewise, if a bug reporter is just rude, they won't get attention from the maintainer any longer. It's all reciprocal. Nobody is entitled to anything. If you play the game right, it's a very productive collaborative framework. And a lot of fun.
- Shorel 6y ago
  That's just a limitation of English. Parent clearly meant "gratis", while you clearly mean "libre".
cy_hauser 6y ago
> I can open up the source and debug and figure out a workaround or a fix. I use a lot of open source software I'm not even remotely capable of understanding, much less fixing. I figured I was at least an average coder but maybe I've been fooling myself.
- alibarber 6y ago
  You might well surprise yourself. The hardest part of the whole thing is accurately distilling exactly what was causing the failure. And this is also where you the user is the best placed. Mine had to do with Python Datetimes and timezones and after figuring out how to reliably reproduce it with a minimal case I could step through the stack trace and see what the library was doing (not much, just 'adding' some times together) and could see what might be causing it. (I haven't actually got to the bottom of it yet - I had other stuff to do.) But really the hard and time consuming step is that first bit. Of course, like anything it's a cost benefit - if it'll take weeks to nail it down and fix, vs using something else - then of course, a new approach is needed.

wildmanx 6y ago

It is free. It's so free that you are not just not paying, you even have the freedom to fix the issue yourself. And contributing the fix upstream is not selfless either. You don't want to keep dragging the patch along with every new release. You want it upstream so that you can forget about it. Just as much as the maintainer can now fix a bug which somebody else for free reported and even contributed a patch. Refusing to even listen is mindbogglingly stupid. Of course there can be disagreement about whether the bug is worth fixing or whether the patch is a good solution. But that's a different story.

davesque 6y ago
It's not stupid. It's just a matter of how much time the maintainer has and how they wish to spend it. People who submit PRs forget that they are the only person, at the time of submission, who understands what their PR does without any further effort. Maintainers have to spend time (away from their day job or leisure time or whatever) understanding your work and not getting paid a cent for it. For a popular project, spread that effect across a thousand or so users.
- wildmanx 6y ago
  What I called stupid is "refusing to even listen". Of course you are not getting paid for it. Just as little as the guy sending you a patch. If you want you issue tracker to be pay-only, would you be fine with allowing people to submit patches that you can only open after paying? The "not getting paid a cent for it" is just flipping the entitlement problem around. The person reporting a bug is not entitled to a fix, nor even to be heard (even though, as I claim above, ignoring them is usually not the smartest thing for a maintainer to do). Neither is the maintainer entitled to get fixes attached to bug reports, or even a certain quality in bug reports themselves. All of this is voluntary, nobody is entitled to anything. But what you can do is foster a good culture. If you incentivize high quality bug reports, for example if somebody shows they made an effort when reporting the problem and you respond with a positive answer, then people see this and adjust their behavior accordingly. If you accept pull requests, especially high quality ones, especially those where everything is well-explained, well-structured and the maintainer's comments are addressed, people will tend to adjust and do it like that more. Just as much as if you are and asshole about bug reports, you'll likely not get high quality ones or even fixes any longer. Likewise, if a bug reporter is just rude, they won't get attention from the maintainer any longer. It's all reciprocal. Nobody is entitled to anything. If you play the game right, it's a very productive collaborative framework. And a lot of fun.
Shorel 6y ago
That's just a limitation of English. Parent clearly meant "gratis", while you clearly mean "libre".

cy_hauser 6y ago

> I can open up the source and debug and figure out a workaround or a fix. I use a lot of open source software I'm not even remotely capable of understanding, much less fixing. I figured I was at least an average coder but maybe I've been fooling myself.

alibarber 6y ago
You might well surprise yourself. The hardest part of the whole thing is accurately distilling exactly what was causing the failure. And this is also where you the user is the best placed. Mine had to do with Python Datetimes and timezones and after figuring out how to reliably reproduce it with a minimal case I could step through the stack trace and see what the library was doing (not much, just 'adding' some times together) and could see what might be causing it. (I haven't actually got to the bottom of it yet - I had other stuff to do.) But really the hard and time consuming step is that first bit. Of course, like anything it's a cost benefit - if it'll take weeks to nail it down and fix, vs using something else - then of course, a new approach is needed.