Why we terminated our partnership with Microsoft - Re: Next decade of open source

Aaron Stanard published a blog post about The Next Decade of .NET Open Source . It's a good summary of recent conversations and there's a lot to agree with in the post. In particular, I agree strongly with this point:

If Autofac is genuinely the better tool for your business’ case than ASP.NET Core’s built-in DI, the right behavior is to support Autofac, not lobby Microsoft to incorporate those features directly into their first party DI.

This point resonated a lot with me. I met a number of people over the years who've said something along the lines of "I really like Octopus Deploy! When Microsoft acquired In Release it wasn't very good. We told Microsoft to make it more like Octopus Deploy!".

Ummm, thanks... I guess? :sleepy: More on that below.

One part I think the post didn't touch on is that Microsoft projects don't exactly compete on a level playing field with community OSS projects . There's a simple thing Microsoft could do to change this, and it doesn't involve money. But, they won't.

In fact, I think the issue with .NET OSS is fundamentally down to Microsofts organization structure . While Octopus isn't OSS (though much of it is, and we'll invite customers to out GitHub repository), I think our experience is similar to that of many OSS projects that were displaced by a Microsoft product.

How Microsoftcouldsolve it

There's a saying in business that if you want to displace a competitor, you need to build a product that's at least 10x better. It's not enough to be "just as good". Customers will say "why should I use you, we've beeen successful with ". You need a really good reason to overcome that.

However, in the .NET ecosystem, if you're Microsoft, that's not generally true. If Microsoft wants to make a document database, a messaging framework, a unit test framework or a deployment automation tool, it only needs to be 1/10th as good before the conversation immediately becomes "why should we use you over the Microsoft thing?". Microsoft become the default option, even if they're the last to the game.

What's the solution to this?

If you look at the announcements for Microsoft products that compete with their own ecosystem, one thing you'll very rarely see is any acknowledgement of the OSS projects they displace. Any Microsoft voices who'd previously promoted the OSS project will often go quiet after the Microsoft product is released.

If Microsoft decide to release a product (open source or not) in a space where there are existing partners/community projects, I think they should:

1. Acknowledge the existing alternatives, and make it clear they've got a different use case in mind (this is, usually, the reason)
2. Link to those alternatives, and highlight situations where those alternatives are better
3. For all the effort they put into promoting their own product, put at least a small amount of effort into promoting the alternatives

Why it won't happen - my experience at Octopus Deploy

At Octopus Deploy, while we still integrate very well with Azure DevOps, we formally terminated our partnership with Microsoft in 2016 over issues that are similar.

Prior to 2016, Octopus Deploy was the only popular option for .NET developers to automate their application deployments, and we'd single-handedly helped thousands of dev teams to go beyond "right click, publish". In fact, at the time, Octopus Deploy was responsible for a large % of the largest Azure deployments that were happening.

Microsoft had acquired In Release previously, then turned it into Release Management, but were still charging a lot for it. In 2016 they made a bunch of changes:

• They rebuilt it and turned it into Azure Pipelines, and made it closer to Octopus functionality wise
• They bundled it into Visual Studio with the "right click, set up CI/CD pipeline" option (Octopus wasn't able to get into this)
• They changed the pricing model enough for most teams to assume it's free/included in their subscription
• They began promoting it very heavily

We suddenly found ourselves competing with a product from Microsoft that looked similar, that was being given away (perception, at least), that was integrated with VS, and that was being pushed in every Azure keynote. Overnight it became the default. We were exhibiting at Build 2016 at the time much of this was announced, and I remember people coming to our booth asking "so why should we use you over the Microsoft thing?". The "Microsoft thing" was announced only 5 minutes prior!

There were two conversations I had at Build 2016 that I think shed some light and informed my opinion here.

The first was with a product manager who worked on pipelines/release management. We talked about some integration ideas, but it didn't go anywhere. During the conversation we talked about some ways Octopus and Azure Pipelines differ - and it was clear this guy knew Octopus incredibly well . He described how channels in Octopus - an advanced feature that I'm not sure I even understand sometimes - relate to something in Azure pipelines. To know a feature like that so well, he's done his homework. I'd be incredibly surprised if people working on other products at Microsoft hadn't done their homework on the OSS alternatives.

The second was with someone who was senior within the overall TFS/Azure DevOps group that pipelines belongs to. He made it clear that TFS had its own P&L, and that people's career pathways would be tied to adoption of the products they work on, and so of course people wanted to see them succeed. If Octopus got in the way, even if that might overall be bad for Microsoft, it wasn't their problem.

So if Microsoft release a product that competes with an existing open source community project, I think there's two things you can assume:

1. It's unlikely they didn't do their research or weren't aware of the alternative.
2. If it's large in scale, they convinced their bosses to let them work on the project, and there's an expectation that it will gain adoption - either because it's directly tied to their bonuses/performance review, or just political capital. So there's very little reason for them to promote the alternative.

Which brings me back to Aaron's post: it's not going to work.

.NET OSS maintainers will struggle to build professionally supported OSS projects because Microsoft will immediately become the default (in the conversation, at least) in any market they enter, sapping any motivation for contributors to continue. Microsoft could balance that by promoting the alternatives, but that's very unlikely, because it's usually not in the interests of the teams involved.

There are exceptions to this like anything, but I think you see the long arc playing out. We've all seen the comic of Microsoft's org chart with the guns of each team facing each other. What's not obvious is that the .NET open source community exists within that structure too.

As I said, in 2016 we terminated the official "partnership" we had with Microsoft at the time. While a few Microsoft teams are still very friendly to us (and use Octopus), it was wierd. Azure feature teams loved us, and we built integrations with services like Service Fabric to help them with adoption. But overall it was clear that partnering with Microsoft was a waste of time, and a distraction.

(I'm informed that Octopus is still responsible for a huge % of Azure deployments, though nobody at Microsoft will tell me anymore. We've focussed on our customers and building a product they'll love. Explaining "why Octopus over Azure release pipelines" still grates, but I understand why, and we're getting better at it.)