To Microsoft Developer Division Leadership

To Microsoft Developer Division Leadership,

Those of us who work in the Microsoft Developer Division (DevDiv) would like to respond to the recent controversy surrounding the pulling and reinstating of the "dotnet watch" feature of dotnet 6. While we are grateful that cooler heads prevailed and "dotnet watch" was preserved, we do not feel confident that this will not happen again?quite the opposite.

To show this point, we will look at the recent blog post by Scott Hunter (https://devblogs.microsoft.com/dotnet/net-hot-reload-support-via-cli/). Based on everything we know of the situation and how the Developer Division operates, little of what Scott wrote seems true and contradicts what happened. To be clear, this is not an attack on Scott Hunter; and instead, it shows how far others are willing to go to protect management.

"As a team, we are committed to .NET being an open platform and doing our development in the open. The very fact that we decided to adopt an open posture by default from the start for developing the Hot Reload feature is a testament to that."

Nothing about the pull request was open. We mentioned it in a blog post (https://devblogs.microsoft.com/dotnet/update-on-net-hot-reload-progress-and-visual-studio-2022-highlights/) and opaquely rushed the PR to avoid comments. How can we say we're transparent when this is so clearly the opposite? It is as if we all collectively knew this was wrong but had to go along with it anyway.

"The vast majority of the .NET developers are using Visual Studio, and we want to make sure VS delivers the best experience for .NET 6."

Even if this is true, does this imply we do not care about non Visual Studio users? How would pulling this feature so late in development make it so Visual Studio has the best experience for Hot Reload? It is insulting to those who don't always use Visual Studio for their dotnet development, and it says we don't understand our customers or even employees who use what we build.

We use CLI, and we use VS Code. Stop pretending otherwise.

"We made a mistake in executing on this plan in the way it was carried out. In our effort to scope, we inadvertently ended up deleting the source code instead of just not invoking that code path."

To be clear, blaming the engineer for this "mistake" is cowardly. The problem was removing the feature, not how they carried it out. Are we saying if only "turned it off" instead of removing it, we wouldn't have reverted the change? Would this code have been actively worked on or left to rot?

"With the runway getting short for the .NET 6 release and Visual Studio 2022, we chose to focus on bringing Hot Reload to VS2022 first."

To show that "Quality Control" was not the case with "dotnet watch," we will compare it with another product we delayed: MAUI.

MAUI is in rough shape. It was clear by RC1 that the quality was not going to be high enough by the time dotnet 6 shipped; there was too much to fix and not enough time to do it. The MAUI Team and its partners brought these issues to leadership, which pushed the product back to early next year.

There was and still is no indication that "dotnet watch" was in the same place. Going through the GitHub issues nor the dotnet team's backlog show any concerns that the quality was not there. On the contrary, it was doing just fine. These would have been brought up much sooner in our release cycle if there were real quality concerns, not three weeks before shipping.

"As is true with many companies, we are learning to balance the needs of OSS community and being a corporate sponsor for .NET."

If we read between the lines, this statement is true. We conflict with what we put into dotnet, Visual Studio, and Visual Studio Code. Keeping Hot Reload as a "value add" for Visual Studio keeps those locked into the paid product and less reason to jump to VS Code. In a cold and calculated way, that makes total sense, and it is also absolute nonsense.

What if teams working on Hot Reload for Visual Studio integrated "dotnet watch" into their products? What if leadership pulled these features weeks before the general release? How would that improve Visual Studio in any way? Are we going to keep removing parts from CLI because we're afraid we'll lose revenue from Visual Studio?

The way we build the best Visual Studio is by having the best runtime on the planet. When the Visual Studio team adds features to the foundation of dotnet, we have a consistent base for everyone to work on and contribute. We can build the best IDE by collaborating in the runtime, not making our open-source arbitrarily products worse.

What's next? Are we going to make Omnisharp a closed source product? So that we can make sure it can't get new features that take away from the "value" of Visual Studio? So that we don't give away features to Rider? How does that help us at all? These decisions by leadership make sure that Visual Studio will always be second-class to everything else on the market. Moves like these not only hurt us with customers but how we build products internally. They don't just hurt us with the "OSS community" but everyone in the Developer Division and Microsoft.

If we want to be genuinely transparent about this, we should make these changes to make this right:

We need a complete timeline, posted publically, of how this happened and those directly responsible for how it led to this.
We should never rush a PR through ever again. It was clear from the start that removing the code was the wrong action, and if we genuinely want feedback from the community, we have to be willing to listen not after but before.
If these decisions were made unilaterally by those in leadership, we need to prevent that from ever happening again. There was an apparent conflict of interest between the "needs" of VS and those of dotnet. There needs to be checks and balances to prevent any person, no matter how high up they are, from making decisions like this without genuine feedback from within and out the division.

Our goal here is not to insult any specific person in leadership who may have made this decision. Instead, it's to fix the core problem: No one should have so much power to impact a product like dotnet so close to release directly. Anyone who leads Developer Division could do the same actions, which we need to prevent. Having clear guidelines to protect these products that form the foundation of everything Visual Studio is will not only make us the best in class as stewards of Open Source software but also help us build the best IDE we can.