[arp242]

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

[lolinder]

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.

[OhMeadhbh]

IBM is a cash poor company that just doesn't have the resources to pay for the software it sells.</snark>

Seriously though, I am kind of curious why IBM can't cough up cash. I'm guessing it takes a while to set up a vendor in their system. So they probably //could// pay for a support contract, but by the time they set it up they'll have blown through some internal deadline. Or maybe this request is being made from a lower level person and someone in their reporting chain has blocked the idea of setting up a support contract.

My memory of IBM is they're pretty insular, the particular person involved could just not understand what open source is. For instance, I was hired into a team in Boca Raton in the late 80s because my resume said I had experience with multiple Virtual Machines (VMs). I actually had experience with VMS, which was an operating system from Digital Equipment Corporation. When I asked my boss about that, her response was "What's VMS? What's Digital Equipment Corporation?" Which was a very strange thing to say as they had (more than) decimated IBM's S/36 and S/38 sales. Later on when I worked for the AIX division, I found many people who were clueful.

I think what I'm saying is:

1. IBM is a big company. It's probably not accurate to judge the whole organization from one person's interaction.

2. You can survive at IBM without understanding the outside world. (though I'm just extrapolating that assertion from what I saw in the 80s,90s and late 2000s.)

[datavirtue]

This is what it's like at GE. Stocked with people who have been there their while life. They extrapolate what they know (GE) to the outside world and hence fail to understand almost everything impacting them. The people who come there mid-career are a distinct, and marginalized, class who don't really fit in (mostly because they aren't dillusional).

[account42]

I don't think the initial response was really reasonable. Expecting an open source project that your company is leeching off of to care about your customer's problems is pretty tone deaf. Asking about a release schedule: fine. Trying to pressure the project into releasing sooner by talking about regulations: dick move.

[arp242]

> 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]

Agreed. See my first sentence:

> The initial question was polite and reasonable, as was @mhils's response.

[hitekker]

I think you’re right; the conversation was civil until the requestor started accusing the maintainer of extortion.

Some people in this thread didn’t read that far, and now seem to be to twisting reality to defend their judgement.

[ncr100]

There was a follow-up?

Not being a logged in Twitter user, the remainder of the thread is hidden to me.

[lolinder]

Third picture in the same tweet:

> I'm assuming your response to my request for the next mitmproxy target date was a joke rather than an official project response or, worse, a thinly veiled extortion attempt. In reviewing the project's official documentation...

[ncr100]

Thank you @lolinder!

[mhils]

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]

> 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]

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]

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.

[justinclift]

Yeah, that bit is pretty clear.

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

[arp242]

> 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]

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.

[arp242]

I didn't read it as "demanding"; asking a question is not "demanding".

And to repeat: there is nothing to be patched. The fix is merely an update of a dependency, which already happened months ago. It is ONLY asking "when will you tag a new release?"

[bugglebeetle]

The whole interaction has to be colored by what the person eventually sent in their email. In that light, it’s very much a demand. Do this unpaid work for me. Any request for recompense is extortion.

Secondly, this is just semantics. Fork, update the dependency or whatever reference to it, and submit back as a pull request. Or maintain the forked repo yourself if it’s that mission critical.

[scottmcf]

I fully agree. The original request can be read either either with a neutral/oblivious tone or a negative demanding tone. This is the wrong way to ask someone to do free work for you regardless if it's reasonable or not, and the issue is compounded by highlighting the financial aspect.

The followup email proves that taking a negative reading of the original request is the more reasonable read of the writer's intention.

[returningfory2]

FYI, I think that as of this comment you don't understand what the maintainer was being asked to do. There is nothing in the code to fix. There is no dependency to be updated. Forking and doing whatever isn't what's needed. The person is just asking the person to tag a new release. The requester can't do this themselves.

[berkle4455]

This is the key part half of HN can’t wrap their head around. Ron’s email clarifies his expectations and demands.

[arp242]

> Secondly, this is just semantics.

It's absolutely not "semantics", because the amount and type of work involved is radically different. Some bug is something I can fix myself with a patch; a new release isn't something I can do at all.

> Fork, update the dependency or whatever reference to it, and submit back as a pull request.

IT HAS ALREADY BEEN FIXED. How many times do I need to repeat this?

[x0x0]

You know that's nonsense.

It's not just tagging a release; the interlocutor is demanding real work, ie a full qa pass. A release means, in the real world, "we view this set of things as working, and have tested it as such. Likely including some baking in prod."

[account42]

Asking about a timeline doesn't need you to mention your paying customers and government regulations. These are mentioned specifically to create a sense of urgency while being fully aware that you are relying on free labor. This wasn't someone asking an innocent question.

[rolisz]

But you wouldn't have permissions to release a new version (which is what is being asked).

[vlovich123]

Nothing is stopping you from cutting a release whenever you want containing the fix.

[sickill]

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.

[jlokb2341]

> 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]

> 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]

That's not how it went though. They deliberately put their paying customer as a leverage topic on the table right away.

[striking]

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

[berkle4455]

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

[dna_polymerase]

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?!?

[lozenge]

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.

[pella]

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#issuecomm...

[whizzter]

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

[lamontcg]

> 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]

recommended in similar situation:

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."

[convolvatron]

Maybe the world isn’t entirely transactional And dominated by the need to grow. ' I can do a thing that provides me some value and maybe it does for you too. We both win.

[account42]

> But the buyer/seller relationship we have in everyday life automatically carries over into this world.

Only because people don't read the license which explicitly says YOUR EXPECTATIONS ARE WORTH SQUAT.