7 ms·

As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Nor can you force your employer to

As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Nor can you force your employer to negotiate a contract with the maintainer. Don't get me wrong: I'm not arguing the maintainer has any responsibility to fix your issue. I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. Their choices are constrained by factors outside their control, and they are under pressure to deliver. It's this pressure that explains some of the frustration and anger that can bubble up in open source discussions. I don't think there's an easy solution, but more empathy on all sides might be a start.

hypfer 4y ago
> As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Well y'know... you're kinda being paid for that. That literally is your job. You're given money to deal with that. It is not a matter of "empathy" for a FOSS maintainer to do your job for you.
- hampereddustbin 4y ago
  If commanded, sure, but in many cases your job would actually be to communicate the changing environment to management so they may allocate more resources or pay the maintainer or whatever middleman company to upkeep the required software. Silently trying to plow through problems of these magnitudes will cause the project to be late and still cost the same. It's bad for everyone
  - marcus_holmes 4y ago
    this. As a dev, this is not your problem. If you had a dependency forced on you, and that dependency has issues that the maintainers are not willing to deal with, then escalate the problem to your manager. Of course, if you included a dependency because you thought it was a good idea, and it turns out to not be a good idea, then that's a different problem. You'll have to let management know that you'll need some time to refactor the code to remove the dependency. That could be a difficult conversation, but the answer is still not "hassle the maintainer to fix my problem"
    - deleted 4y ago
      [deleted]
    - briantakita 4y ago
      > "hassle the maintainer to fix my problem" Who is proposing that it's a good idea to hassle the maintainer? Most of these interactions go awry when someone decides to be an asshole. The tone of the article which says "fuck off" demonstrates the interpersonal impulses at play here. Choose who you rely on wisely & try not to get into bad situations. If the maintainers of project x have an ill disposition toward the community, then consider it a red flag.
  - jstummbillig 4y ago
    It's really simple: Harassing people, who explicitly waived liability in a manner that agrees with the law, is never an okay strategy. That is not to say it can't be very attractive in the face of personal adversity or be very effective, in getting you what you want. Just it's never okay. I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume?
    - hampereddustbin 4y ago
      >I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume? There are a lot of people on this site. Some of them may think differently than others, there is no way to fuse them into a single persona.
      - jstummbillig 4y ago
        But that is exactly what we do by upvoting, statistically. There is a body of prior work to look at. Our collective stance on oss or mass surveillance is clear, and you can infer the resulting upvotes with certainty, statistically (might actually be a fun game). The spirit of hn has clear biases and it's not equally open-minded towards all ideas.
        hampereddustbin 4y ago
        A tiny subset of the site's users have accounts to vote with, and even less make use of it let alone make comments. Any guess about the "average" would be quite inaccurate. The stance of a vocal minority on X can be quite clear on a given thread, but even that is just the opinion of maybe 20-40 people. And this is assuming there is no point manipulation at play, which is not the case for any popular site. In my opinion points alone can't be taken for more than a slight grain of salt.
    - alibarber 4y ago
      I simply cannot fathom the idea of harassing someone publicly on the internet to deal with a professional issue I face. In fact, at every company I've ever worked for, damaging the company's reputation by doing that would have lead to far more serious issues at work than just finding a workaround and documenting it well - and then, if suitable, contributing back to the project with something helpful.
- ricardobeat 4y ago
  I would like to know which universe everyone here lives in, where such scenario is a possibility. Let’s say you use Kubernetes. A transitive dependency that does DNS resolution in a built in module is doing something wrong, like not resolving hosts ending with the letter X. You can’t “refactor to remove the dependency”, you can’t realistically maintain a fork of the whole thing. This is what the majority of these situations look like. OSS is supposed to be a collaborative environment where everyone can contribute a little, not a “fuck you, pay me” environment.
  - asoneth 4y ago
    At the end of the day, everyone must eat and put a roof over their heads. Someone who uses an open source project in the course of their paid employment doesn't have standing to accuse volunteer maintainers of being overly motivated by money.
  - sebastianz 4y ago
    Then do not use kubernetes, if its complex enough that you cannot afford it as a dependency, with all that entails.
    - deleted 4y ago
      [deleted]
  - brudgers 4y ago
    OSS isn’t supposed to be anything other than what the license says.
  - MangoCoffee 4y ago
    >OSS is supposed to be a collaborative environment where everyone can contribute a little OSS coders doesn't owe you anything if they don't want to be collaborative. you already getting the code for free. you are paid to deal with these Open Source software. you can always buy the commercial software if Open Source is not doing what you want. > not a “fuck you, pay me” environment i don't understand. if OSS coders offer an pay option. why shouldn't they get pay? you get paid to deal with Open source software by your employer, no? you get to eat 'cause you get paid to deal with Open source software, no? why shouldn't OSS coders get to eat too? only you get to eat but not them?
- keybored 4y ago
  The hypothetical FOSS maintainer is giving a new meaning to “kill them with kindness” in this thread.
mpol 4y ago
In that case you could maintain a set of patches for upstream, instead of going for a full fork. You could document how much time you spend maintaining those patches and communicate that to your manager. If it is still cheaper to maintain that set of patches and not pay upstream, I guess that is a business decision that might financially work out.
- swiftcoder 4y ago
  "paying upstream" is fine for little independent open-source projects, but for the big popular dependencies it doesn't actually work. You can't just pay Google to work on Android/Chrome, or pay Facebook to make changes to React...
  - mpol 4y ago
    Using software from Google or Facebook, it should have been known when making that decision that there is no influence you can have on those. These companies are run by psychopaths. I do understand your point though, there will be many other software projects where the same issue is happening. I guess maintaining your own set of patches or doing a full fork are then the options. Or refactoring.
hampereddustbin 4y ago
This issue would be above the developer's paygrade. It's not the developer's job to make requirements fit in the timeframe, that would be the manglement's job. If execs have made bad decisions with regards to the developer's input on what it's going to take, the problem is solely on them.
- gpvos 4y ago
  That's a rather idealized view. In practice, management has more than enough ways to make it the developer's problem. Of course, that may mean it's time to leave.
pc86 4y ago
> I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. The whole point of this article is that these are your three options. What are you saying the fourth option is? It sounds like you're just saying "yeah but this isn't good because (for example) nobody will merge my random bug fix into React core." That's sort of the point - your options then are #2 or #3.
- chris_wot 4y ago
  If a bug fix with test coverage sits in a queue for years, just because the maintainer is an arsehole, then a bit of mild criticism should probably be expected. Consider it a fixed fork fuck you.
  - chrisseaton 4y ago
    > then a bit of mild criticism should probably be expected No they’ve every right to ignore your PRs for any reason or no reason at all. You aren’t paying them. You can ask them to merge but you’ve got no basis to criticise them because they never promised you anything.
    - chris_wot 4y ago
      In that case, I guess forking the project to fix it whilst criticising them is disallowed?
      - chrisseaton 4y ago
        Can I ask you to send me $100 and then criticise you when you don’t? Or is that an unreasonable criticism since why on earth should you send me any money?
        chris_wot 4y ago
        That’s not unreasonable, if I used your work or wanted a change.
blowski 4y ago
This all comes down to "no silver bullets" and "there are no solutions, only trade-offs". You can have codebase x for free, but depending on future changes is risky, especially if it's close to your core. A larger team are likely to be more stable, but be less amenable to any specific changes you want. You can fork the code, or provide patches, but this adds extra complexity you'll need to manage.
samsquire 4y ago
> and they are under pressure to deliver. You're being paid to deliver and the maintainer is not. This is a critical fact. The maintainer did their bit, it's time to do yours. > but more empathy on all sides might be a start. More empathy for the _maintainers_ I think.
- ricardobeat 4y ago
  > it’s time to do yours And how is fixing a bug and submitting the patch not doing your part? This is what OSS is all about.
  - samsquire 4y ago
    It isn't that's it's not doing your part, it's that to think they are equal amounts of work, time, value and money. Creating the Linux kernel is different to packaging an upstream Dependency. Or fixing a bug in a dependency. You effectively owe the maintainer again for the work they do reviewing your work. Something that takes them away from their free time and other issues. Sure both are hard and valuable but they are not equal difficulty or value. The company earns money based on the revenues produced by the software that uses the maintainers product. That money goes to you as part of your wages and you think a bug fix is enough to compensate for the maintainers additional time for looking or merging your bug. Do you see now how that might not be reasonable or fair? Your balance debt to the maintainer is negative even after your bug fix. Especially given money is involved so it's doubly negative. You also need to think of the time and money the maintainer spent in addition to the work to produce the initial product. So there you are even more indebted to the maintainer.
    - ricardobeat 4y ago
      You’re looking at this as a one-sided transaction. The distinction between producers and consumers is not clear cut, especially if you consider only the subset of developers who submit patches. In reality, unless they run their own handwritten OS, the roles are going to be reversed next week, where that maintainer benefits from the other person’s work (and salary as you say) through another piece of software. This is the premise of free software. Each contributes what they can, everyone benefits.
sbuttgereit 4y ago
For the maintainer in the scenario it is precisely that simple. For the client developer sure, they might be in a tough spot not directly of their own making but their difficult position does not somehow convey any responsibility at all to the maintainer... not even a responsibility to be sympathetic, empathetic, or kind. Any action by a frustrated developer against the maintainers at this point, any harassment whatsoever, might be explainable by the developer's situation but would not be in any way justified by it. The developer's problems are just not the maintainer's in any way and any attempt to harass the maintainers into being responsive would be unethical. Full stop.
lallysingh 4y ago
Sounds like that developer inherited a problem at work and wants to make it someone else's problem. Solving those problems is part of their job.
swatcoder 4y ago
> frustration and anger The root problem in your story is that your developer doesn’t feel like they can safely convey to their manager that the project has unexpected constraints. That form of intimidation happens, sure, but it’s not very nice to bring random strangers into the drama of your poor work environment. If you have a shitty manager that you can’t communicate with, the maintainer doesn’t deserve to become the outlet for your frustration and anger, do they? There’s a classic story of the workee coming home and taking out his work problems on his wife, who takes it out her marital problems on their kids, who take out their problems on the pets. It’s meant to help you see that shuffling your problems on other people doesn’t solve problems and instead just makes other’s lives worse.
- BowBun 4y ago
  Another take: Maybe many of us in software have enjoyed a long run of productivity driven by open source availability. That productivity is now baked into many software cultures (who doesn't assume they can use industry standard libraries, outside of very sensitive environments?) and an expected part of what programmers can do. Imagine turning around 40 years in and telling business folks "Oh crap, actually we're only 20% as effective because we've been ignoring glaring security, maintainability, and social issues around FOSS that we've simultaneously benefited from for decades". Feels like some golden handcuffs to me!

hypfer 4y ago

> As I said, as a developer working on a software project for your employer, you often inherit dependencies you had no say in. Well y'know... you're kinda being paid for that. That literally is your job. You're given money to deal with that. It is not a matter of "empathy" for a FOSS maintainer to do your job for you.

hampereddustbin 4y ago
If commanded, sure, but in many cases your job would actually be to communicate the changing environment to management so they may allocate more resources or pay the maintainer or whatever middleman company to upkeep the required software. Silently trying to plow through problems of these magnitudes will cause the project to be late and still cost the same. It's bad for everyone
- marcus_holmes 4y ago
  this. As a dev, this is not your problem. If you had a dependency forced on you, and that dependency has issues that the maintainers are not willing to deal with, then escalate the problem to your manager. Of course, if you included a dependency because you thought it was a good idea, and it turns out to not be a good idea, then that's a different problem. You'll have to let management know that you'll need some time to refactor the code to remove the dependency. That could be a difficult conversation, but the answer is still not "hassle the maintainer to fix my problem"
  - deleted 4y ago
    [deleted]
  - briantakita 4y ago
    > "hassle the maintainer to fix my problem" Who is proposing that it's a good idea to hassle the maintainer? Most of these interactions go awry when someone decides to be an asshole. The tone of the article which says "fuck off" demonstrates the interpersonal impulses at play here. Choose who you rely on wisely & try not to get into bad situations. If the maintainers of project x have an ill disposition toward the community, then consider it a red flag.
- jstummbillig 4y ago
  It's really simple: Harassing people, who explicitly waived liability in a manner that agrees with the law, is never an okay strategy. That is not to say it can't be very attractive in the face of personal adversity or be very effective, in getting you what you want. Just it's never okay. I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume?
  - hampereddustbin 4y ago
    >I am also somewhat puzzled how we are having a discussion about this on HN, where adherence to open source licenses is usually a virtue. Only as long as our work is not negatively effected, I presume? There are a lot of people on this site. Some of them may think differently than others, there is no way to fuse them into a single persona.
    - jstummbillig 4y ago
      But that is exactly what we do by upvoting, statistically. There is a body of prior work to look at. Our collective stance on oss or mass surveillance is clear, and you can infer the resulting upvotes with certainty, statistically (might actually be a fun game). The spirit of hn has clear biases and it's not equally open-minded towards all ideas.
      - hampereddustbin 4y ago
        A tiny subset of the site's users have accounts to vote with, and even less make use of it let alone make comments. Any guess about the "average" would be quite inaccurate. The stance of a vocal minority on X can be quite clear on a given thread, but even that is just the opinion of maybe 20-40 people. And this is assuming there is no point manipulation at play, which is not the case for any popular site. In my opinion points alone can't be taken for more than a slight grain of salt.
  - alibarber 4y ago
    I simply cannot fathom the idea of harassing someone publicly on the internet to deal with a professional issue I face. In fact, at every company I've ever worked for, damaging the company's reputation by doing that would have lead to far more serious issues at work than just finding a workaround and documenting it well - and then, if suitable, contributing back to the project with something helpful.
ricardobeat 4y ago
I would like to know which universe everyone here lives in, where such scenario is a possibility. Let’s say you use Kubernetes. A transitive dependency that does DNS resolution in a built in module is doing something wrong, like not resolving hosts ending with the letter X. You can’t “refactor to remove the dependency”, you can’t realistically maintain a fork of the whole thing. This is what the majority of these situations look like. OSS is supposed to be a collaborative environment where everyone can contribute a little, not a “fuck you, pay me” environment.
- asoneth 4y ago
  At the end of the day, everyone must eat and put a roof over their heads. Someone who uses an open source project in the course of their paid employment doesn't have standing to accuse volunteer maintainers of being overly motivated by money.
- sebastianz 4y ago
  Then do not use kubernetes, if its complex enough that you cannot afford it as a dependency, with all that entails.
  - deleted 4y ago
    [deleted]
- brudgers 4y ago
  OSS isn’t supposed to be anything other than what the license says.
- MangoCoffee 4y ago
  >OSS is supposed to be a collaborative environment where everyone can contribute a little OSS coders doesn't owe you anything if they don't want to be collaborative. you already getting the code for free. you are paid to deal with these Open Source software. you can always buy the commercial software if Open Source is not doing what you want. > not a “fuck you, pay me” environment i don't understand. if OSS coders offer an pay option. why shouldn't they get pay? you get paid to deal with Open source software by your employer, no? you get to eat 'cause you get paid to deal with Open source software, no? why shouldn't OSS coders get to eat too? only you get to eat but not them?
keybored 4y ago
The hypothetical FOSS maintainer is giving a new meaning to “kill them with kindness” in this thread.

mpol 4y ago

In that case you could maintain a set of patches for upstream, instead of going for a full fork. You could document how much time you spend maintaining those patches and communicate that to your manager. If it is still cheaper to maintain that set of patches and not pay upstream, I guess that is a business decision that might financially work out.

swiftcoder 4y ago
"paying upstream" is fine for little independent open-source projects, but for the big popular dependencies it doesn't actually work. You can't just pay Google to work on Android/Chrome, or pay Facebook to make changes to React...
- mpol 4y ago
  Using software from Google or Facebook, it should have been known when making that decision that there is no influence you can have on those. These companies are run by psychopaths. I do understand your point though, there will be many other software projects where the same issue is happening. I guess maintaining your own set of patches or doing a full fork are then the options. Or refactoring.

hampereddustbin 4y ago

This issue would be above the developer's paygrade. It's not the developer's job to make requirements fit in the timeframe, that would be the manglement's job. If execs have made bad decisions with regards to the developer's input on what it's going to take, the problem is solely on them.

gpvos 4y ago
That's a rather idealized view. In practice, management has more than enough ways to make it the developer's problem. Of course, that may mean it's time to leave.

pc86 4y ago

> I'm only saying that the situation for the developer facing the bug is not always as simple as the article implies. The whole point of this article is that these are your three options. What are you saying the fourth option is? It sounds like you're just saying "yeah but this isn't good because (for example) nobody will merge my random bug fix into React core." That's sort of the point - your options then are #2 or #3.

chris_wot 4y ago
If a bug fix with test coverage sits in a queue for years, just because the maintainer is an arsehole, then a bit of mild criticism should probably be expected. Consider it a fixed fork fuck you.
- chrisseaton 4y ago
  > then a bit of mild criticism should probably be expected No they’ve every right to ignore your PRs for any reason or no reason at all. You aren’t paying them. You can ask them to merge but you’ve got no basis to criticise them because they never promised you anything.
  - chris_wot 4y ago
    In that case, I guess forking the project to fix it whilst criticising them is disallowed?
    - chrisseaton 4y ago
      Can I ask you to send me $100 and then criticise you when you don’t? Or is that an unreasonable criticism since why on earth should you send me any money?
      - chris_wot 4y ago
        That’s not unreasonable, if I used your work or wanted a change.

blowski 4y ago

This all comes down to "no silver bullets" and "there are no solutions, only trade-offs". You can have codebase x for free, but depending on future changes is risky, especially if it's close to your core. A larger team are likely to be more stable, but be less amenable to any specific changes you want. You can fork the code, or provide patches, but this adds extra complexity you'll need to manage.

samsquire 4y ago

> and they are under pressure to deliver. You're being paid to deliver and the maintainer is not. This is a critical fact. The maintainer did their bit, it's time to do yours. > but more empathy on all sides might be a start. More empathy for the _maintainers_ I think.

ricardobeat 4y ago
> it’s time to do yours And how is fixing a bug and submitting the patch not doing your part? This is what OSS is all about.
- samsquire 4y ago
  It isn't that's it's not doing your part, it's that to think they are equal amounts of work, time, value and money. Creating the Linux kernel is different to packaging an upstream Dependency. Or fixing a bug in a dependency. You effectively owe the maintainer again for the work they do reviewing your work. Something that takes them away from their free time and other issues. Sure both are hard and valuable but they are not equal difficulty or value. The company earns money based on the revenues produced by the software that uses the maintainers product. That money goes to you as part of your wages and you think a bug fix is enough to compensate for the maintainers additional time for looking or merging your bug. Do you see now how that might not be reasonable or fair? Your balance debt to the maintainer is negative even after your bug fix. Especially given money is involved so it's doubly negative. You also need to think of the time and money the maintainer spent in addition to the work to produce the initial product. So there you are even more indebted to the maintainer.
  - ricardobeat 4y ago
    You’re looking at this as a one-sided transaction. The distinction between producers and consumers is not clear cut, especially if you consider only the subset of developers who submit patches. In reality, unless they run their own handwritten OS, the roles are going to be reversed next week, where that maintainer benefits from the other person’s work (and salary as you say) through another piece of software. This is the premise of free software. Each contributes what they can, everyone benefits.

sbuttgereit 4y ago

For the maintainer in the scenario it is precisely that simple. For the client developer sure, they might be in a tough spot not directly of their own making but their difficult position does not somehow convey any responsibility at all to the maintainer... not even a responsibility to be sympathetic, empathetic, or kind. Any action by a frustrated developer against the maintainers at this point, any harassment whatsoever, might be explainable by the developer's situation but would not be in any way justified by it. The developer's problems are just not the maintainer's in any way and any attempt to harass the maintainers into being responsive would be unethical. Full stop.

lallysingh 4y ago

Sounds like that developer inherited a problem at work and wants to make it someone else's problem. Solving those problems is part of their job.

swatcoder 4y ago

> frustration and anger The root problem in your story is that your developer doesn’t feel like they can safely convey to their manager that the project has unexpected constraints. That form of intimidation happens, sure, but it’s not very nice to bring random strangers into the drama of your poor work environment. If you have a shitty manager that you can’t communicate with, the maintainer doesn’t deserve to become the outlet for your frustration and anger, do they? There’s a classic story of the workee coming home and taking out his work problems on his wife, who takes it out her marital problems on their kids, who take out their problems on the pets. It’s meant to help you see that shuffling your problems on other people doesn’t solve problems and instead just makes other’s lives worse.

BowBun 4y ago
Another take: Maybe many of us in software have enjoyed a long run of productivity driven by open source availability. That productivity is now baked into many software cultures (who doesn't assume they can use industry standard libraries, outside of very sensitive environments?) and an expected part of what programmers can do. Imagine turning around 40 years in and telling business folks "Oh crap, actually we're only 20% as effective because we've been ignoring glaring security, maintainability, and social issues around FOSS that we've simultaneously benefited from for decades". Feels like some golden handcuffs to me!