5 ms·

Reading the issue[1] I think the IBM request is a lot more reasonable than this tweet makes it seem. The issue is that a mitmproxy dependency has a CVE, mitmpro

by arp242 3y ago

Reading the issue[1] I think the IBM request is a lot more reasonable than this tweet makes it seem. The issue is that a mitmproxy dependency has a CVE, mitmproy updated the dependency (in March), but hasn't made a stable release yet with this update (last release from Nov 2022), and IBM guy is asking "when do you plan to tag a release? Do you have a timeline for this so we can communicate this to our customers?" Notably it's NOT asking for a fix; "when will you fix it?" is not accurate as there is nothing to be fixed. It's just asking "when do you plan to make a new release with this dependency update?" I don't think that's an unreasonable question. I also don't think it's unreasonable to ask for a support contract if you want these kind of fixes shipped within a certain timeframe, but the question is a lot more reasonable than it seems at a glance and immediately coming back with "email me for a support contract" seems a bit over the top to me. I could have asked this question and I think most people here could. [1]: https://github.com/mitmproxy/mitmproxy/issues/6051 https://github.com/mitmproxy/mitmproxy/issues/6051

mhils 3y ago
Asking for a release date is a perfectly reasonable request! My response was highly influenced by the context. I came back with "email me for a support contract" because 1) I previously stated in the thread that we will not ship a patch release for this[^1] and 2) the commenter emphasized the impact on their paying customers. So this was all I had to add there. I agree that I could have phrased this more nicely, but I personally don't feel my reply was totally over the top. [^1]: the CVE itself is bogus and we don't use that part of the dependency.
- politelemon 3y ago
  > the CVE itself is bogus and we don't use that part of the dependency. A trend I'm noticing, compliance and infosec teams only caring about checklists and not able to understand nuances of CVEs. They only see the number. Thus the boneheaded pursuit and odd expectations spilling into the open source ecosystem.
  - woofcat 3y ago
    Blame the government :) Anything regulated / FedRAMP etc has timelines for security issues and they simply don't care how you can explain it. It's just 'fix it'.
- account42 3y ago
  FWIW I think your initial reply was absolutely fine as is. Talking about problems with your paying customers while asking upstream to work for free is pretty tone deaf.
jlokb2341 3y ago
> The issue is that a mitmproxy dependency has a CVE, As the maintainer explained, the CVE doesn't even effect mitmproxy. All they would be doing is helping an infosec person tick off a box. > immediately coming back with "email me for a support contract" seems a bit over the top to me. Why should the maintainer work for free while the requester profits off free labor? > I don't think that's an unreasonable question What's unreasonable is FrugalGuy's entitlement. You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects.
- brightlancer 3y ago
  > You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects. In the original github comment, the corporate asked a question. Questions are not demands. He didn't say "Do this"; he _ASKED_ "When will you do this?"
  - rf15 3y ago
    That's not how it went though. They deliberately put their paying customer as a leverage topic on the table right away.
lamontcg 3y ago
> mitmproy updated the dependency (in March), but hasn't made a stable release yet with this update (last release from Nov 2022) I'm split between my blind hatred of robotic CVE checklists and my blind hatred of waterfall release management.
pella 3y ago
update mhils: "@FrugalGuy has just sent me genuine apology, which I truly appreciate. Please be nice and assume good intentions. :heart: " https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomment-1636827703 https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
whizzter 3y ago
"Just asking" by calling it an "thinly veiled extortion attempt"?
striking 3y ago
Sure, and none of that changes the threatening tone they employed when sending an email to the maintainer.
- berkle4455 3y ago
  And when it comes from his corporate email, it suddenly becomes $121B entitled company harassing a solo dev to work for free.
justinclift 3y ago
Yeah, that bit is pretty clear. It's his follow up communication referring to "thinly-veiled extortion" which is very, very far from reasonable.
- deleted 3y ago
  [deleted]
- arp242 3y ago
  > Yeah, that bit is pretty clear. It really wasn't, not from the Tweet alone, which could very easily be interpreted as demanding to fix a specific bug. As for the email: shrug. The question was reasonable, and his reply on GitHub wasn't especially great, and neither was the email. No one is coming off particularly well here IMHO.
  - bugglebeetle 3y ago
    Just FYI: in a situation where someone else is making money off other people’s unpaid labor, and then demanding they do more work for free to keep the $$$ flowing, the person doing the demanding is always the villain. I’ve been in the same situation as the requester and I did the thing any other sane, not-ridiculously-entitled developer would do: forked, patched myself, and then submitted back as a pull request.
    - rolisz 3y ago
      But you wouldn't have permissions to release a new version (which is what is being asked).
      - sickill 3y ago
        Releasing is work. It’s activity which takes time. You can’t expect someone will do it for you for free when you ask for it.
      - vlovich123 3y ago
        Nothing is stopping you from cutting a release whenever you want containing the fix.
s3p 3y ago
[flagged]
lolinder 3y ago
The initial question was polite and reasonable, as was @mhils's response. What wasn't at all reasonable was the follow-up email from IBM (same person?) accusing him of a "thinly veiled extortion attempt". Maximilian is not obliged to provide a release schedule to someone who isn't paying him, and it wasn't at all unreasonable to suggest that if IBM really needs a timetable they could pay for it. Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much.
- arp242 3y ago
  > Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much. They could, and so could I, and most people here if they wanted to. That doesn't mean it's an unreasonable question to ask. If anything it's exactly the sort of question you would ask if you planned to make your own release, so you know if it's going to be worth the effort.
  - lolinder 3y ago
    Agreed. See my first sentence: > The initial question was polite and reasonable, as was @mhils's response.
    - arp242 3y ago
      [flagged]
      - gameman144 3y ago
        I don't find it unreasonable at all, the author is under no obligation to communicate in any particular way. If a stranger drives through my neighborhood and asks "when are you going to plant begonias? I drive through here all the time but I want to see begonias", a fine response is "if you want to pay for some begonias, I'll plant them!"
        arp242 3y ago
dna_polymerase 3y ago
This makes it even worse, tbh. Just fork the code and tag an release yourself. How are regulated entities just pulling code from third party repos without a sanity check. At some size this has to happen, right?!?
pella 3y ago
recommended in similar situation: https://macwright.com/sites/polite.technology/preview https://macwright.com/sites/polite.technology/preview Emotional labor can be challenging; it requires consistently crafting polite responses. And .. managing expectations .. "EXPECTATIONS Acquiring open source software usually doesn't involve any payment. There's no contract between you and your users, or between you and the people whose software you use. But the buyer/seller relationship we have in everyday life automatically carries over into this world. People have expectations that software will work, that issues with software will quickly be fixed, and that you'll answer their questions. This relationship is often the hardest part of software because it as some similarity with traditional buyer / seller relationships but substantial and important differences. With no payment or contract, you can't give an angry user a refund. You can't suggest they leave your store. You'll naturally be in the most empowered place to make the improvements your users want, but how are their needs expressed and received? Of course, financial transactions aren't the only kind of value exchange. You might work on features in order to make your projects more popular, which leads to a better portfolio and reputation in the community. Reputation can lead to a better job or better positioning if you found a company. You might work on a feature in order to learn about the problem or acquire new skills. .... Responding to feature requests Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution. - The maintainer does not owe their time to anyone - The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden. Ignoring the second principle will damage the project and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term. Maintainers are the keepers of the project principles The goal of the software. The scope that defines problems that the software will try to fix and those it will not. The style of the project: which programming practices are used, which language. The culture by which the project is managed. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed."
- 3y ago
lozenge 3y ago
Sorry, that doesn't change anything. It is effort to tag a release regardless of whether the code changes are in the same project or a dependency.
- deleted 3y ago
  [deleted]

by arp242 3y ago

mhils 3y ago

Asking for a release date is a perfectly reasonable request! My response was highly influenced by the context. I came back with "email me for a support contract" because 1) I previously stated in the thread that we will not ship a patch release for this[^1] and 2) the commenter emphasized the impact on their paying customers. So this was all I had to add there. I agree that I could have phrased this more nicely, but I personally don't feel my reply was totally over the top. [^1]: the CVE itself is bogus and we don't use that part of the dependency.

politelemon 3y ago
> the CVE itself is bogus and we don't use that part of the dependency. A trend I'm noticing, compliance and infosec teams only caring about checklists and not able to understand nuances of CVEs. They only see the number. Thus the boneheaded pursuit and odd expectations spilling into the open source ecosystem.
- woofcat 3y ago
  Blame the government :) Anything regulated / FedRAMP etc has timelines for security issues and they simply don't care how you can explain it. It's just 'fix it'.
account42 3y ago
FWIW I think your initial reply was absolutely fine as is. Talking about problems with your paying customers while asking upstream to work for free is pretty tone deaf.

jlokb2341 3y ago

> The issue is that a mitmproxy dependency has a CVE, As the maintainer explained, the CVE doesn't even effect mitmproxy. All they would be doing is helping an infosec person tick off a box. > immediately coming back with "email me for a support contract" seems a bit over the top to me. Why should the maintainer work for free while the requester profits off free labor? > I don't think that's an unreasonable question What's unreasonable is FrugalGuy's entitlement. You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects.

brightlancer 3y ago
> You have to be a special type of hypocrite to accuse an open source maintainer of extortion after demanding they work for free. You can't demand things of volunteers working part time on foss projects. In the original github comment, the corporate asked a question. Questions are not demands. He didn't say "Do this"; he _ASKED_ "When will you do this?"
- rf15 3y ago
  That's not how it went though. They deliberately put their paying customer as a leverage topic on the table right away.

lamontcg 3y ago

> mitmproy updated the dependency (in March), but hasn't made a stable release yet with this update (last release from Nov 2022) I'm split between my blind hatred of robotic CVE checklists and my blind hatred of waterfall release management.

pella 3y ago

update mhils: "@FrugalGuy has just sent me genuine apology, which I truly appreciate. Please be nice and assume good intentions. :heart: " https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomment-1636827703 https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

whizzter 3y ago

"Just asking" by calling it an "thinly veiled extortion attempt"?

striking 3y ago

Sure, and none of that changes the threatening tone they employed when sending an email to the maintainer.

berkle4455 3y ago
And when it comes from his corporate email, it suddenly becomes $121B entitled company harassing a solo dev to work for free.

justinclift 3y ago

Yeah, that bit is pretty clear. It's his follow up communication referring to "thinly-veiled extortion" which is very, very far from reasonable.

deleted 3y ago
[deleted]
arp242 3y ago
> Yeah, that bit is pretty clear. It really wasn't, not from the Tweet alone, which could very easily be interpreted as demanding to fix a specific bug. As for the email: shrug. The question was reasonable, and his reply on GitHub wasn't especially great, and neither was the email. No one is coming off particularly well here IMHO.
- bugglebeetle 3y ago
  Just FYI: in a situation where someone else is making money off other people’s unpaid labor, and then demanding they do more work for free to keep the $$$ flowing, the person doing the demanding is always the villain. I’ve been in the same situation as the requester and I did the thing any other sane, not-ridiculously-entitled developer would do: forked, patched myself, and then submitted back as a pull request.
  - rolisz 3y ago
    But you wouldn't have permissions to release a new version (which is what is being asked).
    - sickill 3y ago
      Releasing is work. It’s activity which takes time. You can’t expect someone will do it for you for free when you ask for it.
    - vlovich123 3y ago
      Nothing is stopping you from cutting a release whenever you want containing the fix.

s3p 3y ago

[flagged]

lolinder 3y ago

The initial question was polite and reasonable, as was @mhils's response. What wasn't at all reasonable was the follow-up email from IBM (same person?) accusing him of a "thinly veiled extortion attempt". Maximilian is not obliged to provide a release schedule to someone who isn't paying him, and it wasn't at all unreasonable to suggest that if IBM really needs a timetable they could pay for it. Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much.

arp242 3y ago
> Heck, IBM could probably put together their own internal release of mitmproxy today if they cared that much. They could, and so could I, and most people here if they wanted to. That doesn't mean it's an unreasonable question to ask. If anything it's exactly the sort of question you would ask if you planned to make your own release, so you know if it's going to be worth the effort.
- lolinder 3y ago
  Agreed. See my first sentence: > The initial question was polite and reasonable, as was @mhils's response.
  - arp242 3y ago
    [flagged]
    - gameman144 3y ago
      I don't find it unreasonable at all, the author is under no obligation to communicate in any particular way. If a stranger drives through my neighborhood and asks "when are you going to plant begonias? I drive through here all the time but I want to see begonias", a fine response is "if you want to pay for some begonias, I'll plant them!"
      - arp242 3y ago

dna_polymerase 3y ago

This makes it even worse, tbh. Just fork the code and tag an release yourself. How are regulated entities just pulling code from third party repos without a sanity check. At some size this has to happen, right?!?

pella 3y ago

recommended in similar situation: https://macwright.com/sites/polite.technology/preview https://macwright.com/sites/polite.technology/preview Emotional labor can be challenging; it requires consistently crafting polite responses. And .. managing expectations .. "EXPECTATIONS Acquiring open source software usually doesn't involve any payment. There's no contract between you and your users, or between you and the people whose software you use. But the buyer/seller relationship we have in everyday life automatically carries over into this world. People have expectations that software will work, that issues with software will quickly be fixed, and that you'll answer their questions. This relationship is often the hardest part of software because it as some similarity with traditional buyer / seller relationships but substantial and important differences. With no payment or contract, you can't give an angry user a refund. You can't suggest they leave your store. You'll naturally be in the most empowered place to make the improvements your users want, but how are their needs expressed and received? Of course, financial transactions aren't the only kind of value exchange. You might work on features in order to make your projects more popular, which leads to a better portfolio and reputation in the community. Reputation can lead to a better job or better positioning if you found a company. You might work on a feature in order to learn about the problem or acquire new skills. .... Responding to feature requests Once a project achieves a certain level of success, it will have users, and those users will have additional demands of the project in the form of feature requests. Experienced and empathetic users will state their feature requests precisely and kindly, but others will use an unfriendly tone or imprecise language that doesn't lend itself to a solution. - The maintainer does not owe their time to anyone - The maintainer must treat everyone with respect Ignoring the first principle will lead to burnout: there are unlimited features to be requested and limited time to implement them. The sense of obligation quickly becomes an emotional burden. Ignoring the second principle will damage the project and reduce its chances of ever attracting additional contributors, which is the only way to succeed in the long term. Maintainers are the keepers of the project principles The goal of the software. The scope that defines problems that the software will try to fix and those it will not. The style of the project: which programming practices are used, which language. The culture by which the project is managed. Maintainers approve of changes to the software by these principles, and also manage discourse and which other contributors are allowed."

3y ago

lozenge 3y ago

Sorry, that doesn't change anything. It is effort to tag a release regardless of whether the code changes are in the same project or a dependency.

deleted 3y ago
[deleted]