Why We Terminated Our Partnership with Microsoft

I lost interest in the author’s argument at that point. They’re upset because someone is going to give a better offer than half a mil a year for the same product. And they’re saying, “think of the OSS!” The same OSS they’re exploiting to charge half a mil. How much of that money does the OSS see? Do they get proper support and maintenance?

Azure is a formidable competitor but a slow moving beast. They should be well geared towards innovation and not depending on their... yes... half a mil price tier. The fact that’s written on paper and not a dedicated sales/VP call is crazy.

It sounds like they need to find something unique. Since every cloud provider is moving this direction.

- Octopus Deploy, for the record, is awesome. But it became extremely overpriced in 2018, to the point I wouldn't reccomend it.

- OTOH, I will point out that since the various Release management bits were tossed out by Microsoft, it seems like that's around when FAKE's deployment module started getting ignored. For Ref, FAKE is an OSS Build tool (like MAKE but F# DSL). It used to have a pretty slick remote deployment module, but around 2016-2017 or so they decided there were too many other options out there to be worth continuing development on.

Often the product MS provides is good enough but I remember in the tail end of the web forms disaster there were some good open source MVC libraries inspired by the Java ecosystem but they never really got traction and people kept building things with shitty web forms. This is until MS came with ASP.NET MVC and people started to switch.

I don't think Microsoft wants to kill alternatives. I think they really want a healthy ecosystem to get more developers using .NET but they also want to be able to create a complete developer experience and that sometimes clashes and kills other products due to the culture.

When Amazon tells you they want to buy you, never sign and come out with a competing product months later we feel malice.

But in this case we don't becauce Microsoft copied an existing product and open source it we say no malice exists.

Big companies are copying smaller successful products on mass. It is not illegal, it's not out of malice. But its getting tiresome. How many products can facebook buy or copy and crush before we change the rules. Avoiding this was one of the pillars of copyright long ago. Now we have copyright for and copying trade secret powered development for big players.

There's a difference between just pure "automate deployments" and what Octopus does.

While sure there's been tools like NAnt around forever, back when Octopus came out* there wasn't a good easy to use workflow tool for deployment orchestration.

Sure, you could use TeamCity/Bamboo/TFS to deploy your code, but it was really focussed on the CI side of things, and the process of building a pipeline was often quite a pain to manage, with them not really understanding 'environments'.

You could, and in many cases often did - tell your CI system to deploy direct to a dev/staging environment - but it really wasn't intended for production environments. If you wanted to orchestrate deploying to more than one machine, it was a pain, and doing even tens of machines required that you built a ton of tooling to do this.

Octopus comes along and gives us the ability to:

- Define environments (ci, dev, staging, preprod, production, etc) - Define a common deployment workflow, with branching/conditionals based on the environment/machine - Define a release workflow, for how a release needed to progress through environments (eg: a release MUST pass deployment on a preprod environment before it can be deployed to production) - Define a release which comprises one or more artifacts (particularly useful if you have multiple parts to your applications - such as a website as well as a service) - Give a good overview of what's deployed where. - Easily roll back a release for an environment - just pick up the previous good release, and re-deploy it to that environment.

While sure I could have achieved all of that, the reality was that few people would put all the effort in to building it themselves, AND making it reliable.

* = I recall Stovell talking/writing that the whole reason he built Octopus in the first place was because he kept running into the same issues over and over when he was at a consulting firm. There just wasn't any tooling, free or commercial, that would do these things nicely.

I will say though that the issue I find is that sometimes this can lead to convoluted code

Picture this scenario:

Start using MS package and all is good

One day a new requirement comes in that the package just can't handle so you code around it.

Turns out that an open source package did what you wanted all along in a much neater way.

This has happened to me a few times that I'm aware of, no doubt countless others where I'm not aware of it.

Many non-MS OSS packages / libraries only have like 1 or 2 maintainers. If they no longer have time for it, or, god forbit, get ill/life happens, then you've got a dead dependency. I never discriminate against a well-supported OSS package in favour of a Microsoft one.

So.. MS wrote a horrible package manager, and the workaround is to use more MS products?

For example EF, particularly EF Core has been a nightmare IME. Whereas Dapper has consistently delivered over time (props to StackOverflow for their awesome and consistent OSS contributions).

- Stay under the radar.

- Change your product into a product that threatens their core business model. (for example against facebook you would offer privacy because they could not offer that without weaking their core tracking you/selling ads business)

- You offer something that bridges two other companies. Think plug-in that pulls from all major crmes.

- You offer something grey market.

- You compete head to head with a better product.

Never let one of these big companies pretend to buy you while they delay and steal your ideas either.

Make a product that seamlessly integrates with the rest of their ecosystem so they're more likely to acquire you than replace you.

Two things:

1) As the other poster said, make your product so compelling that the behemoth company simply acquires you.

2) Try hard to make sure you're not competing against them, nor will they decide to compete against you in the future.

So either do such a great job you get bought out (which will probably be a negative in the long term for your users, but financially it should be a huge win for you), or just don't bother, and find something else to do that doesn't compete with a huge tech company.