Disclaimer: I work for msft, but I don't represent them in this matter nor I have any insider information. I just read the posts.
The bug post is clearly from a developer who I assume is a bit desperate to fix an issue. He certainly isn't representing Microsoft in the bug post - I assume he was naive and thought mentioning Microsoft would bring attention to the issue (it did, the wrong kind).
There's no information about the "offer" Microsoft made, but I'll take a guess: we have an initiative that selects through voting open source projects that are awarded a one time payment of "a few thousand dollars". Unless evidenced otherwise by ffmpeg, I would assume this is where that money is coming from.
A company as big as Microsoft has lots of procedures and bureaucracies involved in contracting with third parties, and I don't think they were aiming for a support contract in this instance, or, at best, someone looking for help found a simpler way of paying out, instead of going through the proper channels.
People tend to see big companies as an entity of their own, instead of a bunch of people running different processes around.
I think the lesson here is that we need to educate our developers on how to communicate with open source projects and third parties.
I also work for MSFT, and this story is frankly embarrassing. It's not even this particular case, it's that this is a pattern, both Microsoft-wide and industry-wide. The initiative you describe is part of the problem - it wouldn't even be relevant in this situation if we as a company properly funded the dependencies that we use. As you say, Microsoft has lots of procedures and bureaucracies, yet we have streamlined the use of F/OSS significantly compared to 12 years ago (I know; I was there when you had to have multiple meetings with lawyers every time you pulled in an open source dependency). Why didn't we do the same for supporting those dependencies? Why is it not part of the same workflow, even? Surely if something is a critical component in a shipping product, it needs to be sponsored appropriately automatically?
> He certainly isn't representing Microsoft in the bug post
Your coworker chose to bring Microsoft into the conversation, he even cited his work as a blocker.
Every company I've worked for as a manager or as an engineer tells me not to post on behalf of the company or my work on the company, unless approved. Because it will look like representing the company. Because it is representing the company.
Hi, this is a high priority ticket and FFmpeg is used in highly visible products all over the world. We have developers working for free while trillion dollar corporations want urgent help from volunteers. Please help,
> People tend to see big companies as an entity of their own, instead of a bunch of people running different processes around.
This is for the better. By invoking the microsoft card, they became representatives of the company. If you are using your company status to gain something, you are acting on behalf of said company. Look up respondeat superior
FFmpeg open sourced their software for all to use without having to pay for it. This was a choice they made.
Then on their own web site, they only accept 1-time donations and state “If you find FFmpeg useful, you are welcome to contribute by donating.” [0]
Then someone comes along to donate (and play by the rules they’ve set), and they publicly complain about it?
Some Advice: if you want to monetize Fortune 500 use, don’t open source it. Or at least, create a strategy that allows you to monetize it (like what Sidekiq has done).
A donation implies that no strings are attached. If Microsoft wants ffmpeg to do something for money, they have to make a business arrangement. They can't just throw some coins at ffmpeg's feet and then start making demands.
To clarify, Microsoft didn't offer a one-time payment to fix any bug. A volunteer explained for free that a command line option had changed between FFmpeg versions.
Microsoft offered a one-off payment instead of a support contract.
They also didn't commit to any timeline for responding in their own ticket tracker and certainly didn't let randos from the Internet set the priorities of the tickets. So IDK, but it sounds to me like there's some reasonable space for an agreement between the parties to be negotiated.
They can simply force all users to file bugs with technical details OR get a support contract for general questions and troubleshooting, which would be the best way of forcing companies into contracts.
They changed how a feature works and they communicated it via changelog I don't know what they should have done more. They have no service contract with ms.
I love how you just continue the lie. I linked to the changelog. Feel free to quote from there where "they communicated it via changelog". That's not even getting into how it's a shitty argument anyway, especially with as shitty of a changelog as ffmpeg has.
This is an example of why Twitter links are terrible for figuring out what’s going on. At first glance, Microsoft is donating a few thousand dollars, cool, better than nothing, why not? You have to scroll up (and you have to be logged in to do that) to read the previous tweet to realize they’re demanding “high priority” fix because FFmpeg is used in a “highly visible” Microsoft product (Teams) and an FFmpeg issue is causing issue for their customers.
Demanding? Seems like the person submitting the ticket wanted to talk to someone quickly. Without context the person submitting the issue m ight be noting that it's high priority on their side, so they're feeling pressure, in case that might convince someone to talk to them sooner to figure out the appropriate action to take.
Not everyone at MS is going to be a developer with enough knowledge to take tha appropriate action. To me this sort of reads like some hapless newbie at MS caught between their managers and the OSS developers, neither of which are getting the full context, and so are having wildly different expectations of what's appropriate.
That said, I don' think it's inappropriate to offer some money. There's many situations where that can make sense to all parties involved. For example, it could be that MS was choosing whether to sick their own resources on it and submit a patch or ask the developer in case they would appreciate the chance at some money for what would undoubtedly be easier for them to do than for some developer at MS that's unfamiliar with ffmpeg. That doesn't mean it makes sense for MS to immediately go to a support contract though, when honestly setting that up and negotiating it and getting it approved by management may itself far outstrip the time they have to get the problem fixed. That doesn't also preclude them opting for a support contract after the fact once the problem is fixed and they reassess their exposure by using ffmpeg in the way they do (why are they pushing out included libs that aren't tested?).
Calling them out publicly is probably a good way to get them to decide not to give that support contract though, since you've proven you're unprofessional enough to immediately publish once side of a grievance very publicly, and who wants to deal with worrying about that in the future?
“This is a high priority ticket” — in the context of an FFmpeg ticket it seems quite clear what “this” is: the FFmpeg ticket.
When you communicate as employee of company X, you represent company X, especially when you specifically namedrop company X. No one cares or should care whether it’s a “hapless newbie” doing the communication. Maybe do better training next time. (The specific engineer is actually quite senior if you look up their name, but that’s beside the point.)
In addition, they didn’t “immediately publish once [sic] side of a grievance”, the ticket happened quite a long time ago and was only brought up in light of the xz fiasco.
> in the context of an FFmpeg ticket it seems quite clear what “this” is: the FFmpeg ticket.
It can be. It can also be the person submitting it noting that it's high priority to them or their org. That can be useful information, but it's not necessarily a demand.
> When you communicate as employee of company X, you represent company X, especially when you specifically namedrop company X.
That's both obviously true and obviously doesn't matter in some instances. If some intern at a company starts throwing a company name around, the complaints should be seen by the company, but if it's obvious it's an intern then it's also obvious it's not something it's possible to ever entirely prevent, and in some cases it's expected it will happen and it's just a matter of how they respond internally to prevent it (Microsoft has something like 220k employees. Employees misrepresenting the company will happen).
The more power a person has at the company the less we should expect this is okay and the more criticism they should get. It scales from the intern to the CEO. I think this is fairly obvious.
If the person in question is in a senior position and was actually demanding something on behalf of Microsoft, then I agree they individually and to some degree Microsoft should be criticized for this, but I'm not sure that's what happened here, so I'll reserve my criticism.
> In addition, they didn’t “immediately publish once [sic] side of a grievance”, the ticket happened quite a long time ago and was only brought up in light of the xz fiasco.
Okay, so not immediate, which is my mistake, but it is one side of the argument with little clarification of the claims made other than the support request ticket, which doesn't go into details about the negotiations for support at all.
Consider that someone from MS could just as easily have posted something to twitter referencing that ticket and saying "We tried to work with an open source project to get a bug fixed, and even offered them money to fix it, and instead they tried to get us on a long term support before it was fixed. Unacceptable." We'd have just as much information about the specifics of what happened behind the scenes, which is none, and all it does it leave people to use their per-existing biases to fill in the missing information and choose who to believe. Better, IMO, to reserve judgement pending additional info.
That is the point of canary release process and it is not as bad as it sounds.
I know bean counters, software managers and IT people love to use the word critical for nearly everything, but in the grand, and even medium scheme of things, there is nothing critical in Teams. We aren't talking medical equipment, nuclear stuff or some simulation platform to make sure buildings are sounds and will not collapse.
It can come the other way, of course, with one or more zeroes added to the end of the price tag. For a couple of million, I don't think ffmpeg would've rejected their offer.
There's something to be said for taking this lump sum and asking for it every time a Microsoft employee files another bug. It'd be like a support contract without the obligations, which includes the freedom to let issues linger on the bottom of the issue tracker. That would create some perverse incentives and probably wouldn't help the project out much, but it may convince Microsoft to go for the cheaper support contract instead.
What I personally don't understand is why Microsoft didn't use any of their programmers to write a patch and submit it. Perhaps the task was daunting enough that their own programmers couldn't do it within their set budget?
To the last point you made: probably big corp stuff. This developer for Microsoft Teams is on a team which doesn’t have the necessary skills to understand ffmpeg, and cannot tap into any other resources in the organization because of politics / budgets / whatever. They’re still faced with bugs in their project, and as such, do the most pragmatic thing: try to work with the developers of the OSS project in question to get it resolved.
It's funny you should say that, because Microsoft does it the other way round. And they have the absolute worse premium support ever. I remember a slide from the CIO conference a few years ago that made the rounds saying that the rule for Microsoft Premium support is you don't buy Microsoft Premium support. It's obviously a joke, since without those contracts Microsoft is pretty unlikely to ever respond to your mail.
Have you looked a ffmpeg’s source? Have you looked at the manpage?? This is not some one-trick utility with a 100-line function at the center of it. It would be hubris for a newbie to the codebase to attempt a nontrivial change as a way to avoid getting support.
(Ironically, turns out that reading man page was the thing that Microsoft didn’t do, and no ffmpeg coding was required)
Boring, repetitive take. Microsoft is a large company with some crap products and some really cool stuff. Their work to bring SQL Server to Linux[1] seemed very cool.
It's a technology company with over 200,000 employees, that's in just about every industry, sometimes with bad software, sometimes with good. Are you actually going to double down on your 2024 comment equivalent of "Herr derr, Micro$hit is bad" when there's much more interesting and nuanced takes to be had, which would be much more useful to and entertaining to everyone involved in the discussion?
You do know that this is Microsoft Teams demanding immediate response support via the FFMPEG support forum. That this is a multi-billion dollar corporation who have used an Open Source piece of software for one of their most highly visible corporate products after they declined to pay for support.
Amazon don't get this because when they use free software they employ people to push back fixes upstream.
Google don't get this because they don't demand that the community fixes bugs on their timescale.
It wasn't supposed to be a gotcha, just an effort to move the discussion into interesting territory.
That said, I wouldn't call a product that diverged from Sybase SQL Server entirely in 1995, was converted to C++ a few years, later, had a complete revision of the old Sybase code in 2005, and has continued to add features over time consistently then being converted to work on Linux as something that could be dismissed as technically unimpressive for the sole reason that 20 years earlier before all that it started out as working on UNIX systems. It started this journey before Linux even existed.[1]
The big innovation, which is obvious to anyone that bothered to look into it, is that they provided and optimized system call agnostic layer to provide accurate, performant access to the base system in a way that was OS independent, and was lauded as fairly impressive and interesting at the time. That people are so fixated on the company that own the product that they can't even assess something on its own merits before dismissing it because of its association with that parent company is exactly the problem I was alluding to originally. The whole reason there's a note in the guidelines about avoiding shallow dismissals is because it lowers the quality of the site in general for everyone.
The tweet is ffmpeg saying they offered Microsoft a support contract. I'm not sure you could have a better source contradicting that. Still a nothing burger tweet.
The bug post is clearly from a developer who I assume is a bit desperate to fix an issue. He certainly isn't representing Microsoft in the bug post - I assume he was naive and thought mentioning Microsoft would bring attention to the issue (it did, the wrong kind).
There's no information about the "offer" Microsoft made, but I'll take a guess: we have an initiative that selects through voting open source projects that are awarded a one time payment of "a few thousand dollars". Unless evidenced otherwise by ffmpeg, I would assume this is where that money is coming from.
A company as big as Microsoft has lots of procedures and bureaucracies involved in contracting with third parties, and I don't think they were aiming for a support contract in this instance, or, at best, someone looking for help found a simpler way of paying out, instead of going through the proper channels.
People tend to see big companies as an entity of their own, instead of a bunch of people running different processes around.
I think the lesson here is that we need to educate our developers on how to communicate with open source projects and third parties.