Hacker News new | ask | show | jobs
by bragr 1065 days ago
The work was already done per messages that the Twitter author/maintainer conveniently did not screenshot. The only thing they were waiting on was a release which something only the maintainer can do. Maybe it's just me, but I think it's unreasonable to be expected to paid to do the basic tasks of a project maintainer.

https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

5 comments

You do realize you're capable of maintaining internal company release right? It just costs money (to IBM), dishing out "thinly veiled demands" is free though.
The work is presumably publicly available in a branch at that point. Nothing is stopping that person from forking the repo, and bundling their own release.

This is pure laziness and exploitative to boot.

They should fork the entire project and launch a competing project rather than ask for a ballpark for the next release so they can inform their stakeholders?
You seem to be incapable of understanding that it is quite possible and not at all unusual to internally carry patches to dependencies on which your commercial product is built. In this case, the patch merely involves changing two bytes[1], three if you include the pyOpenSSL bump, something a company like IBM should easily be able to do.

[1] https://github.com/mitmproxy/mitmproxy/commit/8c6ec5cb56fbf4...

How delusional how you become to think IBM can't pay their own employees internally to release lol
Which is why paid licenses have an "Enterprise license" where response times is hours or max a day. I feel all FOSS projects should stop being fully FOSS (yes even if I get hate for saying this so be it) and adopt a mixed model where it is free up until revenue X$ and then commercial. Commercial would automatically entail fast response times (including fixing bugs, tagged releases etc).

The revenue X$ can be something reasonable. Have slabs for various revenue levels starting from something decently high: million dollars and up.

Fork it? It's MIT licensed.