Microsoft’s Hot Reload Drama Is a Reminder to Pay Attention – InApps 2022

Last week, there was quite a bit of talk about how Microsoft was essentially trying to pull a fast one on its .NET community by reversing course and removing the “hot reload” feature from .NET and instead scoping it to Visual Code 2022. The move led to a fury of responses across the internet, a slew of seemingly cryptic tweets from the likes of Scott Hanselman and others within Microsoft, and an article that asked the question can we trust Microsoft with open source?

The article sums up the scenario nicely, asking if we can trust Microsoft, or just a small number of open source advocates within the company, to herald an open source project such as .NET into the future.

“Do you trust Microsoft with Open Source or do you actually trust people like Jon Galloway, Scott Hanselman, Scott Hunter, Guido van Rossum, David Fowler, Damian Edwards, Miguel de Icaza and a handful of other OSS champions who have been pushing the OSS message internally from the bottom up? What if these people leave .NET? Will Microsoft continue to play nicely with the community?”

The post urged the community to make its voice heard, which it did, not only on social media, but in a pull request to revert the decision that received hundreds of comments in support and was eventually merged, with Microsoft issuing an apology.

“First and foremost, we want to apologize. 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,” wrote .NET director of program management Scott Hunter.

“Our desire is to create an open and vibrant ecosystem for .NET. 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,” Hunter later continued.

Now, while you might argue that all’s well that ends well, you could also argue, as developer and software architect Alexander Trauzzi does, that it’s time for .NET to leave home. Trauzzi contends that Hunter’s blog post “accomplishes nothing and worse still, exacerbates the situation; the community definitely needs to start cornering Microsoft on their double-speak ways.”

Trauzzi lays out the argument that, while this might have the surface appearance (or explanation thereof) of a simple mix-up, it is actually Microsoft’s approach to open source as intended.

“Microsoft supporting open source is still to this day an act of appeasement, not contrition,” Trauzzi writes, citing examples like the inability of extensions to work on non-Microsoft Visual Studio Code builds. This whole hubbub, he argues, is not a problem of communication, as Hunter suggested in his blog post, but rather “a problem of intent.”

“What would things look like if open source Microsoft devotees never spoke out? How much encroachment does Microsoft attempt on a regular basis; where if there weren’t stakeholders ready to met out a moral consequence and commensurate finger-wagging, that these encroachments would eventually lead Microsoft back to their old ways?” asks Trauzzi, before finally coming to his ultimate conclusion. “The suggestion is as simple as the title of this post: The time has come for .NET to take its hope chest and go out into the world.”

Whether you come to the same conclusion as Trauzzi or not, there does seem to be one inevitable lesson from this whole affair. Open source, it would seem — much like democracy — dies in darkness, and so it would be advisable to keep paying attention to keep companies like Microsoft, who nowadays benefit from their apparent adherence to open source, accountable.

This Week in Programming

• A GitHub Universe Round-Up: First up this week, GitHub held its annual developer conference this week and was kind enough to provide a blog post highlighting everything new from GitHub Universe 2021. Of course, if you want a little more context, you could always head to our own write-up of the event as well. If you missed the event this week, you could always go back and watch on demand, but here’s the briefest recap either way. Highlights include the opening up of GitHub Issues to public beta, the introduction of labels and automatic release notes for GitHub Discussions, improved CI/CD with GitHub Actions, a “command palette” for running commands and navigating across organizations, repositories, issues, pull requests, within the GitHub UI and the private beta of pull request merge queue, which allows you to merge pull requests without updating your pull requests anytime another change lands, all while keep the branch green. Speaking of color, apparently, users were unsettled with all the red all over the place when they closed issues, so now closed issues will be purple instead. The blog also notes a number of improvements to GitHub Codespaces, code scanning support for Ruby, new access roles for repositories for Enterprise Cloud customers, and…
• GitHub Copilot Becomes Available for Neovim and JetBrains: You remember GitHub Copilot, of course, right? That’s the company’s just slightly controversial “AI pair programmer” that previously provided code completion (and even full code block suggestions) only in Visual Studio Code and GitHub Codespaces. Now, Copilot is available for use with JetBrains’ IntelliJ and PyCharm versions 2021.2 and above and Neovim 0.6 prerelease with Node.js. According to InfoWorld, the latest update to Copilot also includes the addition of multiline code completions for Java, C, C++, and C#, as well.

• Rust 1.56.0 Arrives with Rust 2021 Support: The latest version of Rust has arrived, and with it so has support for Rust 2021, the “edition” that allows for opt-in changes that might otherwise pose a backward compatibility risk. The Rust team writes that “This is a smaller edition, especially compared to 2018, but there are still some nice quality-of-life changes that require an edition opt-in to avoid breaking some corner cases in existing code” and that the edition guide offers details on new features and how to migrate. There also are some “quality-of-life changes” that require an Edition opt-in to avoid breaking some corner cases in existing code. If you want to read more about editions and Rust 2021 in particular, head on over to a blog post from last May that outlines everything.

• Docker Adds Beta Support for IPv6 on Docker Hub Registry: Docker says that Docker Hub Registry will become “one of the few container registries that supports IPv6” with the beta of IPv6 support, introduced this week. IPv6 support has been on Docker’s public roadmap, and with this release, organizations on IPv6-only networks can now opt in to use the registry directly with no NAT64 gateway. For all the details and caveats on what you might need to know (basically, if you’re still using IPv4, you don’t need to do a thing) head on over and check out the blog post.
• Go’s 2021 Developer Survey: Go developers, it’s time to let your voices be heard: the Go team has announced the 2021 Go Developer Survey. The survey is for “everyone who uses Go, used to use Go, or is interested in using Go” and will be used to help shape the future of Go. The Go team has been offering a yearly survey since 2016 (see previous years’ results here) and uses the results to shape the language moving forward. The 2021 Go Developer Survey will be open until November 16.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.