The whole article paints a picture of Microsoft eating OSS OSS projects, but the author begins by clearly stating that the project he is going to reference (Octopus Deploy) is not OSS.<p>Instead, he is complaining that Microsoft is competing with his own proprietary, commercial offering. I'm not sure why he keeps pushing the narrative that this is bad for OSS, when the only two projects mentioned aren't.<p>Full Disclosure - I worked in the Azure DevOps org for a long time, and several of his assertions about Microsoft's auto-defacto status for developer tools and services aren't true, or at least weren't true during the time this article was set in (2010-2015).
I don't agree with the article at all. The point the author is making has less to do with OSS and more with competition. Business is never 'fair'. The reason people flock to AWS/Azure is because of ease of use, integration with other systems etc.. The burden of maintaining two (or more) ecosystems just because one is 'a little better' isn't worth it. Sure there will always be an alternative that fits the product/team better.<p>Besides, MS and alike have thousands of products and services. Are they supposed to point to every-other-alternative out there before they enter the market?
"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."<p>I can see why you would be upset but what obligation does Microsoft have to do that? One reason CIOs will go with Microsoft solutions lock-stock-and-barrel is that it's there's one account rep, one consolidated bill, one "throat to choke" if there's a support need. The alternative would be to deepen your partnership to the point that something like Octopus becomes a de facto Microsoft product (complete with bundled support when you go with .NET/Azure/etc). Either that or go out of your way to show why DevOps managers never get fired for choosing Octopus.<p>No, it's not "fair" but Microsoft isn't the only company doing this and it <i>would</i> be unfair to suggest they are doing this out of malice.
<i>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.</i><p>I had never heard of Octopus Deploy until 2018. There were plenty of ways to automate deployments for .Net over a decade ago. In fact, Azure Devops is basically TFS online that has been around forever.<p>This is like the company that said Apple “stole” their idea of using an iPad for a second screen for a Mac even though other options existed since 2010.
From the linked (Aaron's) post:<p>> .NET users need to culturally normalize the idea of adopting non-Microsoft .NET solutions when those third party technologies are better on the merits.<p>I'm a .NET developer and say: no. If Microsoft's solution satisfies my needs, I won't adopt a 3rd-party solution, especially if it has other nuget dependencies. Managing nuget packages can become hellish (looking at you Newtonsoft.Json) and MS at least takes some care with that.<p>I'm icky about adding dependencies and by using MS's solutions I can be relatively sure that they won't depend on latest shiny OSS package that could become a liability in the future.
I read this as "evil Microsoft Product Managers <i>researched the market</i> and <i>understand the competition</i> and if they decide to compete with you watch out because they will be evil folks who <i>understand market needs deeply</i> and <i>are intimately familiar with competitors</i>."<p>I mean, I get that's hard to compete with for a smaller company or an less-formal org, like those who maintain many OSS projects, but that's just... being a good product manager. If you don't like that, hire a Product Manager and get those skills yourself.
I wonder what can you do to stop a big company from devouring your share in the SaaS market. What strategies are there?<p>GitHub devour-ed a lot of tools built for it.<p>Google do it with their search cards, amp and many other micro things.<p>Apple does it with incredibly popular apps and integration.<p>Every big company in short do it and they all have big pockets to lose money on the software until competition is sucked out. Unlike hardware, where you will be pressed with anti-competitive charges [0] for above. It doesn't seem to happen with SaaS.<p>0] <a href="https://tech.co/news/eu-fine-qualcomm-2019-07" rel="nofollow">https://tech.co/news/eu-fine-qualcomm-2019-07</a>
Large business with deep pockets has a product with a deficiency. Small entrepreneur sees a need and develops a bolt-on improvement that fixes the deficiency. Large business also sees the deficiency and fixes it.<p>I just don't understand the article's mentality. The only way Microsoft "owes" the small entrepreneur anything is if that entrepreneur had patents or other IP that Microsoft violated; or if the two companies had some kind of non-compete agreement.<p>It seems like, in this situation, the options are to pursue acquisition, have IP (like patents), or figure out how to carve out a niche and compete.<p>IMO: The "bolt-on product to fix something wrong with someone else's product" business model appears short lived and requires a rather early exit strategy.
It looks like you wanted to do OSS but you soon realised that there is potentially good money to be made in commercial software. Your company also spent all the years building a good product but the money bug bit you and you started charging exorbitant prices. The greed kicked in. And now you are whinging because MS came and ate your cake.<p>Please don't get me wrong on this, making money is the reason why we live in a world which has all these amazing things. But it is a jungle and survival matters here.
> 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".<p>Mmm, after research. I just used Jenkins at the time and I thought TeamCity was the other option.
I find it kind of confusing that anyone attempts to make money building developer tools for MS platforms. The behavior described here is MS's standard operating procedure. Their goal is to control everything. They want to provide a fully integrated MS software development platform that's slightly easier to use than open source, supports legacy code, and comes with legacy users.<p>If there is ever an opportunity for building a tool that augments / integrates with the MS platform, that opportunity only exists because MS either 1) lacks the vision, or 2) has not chosen to place engineers on that idea. It is a transient condition. If the idea is worth a lot of money, MS <i>will</i> eventually try to replace the third-party tool with their own.
As soon as Azure became critical to Microsoft’s success they should of seen this coming, it would be unacceptable for any large cloud vendor to not offer a first party deployment service.<p>Having said that when I last used Octopus a few years ago in a pets VM world it was an excellent experience. Does anyone know if they’ve managed to keep up this quality for containers/serverless/immutable VMs?
Related: this guy rode through iran on 90cc bike and talks about his experience:<p><a href="https://youtu.be/_2LEgowbzSc" rel="nofollow">https://youtu.be/_2LEgowbzSc</a>