> The xz fiasco has shown how a dependence on unpaid volunteers can cause major problems. Trillion dollar corporations expect free and urgent support from volunteers. @Microsoft @MicrosoftTeams posted on a bug tracker full of volunteers that their issue is "high priority".
> After politely requesting a support contract from Microsoft for long term maintenance, they offered a one-time payment of a few thousand dollars instead. This is unacceptable. We didn't make it up, this is what @microsoft @microsoftteams actually did:
https://trac.ffmpeg.org/ticket/10341#comment:4
> The lesson from the xz fiasco is that investments in maintenance and sustainability are unsexy and probably won't get a middle manager their promotion but pay off a thousandfold over many years. But try selling that to a bean counter
Not sure why FFmpeg is milking karma here. The very next comment on the thread shows that the library introduced a breaking change by changing a default behaviour, which can be restored with a new flag:
> Use -data_field first as decoder option in CLI. Default value was changed from first to auto in latest FFmpeg version.
Or modify AVOption of same name in API for this decoder.
Which seems to have solved the problem.
I have no reason to believe that the writer of the tweet is lying, but I also don't see evidence in this linked thread that Microsoft offered a one-time payment. I do agree that demanding urgent support requires you to be paying a long term support contract.
And I also think the Microsoft Engineer completely blew this interaction by name dropping his company. The bug is a bug whether it affects Microsoft or Joe Blow of Illinois. There should be no reason to expect that the bug is High Priority because it's affecting Microsoft.
However I also think it's possible to see that the bug is high priority despite affecting Microsoft.
I don't see how a design decision made by the maintainers of this project, which is documented as version changes are made - and completely transparent given the nature of the project (open-source), constitutes a high priority support request from a software engineer external to the project? Sure, it's a pain for adopters who were dependent on the feature, but you can't criticise design decisions made by someone who offers your software for free. You can, however, fork it and take your own path with the software.
Are you saying because a new version breaks the current build of a downstream proprietary application, that should constitute a high priority support request from the maintainers of the project?
That doesn't compute with me. If they were paying for forwards-compatibility and had that expectation in a contract, sure. But they should be able to make changes they see fit without having to make trade-offs to ensure future compatibility with an Enterprise organisation's product.
At that point they're basically making design decisions to suit the Enterprise, at which case - you're not just free resources for software engineering for the organisation, you're actively pushing your project to be vendor-compatible. I could see this reasoning if your project is largely funded by them (Chromium), but in this case, they're not.
That doesn't sounds like a bug. It sounds more like a change that's not backward-compatible. Who forced Microsoft to switch versions?
I'm sure many of us have been on both sides of this situation. Sometimes you have to deal with breaking changes, and sometimes you want to make them to advance your product. I think it's fair enough to request an LTS contract if you want LTS.
I think it's reasonable to *request* that a bug be treated as "High Priority because it affects my $IMPORTANT_USE_CASE". Who knows, the devs might sympathize and actually prioritize it, say because they were under the impression that it was a minor bug / rare corner case. But it's also possible that they don't, so you just shouldn't have any expectation that your request will be accepted.
Yeah, this pretty much. Big companies like Google, Amazon, Microsoft, Redhat etc. depend on Linux distros and open source software like xz to make large sums of money. But they are too cheap to fund these projects and prevent security fiascos like this.
Just like with openssl, where they didn't bother investing until months after HeartBleed.
That's an issue, but I don't know how relevant it is to the xz thing. One maintainer was specifically targeted. When he had health issues, some fake accounts started to complain and pushed for the malicious contributor to be added as a maintainer.
I suppose I think it's fair to ask the broader question: Are we only going to address the precise issue which caused the `xz`, or are we going to finally address the related elephant in the room? Too many are doing unpaid work which benefit the largest, most profitable corporations which have ever existed. And not only are they unpaid, they are generally treated like garbage by their own FOSS "communities".
I think there comes a point where many say: This is simply ridiculous. I love open source. I appreciate the opportunities it has afforded me, but the lack of dignity afforded developers and maintainers is grotesque. It's unsustainable and will collapse in upon itself, if the big players don't right the ship.
Play FOSS licensing games, win FOSS licensing prizes. No one is forcing these folks to release their stuff under those licenses, and no one should expect any kind of support for stuff released under a FOSS license.
IMO, the only real solution to this mess is getting past the stigma of paying for software and libraries. There is not enough goodwill/karma in the world to convince enough folks to pay for something they receive for free.
> IMO, the only real solution to this mess is getting past the stigma of paying for software and libraries. There is not enough goodwill/karma in the world to convince enough folks to pay for something they receive for free.
For that to work you'd need to solve liabilities internationally.
Taxes are the most pressing issue - if the company and the (F)OSS developer are in the US, it's relatively easy, but a lot of developers aren't in the US but in Europe, Africa or Asia. Some of these places have authorities that don't care about anything, but others (like Germany) are bureaucratic monsters.
Then come sanctions and AML/KYC issues - it's easy enough for an anonymous person from Russia, China, North Korea, Iran, Cuba, Venezuela or Syria to participate in a (F)OSS project. But once payments come into play, the usual regulatory bullshit comes into play as well. As, say, Microsoft, you can't just go and Western Union a few hundred dollars to an (effectively) anonymous person, you have to verify their identity and make sure that they're not the target of sanctions against themselves or their country. European countries have it easier because the only place we're seriously sanctioning outside of North Korea is Russia and Belarus, but that's a headache as well.
And then come civil liabilities. As a (F)OSS developer, all major licenses explicitly disallow warranty claims or patent claims. But once you get paid for something, that implicitly or explicitly (depending on jurisdiction) makes you a commercial trade partner, which means you can be held liable should your code prove to be the cause of a security vulnerability. And that's not even getting into the minefield of software patents and DRM, which add criminal liabilities on top of all that crap.
Even if Microsoft or whoever wanted to drop me some money for something I wrote, there's no way in hell I'd accept anything below 100k simply because all of the overhead of shielding myself. I'd need to start up the German equivalent of a LLC which costs a few thousand euros plus recurring fees for accounting requirements, I'd need to purchase insurance which given the potential claims of a company like Microsoft would run many thousand euros a month...
In an ideal world, at least the G18 (i.e. G20 minus China and Russia who already don't cooperate with the RoW that much regarding anything IP-related) would come together and agree on a common framework that makes funding for open source developers easy and hassle free, but I'd guess it would take a few xz and log4j2-level events on a global scale to even move the issue high enough that regular politicians pick it up.
Yeah that's all true, but fixing that is going to do little to address the security issues. A campaign like this would find or create another opportunity. They spent at least a year infiltrating the project.
> Yeah that's all true, but fixing that is going to do little to address the security issues.
I'm not sure this is the case. I'd imagine it would be harder to infiltrate a project which pays its contributors. Yes, there is incentive to stay on as maintainer, provide some modicum of dignity, but also maintainers wages would be traceable back to real bank accounts. Professionalize a project and that project can get serious about security, etc., too.
Microsoft really should have a support contract in place with maintainers.
This feels like they’re abusing their position by making these requests in an open forum, when really it’s likely just an employee that doesn’t know better.
I mean imo just by reading that someone senior at Microsoft told that dev to open a ticket and they just created a ticket with the exact same wording they would have used for an internal Microsoft ticket. Might not have even realized it was a third party project.
Right, and no doubt there was pressure placed on this developer (likely in a lower-level position) without any sort of actual support or resources available.
Those at the bottom of the pyramid tend to be looked upon poorly for asking questions or seeking help. The expectation was that they should be able to figure this out on their own.
And now with this press, the developer will be highlighted in their management chain. They will get the opposite (negative) reaction, which will be, "why didn't you come to us in the first place."
It's a no win situation. While this was not likely the right approach (or at minimum, the right messaging), I sympathize with the developer who is just trying to get the job done and look competent in doing so.
> After politely requesting a support contract from Microsoft for long term maintenance, they offered a one-time payment of a few thousand dollars instead. This is unacceptable. We didn't make it up, this is what @microsoft @microsoftteams actually did: https://trac.ffmpeg.org/ticket/10341#comment:4
> The lesson from the xz fiasco is that investments in maintenance and sustainability are unsexy and probably won't get a middle manager their promotion but pay off a thousandfold over many years. But try selling that to a bean counter
https://twitter.com/FFmpeg/status/1775178805704888726