--- title: "Microsoft Teams Asked Open Source Volunteers to Fix Their Bug. Then Offered $3,000." author: "Cutsio Team" date: "2026-05-14" lastmod: "2026-05-14" category: "Video Technology" excerpt: "When Microsoft Teams needed a bug fixed in FFmpeg, a Microsoft engineer posted a high-priority issue on a volunteer-run tracker and name-dropped the company to emphasize urgency. The FFmpeg team's response went viral — and exposed a systemic problem with how trillion-dollar companies treat open source." tags: ["FFmpeg", "Microsoft", "Teams", "Open Source", "Corporate Responsibility"] --- ## What did Microsoft Teams do that made the FFmpeg community so angry? A Microsoft Teams engineer posted a high-priority bug report on the FFmpeg public issue tracker, name-dropped Microsoft to emphasize the urgency, and expected the volunteer team to fix it as if they were a paid vendor — and when the FFmpeg team politely requested a support contract for ongoing maintenance, Microsoft offered a one-time payment of a few thousand dollars. The incident became a defining moment for the open source sustainability debate. The FFmpeg account posted the exchange publicly with the response: "We didn't make it up. This is what Microsoft Teams actually did." The post went viral, not because the FFmpeg community enjoys public shaming, but because the exchange was so perfectly emblematic of a broken relationship between massive corporations and the open source projects they depend on. The Microsoft engineer who posted the bug was likely acting in good faith. They had a problem, they found the FFmpeg tracker, and they filed a report following standard procedures inside Microsoft. The issue was that the standard procedures inside Microsoft did not account for the fact that FFmpeg is not a vendor. There is no support contract. There is no SLA. There is a public bug tracker maintained by volunteers, and treating it like a corporate Jira instance is a category error. When the FFmpeg team responded by asking about a support contract for long-term maintenance, the offer came back at a few thousand dollars. For context, a single senior engineer at Microsoft costs the company several hundred thousand dollars per year in salary and benefits. The offer represented a tiny fraction of the value Microsoft derives from FFmpeg, and it was framed as a one-time payment rather than ongoing support. ## Why do large companies treat open source projects like vendors? Large companies treat open source projects like vendors because their internal procurement and support processes have no mechanism for dealing with community-driven software — the only way to get a bug fixed through corporate channels is to file a ticket, escalate it, and treat the recipient as a service provider. The problem is structural. Inside a company like Microsoft, there are established processes for dealing with software vendors. You file a support ticket. The vendor has an SLA. They assign an engineer. They provide regular updates. The issue gets escalated if it is not resolved in time. Open source projects do not work this way. There is no SLA. There is no duty to respond. There is a community of volunteers who fix bugs when they have time, interest, and energy. Filing a high-priority ticket on a public tracker with the expectation that it will be treated urgently is fundamentally misunderstanding the nature of the relationship. JB Kempf explained the dynamic. "They think an open source project is a traditional vendor that they have an SLA with. They think a public bug tracker is a third-party vendor's Jira. It is not. It is there to report bugs." The solution that some companies have adopted is to create Open Source Program Offices (OSPOs). These are internal departments that understand how open source communities work. They know which projects their company depends on. They have relationships with the maintainers. They can route bug reports appropriately and, more importantly, they can ensure that the company contributes back proportionally to its usage. The Microsoft Teams engineer who filed the bug did not have access to an OSPO that could have handled the situation differently. They were a manager on one project, encountering open source for the first time, and following the only process they knew. ## What does the XZ fiasco have to do with FFmpeg and Microsoft Teams? The XZ fiasco demonstrated the catastrophic security risk of critical internet infrastructure being maintained by unpaid volunteers, and the FFmpeg-Microsoft Teams exchange showed exactly why that risk exists — companies that depend on this infrastructure refuse to pay for its maintenance. The XZ backdoor was the most serious supply chain attack ever discovered in open source software. A single volunteer maintainer, burned out and under-supported, was manipulated into giving commit access to a malicious actor who nearly inserted a backdoor into SSH, the protocol that secures remote access to most of the internet. The FFmpeg account's response connected the dots. "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." The connection to the Microsoft Teams incident is direct. When a trillion-dollar company offers a few thousand dollars for critical maintenance work, they are signaling that they do not value the infrastructure they depend on. That lack of investment creates the conditions for burnout, abandonment, and security failures. The maintainers of critical open source projects are not asking for charity. They are asking for proportionate contribution. If Microsoft derives millions of dollars of value from FFmpeg — and it does, because Teams depends on video processing — then contributing a fraction of that back to the project's maintenance is not generosity. It is paying your infrastructure costs. ## How does the "one percent" problem affect open source sustainability? The "one percent" problem refers to the reality that out of every hundred contributors to an open source project, only one will remain long-term — which means the quality bar for contributions must be extraordinarily high, and the cost of reviewing poor contributions falls on the tiny permanent core team. JB Kempf explained this dynamic directly. "The core community of VLC is five people. The core community of FFmpeg is ten to fifteen. We are the ones going to maintain your code." He continued: "One thousand contributors in the timeline and just ten staying — it is one percent chance that someone comes and stays. You will have change of job, change of wives, you have children, you have accidents in life. You are going to change jobs. You are not going to come back." This is why the code review standards in FFmpeg and VLC are so high. It is not gatekeeping. It is survival. Every line of code that gets accepted is code that the core team will have to maintain for the next decade. They cannot afford to accept code that is merely adequate. It has to be excellent, because they are the ones who will be maintaining it long after the contributor has moved on. This also explains why the response to the Microsoft Teams bug report was not just about the money. It was about respect. The bug report, with its name-dropping and urgency, did not acknowledge that the people being asked to fix it were volunteers who would still be maintaining that code years after the Microsoft engineer had moved to a different team. ## What does the "spicy tweet" strategy accomplish? The "spicy tweet" strategy accomplishes what years of polite requests could not — it forces large companies to pay attention to open source projects by creating public accountability that their internal processes cannot ignore. JB Kempf is blunt about why the strategy exists. "Unfortunately, we are so small that the only very strong power we have to solve issues is blaming on social network, because it snowballs and now they listen to us." He gave a concrete example. For more than a year, VLC could not update its Android app because of a bug in the Google Play Store. They filed support tickets. They contacted Google through every available channel. Nobody responded. The only way to get a Google engineer to pay attention was to post a spicy tweet saying they would stop distributing VLC for Android. Within days, someone from the Android team reached out. The same pattern applies to Microsoft. VLC is probably among the top ten most-used software applications on Windows. But JB does not have a contact at Microsoft. He is not part of their ISV program. Adobe and Spotify have account managers at Microsoft. VLC has a public bug tracker and a Twitter account. "The spicy tweets worked," Kieran confirmed. "Donations increased. Awareness increased. And Google started sending patches." ## How can companies properly engage with open source projects they depend on? Companies can properly engage with open source projects by establishing an Open Source Program Office, assigning engineers to contribute code rather than just filing bug reports, making regular financial contributions proportional to their usage, and treating maintainers as partners rather than vendors. The most effective form of corporate engagement with open source is engineering time. When a company assigns engineers to work on the projects they depend on, they get several benefits simultaneously: the bugs they care about get fixed, the engineers build deep expertise in the technology, and the relationship with the maintainers shifts from adversarial to collaborative. Financial contributions are also essential, but they need to be structured correctly. A one-time payment of a few thousand dollars for critical maintenance is not a contribution — it is an insult. Recurring funding that covers ongoing maintenance costs is what projects need. The exact amount depends on the project's scale, but a reasonable benchmark is that a company using FFmpeg at scale should be contributing enough to fund at least a fraction of a full-time developer position. The companies that do this well — and there are some — treat open source investment as an infrastructure cost, not a charitable donation. They understand that the software they depend on will only be maintained if they contribute to its maintenance. | Company Action | Impact on Open Source Project | Example | |---|---|---| | File bug reports without patches | Increases volunteer workload | Microsoft Teams incident | | File bug reports with patches | Helps the project improve | Google's post-backlash approach | | One-time payment | Covers immediate costs, does not solve sustainability | $3,000 offer | | Recurring funding | Enables long-term planning and hiring | Mozilla, Bloomberg models | | Assign engineers to contribute | Builds expertise and relationships | Google's AV1 contributions |

Good tools deserve proper support.

The open source infrastructure that powers video on the internet needs sustainable support. Cutsio is built on the same principles: we make video pre-processing fast, reliable, and accessible. Upload your footage, remove silences with AI, generate transcripts, and export clean XML to your NLE — without the corporate drama.

Try Cutsio Free

No credit card required. 60 minutes of free processing.

## FAQ **Did Microsoft ever properly compensate FFmpeg for the Teams bug?** The public record shows that Microsoft offered a one-time payment of a few thousand dollars, which the FFmpeg team considered inadequate. The broader public shaming campaign led to improved responsiveness from Microsoft on other issues. **What is an Open Source Program Office?** An OSPO is an internal department within a company that manages how the company engages with open source communities. OSPOs ensure that the company contributes back proportionally to its usage of open source software. **Is it ever appropriate to file a high-priority bug on an open source tracker?** Yes, but the filer should also contribute a patch or offer to fund the fix. Filing a bug without a patch on a volunteer-run project and demanding urgent attention is inappropriate. **How much should a company like Microsoft contribute to FFmpeg?** There is no standard amount, but a reasonable benchmark is that a company using FFmpeg at scale should contribute enough to fund at least a portion of a developer's salary or make recurring donations through the project's official channels. **Why do open source maintainers reject code that is "good enough"?** Maintainers reject code that is merely adequate because they are the ones who will have to maintain it for years after the contributor moves on. Only about 1% of contributors stay long-term, so the quality bar must be extremely high.