Microsoft recently appointed a "quality czar." No budget. No team. No real authority.
That's like hiring a fire chief who isn't allowed to touch the hoses.
On GitHub, a project with 2,400 stars tried to replace all its code with AI-generated code and change its open source license, while keeping the same name. The internet debated the legal question: does an AI-assisted rewrite permit relicensing? They missed the real story.
Your entire tech product probably depends on code written by volunteers. Volunteers who receive no compensation, and who burn out along the way.
Three stories about the same thing: real engineering leadership isn't titles, good intentions, or the quiet exploitation of other people's work. It requires authority, resources, and accountability.
The Change Initiative That Always Fails
Twelve years of Windows security incidents, research on organizational cultures that undermine employees, and Microsoft responds by appointing one person.
This pattern is familiar from every organizational transformation I've seen fail. It always looks the same: make noise as if something is being done, appoint a title that sounds important, then avoid the hard work of actually changing processes and structures.
Real organizational change requires at least three things:
- Authority to make decisions, not just to recommend
- Budget to implement them, not just to discuss
- Accountability for outcomes, not just for reports
Without all three together, the appointment is theater. It creates the illusion of action without impact. And sometimes that's worse than doing nothing, because it gives the organization "evidence" that something is being handled, while nothing is being handled at all.
Engineering leadership that changes things starts with the question: "Who has the power to force real change, and how do you make them build systems where quality is structurally embedded?"
Open Source: The Invisible Foundation
Dan Lorenc from ChainGuard spent ten years at Google. He watched App Engine grow from before the PaaS category existed. Everything is built on open source foundations.
But what people don't talk about: there is no single "open source community" managing everything. There are random individuals uploading code to the internet under various licenses. Many of them receive no compensation, burn out over time, and stop maintaining.
Your entire stack (from the framework you're using to the security libraries you don't know exist) depends on people who could decide tomorrow they have nothing left to give.
This isn't theoretical. It happened. The Heartbleed bug in OpenSSL (code protecting a significant portion of the internet) was maintained by two or three people with no meaningful organizational backing.
Allocate resources to OSS maintenance. Not as charity, but as risk management. The same way you budget for security and SLAs, budget for the foundations you're built on.
AI and Code Ownership: The Wrong Question
The chardet project (a Python character detection library with 2,400 stars) saw a maintainer attempt to replace all the code with AI-generated code and relicense it. The internet asked: "Does an AI-assisted rewrite permit relicensing?"
But that's the wrong question.
As a maintainer of a CNCF project myself, I can tell you: writing code was never the core of open source ownership. Owning an open source project means owning the integration processes, deployment pipelines, tests, documentation, and issue triage. That's the asset built over years that can't be rewritten by AI.
There's also a deeper warning here for every engineering leader: when AI dependency becomes a tool for circumventing original contributions, you erode the community trust that makes projects live. A fork is always an option, but a community that doesn't follow you is no longer an asset you have.
Takeaways
These three stories (Microsoft's quality czar, chardet, and open source volunteers) speak to leadership in an environment where the tools change constantly but leadership principles don't:
- Organizational change requires authority + budget + accountability. Each component alone isn't enough.
- The open source you depend on is a dependency, not a backdrop. Manage it accordingly.
- AI changes who writes code, not who is responsible for it. Accountability stays with you.