This follows from Aaron's post and this set of tweets
Sometimes Microsoft build things that replace or compete with OSS and community alternatives. This upsets a bunch of people and it's been written about plenty.
These two pages in docs.microsoft.com are really nice counter examples - while they show the built-in Microsoft solutions, they also mention other OSS options, and even link to them:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-3.1
A much better example, Microsoft shipped a replacement for JSON serialization. I think that this page is really good:
Here's what it does well:
- It explains the goals of the Microsoft version vs. Newtonsoft.Json in a way that reads as honest
- It explains and highlights lots of cases where Newtonsoft.Json is a sensible choice
In fact it actually goes out of its way to point out the non-goals of the project and make the limited set of situations where it's useful clear. If I was the author of Newtonsoft.Json, I think I'd find this very fair and reasonable. Especially if I had chance to add some of my own comments to the page.
When WinGet or MSTest were announced, imagine if Microsoft did something similar:
- Acknowledge the open source alternatives that came before
- Explain why this project is different, and what necessetated not using those projects
- Provide a page that clearly outlines when the Microsoft solution is a good alternative, and when the OSS alternative would be a better choice - give real actionable guidance. Help .NET developers make informed choices.
- Talk to those OSS authors before the annoucement and get their feedback on the project, the goals and the page, and let them update the page as their own project evolved
I think the example with System.Text.Json vs. Newtonsoft.Json is the closest to the gold standard. With this document, a developer can to others on their team and have an intelligent conversation around the choices. It's probably the most respectful way to interact with OSS projects when building on top of one isn't an option for some reason or other.
Some projects have done this well, some less well. Something like the above would feel like a pretty good minumum bar. Internally, you could use it as acceptance criteria for your team: before we build an alternative to established OSS projects and risk alienating some of our biggest supporters, we should be able to do all of the above.