Press "Enter" to skip to content

Microsoft’s U-Turn After Open Source Outcry Over ‘Hot Reload’ Decision

Microsoft discovers that no matter how much control it wants over .NET, an open source foundation is ultimately controlled by its community.

Microsoft office building

Never underestimate the power of open source developers to make a tech giant grovel.

Microsoft has done an about face on an announcement made Wednesday in a blog by Dmitry Lyalin, a MS principal program manager, who announced that Redmond was removing a Hot Reload feature from .NET, its cross-platform open source framework for developers, after a huge outcry from open source developers that spread from GitHub, to Hacker News, and across social networks.

The brouhaha even moved The Verge to proclaim on Friday, “Microsoft risks burning all of its good open source work.”

The feature in question, which allows changes to be made to source code on-the-fly, with the software running, in order to instantly see the effects of the change, was highly anticipated by developers who fully expected to see the feature included in the next ready-for-prime-time .NET release. It’s already included in a .NET 6 release candidate, which as a rule means that Microsoft developers are looking for bugs, but otherwise consider the software ready for production use.

Adding fuel to the fire, was Microsoft’s assertion that Hot Reload would remain available on Visual Studio, which is not only proprietary but which only runs on Windows. This led many open source devs to express concerns that Microsoft is treating open source developers as a second class citizens.

“Microsoft does not want you to use .NET or RIDER, that’s why,” a user named Nick commented on GitHub. “Or emacs, vim, vs code, or any other editor that works with Microsoft’s own Language Server Protocol. If you use any of these on any operating system, you are a second class citizen now.”

Microsoft’s Turn Around

On Saturday, Microsoft made an abrupt U-turn, and in a blog by Scott Hunter, .NET’s director of program management, admitted making a mistake, apologized for the action (sort of conditionally, but an apology is something your rarely get out of Microsoft), and announced that the Hot Reload feature won’t be leaving .NET after all.

“First and foremost, we want to apologize,” he wrote. “We made a mistake in executing on our decision and took longer than expected to respond back to the community. We have approved the pull request to re-enable this code path and it will be in the GA build of the .NET 6 SDK.”

The pull request he referenced evidently points to a community initiated pull request to reverse Microsoft’s actions. At the time it was submitted, it was considered to be a long shot.

Hunter went on to say that Microsoft’s intent had never been to permanently kill the feature in .NET, only to put it on hold for a while.

“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,” he said. “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.”

“We underestimated the number of developers that are dependent upon this capability in their environments across scenarios, and how the CLI was being used alongside Visual Studio to drive inner loop productivity by many,” he added. “As is true with many companies, we are learning to balance the needs of OSS community and being a corporate sponsor for .NET. Sometimes we don’t get it right. When we don’t, the best we can do is learn from our mistakes and be better moving forward.”

.NET Community Issues

This faux pas came at a bad time for Microsoft and its relationship with the .NET Foundation, which it established in 2014 when it made .NET open source.

Rodney Littles II, a .NET Foundation board board member since 2020, resigned from his seat just before the most recent board election in September — over Microsoft’s control over a board that’s supposed to have a large degree of independence.

“The .NET Foundation needs to be clear and honest with the community, and tell us once and for all: are you here to enforce Microsoft’s will on .NET, or are you here to help foster and promote a healthy community?” he wrote in his blog after his resignation. “The scoreboard doesn’t look good for the latter.”

Then, during the first week in October, the foundation’s executive director — Claire Novotny, a senior program manager at Microsoft — resigned under controversy, which has led board members to question the power that Microsoft continues to hold over the project.

More recently, Miguel de Icaza, a co-founder of GNOME who’s now at Microsoft, noted that although the .NET Foundation design was based on the GNOME Foundation, there are major differences.

“The major areas where it differed [are] the permanent [Microsoft] seat and the veto power,” he said. “The latter is intended to prevent a scenario where the assets of the foundation were relicensed under a license like the GPL (I think there are reasons why this couldn’t happen, and also I think it doesn’t matter in practice, as a fork can achieve the same), but this was the rationale for it.”

Although de Icaza noted that open sourcing .NET was “a major concession from Microsoft,” and might be as far as Redmond is willing to go, there are signs that Microsoft might be ready to at least loosen its grip on the foundation going forward.

“Our desire is to create an open and vibrant ecosystem for .NET,” Hunter said. “As is true with many companies, we are learning to balance the needs of [the] OSS community and being a corporate sponsor for .NET. Sometimes we don’t get it right. When we don’t, the best we can do is learn from our mistakes and be better moving forward.”

Breaking News: