I’ve got no stake in this decision as I help run F# from the Microsoft side of the world, so feel free to ignore the words that follow. But this looks like a decision I helped make in 2016 that I still regret, even though it’s all worked out and everyone seems to be happy today.

Back in 2016, we were heavily pushing the F# and .NET world towards .NET Core and a cross-platform by default world. You could argue we’re still doing that, and you’d be accurate, but back then .NET Core was missing a lot of stuff and it was kind of rough for early adopters.

The F# community stepped up and built the “F# SDK for .NET Core”, which among other things was a plugin into the .NET Core SDK itself. Our infrastructure around .NET Core was nowhere where it is today, and although we did our best, F# could be broken for arbitrary builds of .NET Core seemingly out of nowhere. But because the F# SDK could be built and updated independently of the .NET Core SDK, typically F# users would only be broken for about half a day or so.

However, this project only treated a symptom, not the root problem: F# wasn’t a part of the .NET Core SDK. So after lots of internal discussion and complicated technical negotiations, we decided that F# would be included as a part of the .NET Core SDK moving forward. Our reasons here were technical, not political - we thought the F# SDK was decent and we had a great relationship with its maintainer - but due to poor timing and communication on our part, we did not let the maintainer and broader F# community know about our decision until it was ready to ship.

This caused two problems. Firstly, the designators people had in project files were now incorrect, and unless they changed them, their projects wouldn’t build. Secondly, and more importantly, we lost a lot of trust in the primary maintainer of the F# SDK and a handful of other F# community members who supported his efforts. He had the grace to let that one go and completely forgive us after only a few short weeks, and we’re extremely grateful to still have him work with on shared interests, such as helping develop, maintain, and mentor newcomers to the F# ecosystem in the primary cross-platform tooling plugin for VSCode.

However, the damage that was done was far larger than anticipated. Only after about two years later have they been fully resolved. For two years, I would get bug reports from users saying that their older projects wouldn’t build anymore. Some people who really supported the F# SDK took a lot longer to forgive us than the actual person whose work was unceremoniously tossed to the side. I can’t prove this one way or another, but I wouldn’t be shocked if we even lost a few people from the community to other ecosystems. Some folks simply may not trust me or my peers at Microsoft to work harmoniously with the community again after this.

So, what’s the purpose of this unrelated story?

Unceremonious takebacks with no discussion or at least advance warning out of respect of the people involved is a mistake. It doesn’t really matter what the backing reasons is: policy, money, technical improvements, etc.

Please don’t take my idle thoughts here as discounting the difficulty inherent in a project like the community build, nor in the rich history involved with the projects involved and their maintainers. I also appreciate the desire to have some level of uniformity on the issue of a code of conduct (in fact, I’d love it if all OSS projects adopted the Contributor Covenant CoC). But as someone who approved a similar kind of takeback in a different ecosystem, I’ve come to regret that decision even 3 years after the fact. My advice is that someone kick off a private discussion between involved members and attempt to resolve this with the minimum goal being that nobody leaves the conversation feeling scorned.