10 ms·

Why We Terminated Our Partnership with Microsoft

169 points by gortok 7y ago

lostmsu 7y ago
But for me theirs is 10 times better as I don't have to install it anywhere and then maintain it myself.
- mikece 7y ago
  There is that... but Microsoft screws up their advantage by constantly changing their product names (VSO? VSTS? Azure DevOps? Why don't we just use GitHub... and what is HockeyApp's new name?) to the point of confusing the very market they are trying to serve.
  - cwbrandsma 7y ago
    Renaming stuff is just Microsoft's marketing department flexing. Don't ignore this history of bad names that group has created. ".net", WCF, WPF, Vista, etc.
    - mikece 7y ago
      I maintain that ".NET" is the single worst brand name to come out of Microsoft. I hope the new dotNet version 5 that is supposed to unify Standard and Core (or leave behind stuff like WebForms) gets a new brand name that doesn't have a period in it. Of course, knowing Microsoft they will recycle some name so even if it's better the Google Searches will be all screwed up, not knowing if it's the new Brand-X or the old one.
      - codysc 7y ago
        "Azure Dev Ops" is up there too. It turns out searching "Dev Ops" gives a lot of responses not relating to the product. Who could have possibly anticipated that? Side note, I like ADO. I just hate the name.
        mikece 7y ago
        I especially hate the name for the on-prem version. Boss: "Why the [bleep] did you guys put our code out in Azure?" Team: "No, it's on-prem -- TFS is now Azure DevOps." Boss: "Why didn't you tell me that Microsoft was forcing us to move our code to Azure from TFS?" etc....
        fernandotakai 7y ago
        microsoft cannot get naming right. and it's not only the azure team, everything microsoft is weirdly named. a good example? the new console is called "xbox one x series". why microsoft.
        SideburnsOfDoom 7y ago
        > It turns out searching "Dev Ops" gives a lot of responses not relating to the product. Good, "DevOps" is a philosophy of moving DEVelopement and OPerations together, operating in production, deploying and monitoring software, not merely a MS product. Arguably the monitoring and feedback part is more characteristic of "DevOps", because well, any software method that succeeds must involve deploys. And that's why it's an awful product name for a deploy toolset.
        WorldMaker 7y ago
        My favorite naming trouble with Azure DevOps is trying to troubleshoot a project-level issue in Repos or Boards for example and trying to filter out the mostly unrelated Azure DevOps Projects (the almost-but-not-quite CloudFormation-like tool) documentation.
    - jaywalk 7y ago
      We almost had Windows .NET Server. I don't know how the Windows Server 2003 name managed to win out, but the world was better for it.
  - flyingswift 7y ago
    Unfortunately, the org as a whole has completely collapsed as the result of the GitHub acquisition. I wouldn't be surprised to see ADO be deprecated in 2-3 years in favor of GH
    - delfinom 7y ago
      It's sad because GitHub is honestly a children's toy compared to ADO and GitLab in terms of large scale management of repos. GH shows no interest in fixing and improving long standing deficiencies.
      - strbean 7y ago
        Could you elaborate on these deficiencies?
    - ptx 7y ago
      I was confused for a moment there about how GitHub could be a replacement for Microsoft's ActiveX Data Objects.
mikece 7y ago
"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." 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. No, it's not "fair" but Microsoft isn't the only company doing this and it would be unfair to suggest they are doing this out of malice.
- wolco 7y ago
  Malice is a loaded term. 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.
  - CrazyStat 7y ago
    How would you suggest changing the rules?
    - paulryanrogers 7y ago
      Maybe companies with an overwhelming share of a market/platform are restricted from expanding into adjacent verticals.
      - CrazyStat 7y ago
thrwaway69 7y ago
I wonder what can you do to stop a big company from devouring your share in the SaaS market. What strategies are there? GitHub devour-ed a lot of tools built for it. Google do it with their search cards, amp and many other micro things. Apple does it with incredibly popular apps and integration. 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. 0] https://tech.co/news/eu-fine-qualcomm-2019-07 https://tech.co/news/eu-fine-qualcomm-2019-07
- mikece 7y ago
  It's not only a software thing; Amazon has been accused (or sued?) for anti-competitive behavior by creating "Amazon Essentials" version of lots of very popular items being sold through their site, even advertising the Amazon branded item right on the original product's detail page.
  - thrwaway69 7y ago
    Yeah. I think platforms should become neutral after certain adoption. It gives the company lot of unnecessary leverage. Apple can block off APIs to their apps only, google can do it, microsoft can do it, Amazon can (though they don't have as big of a share of online retail market but still enough).
    - tomnipotent 7y ago
      > become neutral after certain adoption No business should be required to let other businesses screw it over because "neutrality". There really is no such as a "neutral" when it comes to this anyway.
  - wbl 7y ago
    You have been to a grocery store and seen the store brands? Same thing.
    - 7y ago
Dinux 7y ago
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. 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?
- cc81 7y ago
  I don't think it is necessarily about being fair it is just that the philosophy of developers in the .NET world has always been if MS has something then that is the thing we use. I've felt that within Java there are usually more competing products and flavors. 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.
  - kevingadd 7y ago
    There are definitely cases where the community wins out because it delivers better quality - Newtonsoft.JSON eventually was recommended by MSDN documentation instead of the built-in .NET JSON APIs and the new in-development API is being written by the author of Newtonsoft.
    - cc81 7y ago
      That is true and that was a pretty big shift and together with embracing open source more, going all in on Azure, supporting Linux etc. there has been changes and that has reflected somewhat in the community as well. I also think people being used to npm in the frontend will make them more likely to start looking around nuget for things that can support their use case better than what exists by Microsoft.
noen 7y ago
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. 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. 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).
- csharptwdec19 7y ago
  Ehhh.... - 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.
  - cpascal 7y ago
    Their pricing is indeed extremely overpriced, particularly their self-hosted pricing. 10 targets - free 25 targets - $2300/year 50 targets - $4500/year 100 targets - $8800/year 200 targets - $16800/year 400 targets - $32000/year 500 targets - $39000/year . . . 5000 targets - $290000/year inf targets - $420000/year https://octopus.com/pricing/overview https://octopus.com/pricing/overview
    - ska 7y ago
      That's, erm, aggressive.
    - scarface74 7y ago
      Luckily, all of our "targets" are moving toward Lambda and Fargate (serverless Docker). We just have it to run CloudFormation templates for deployments. That pricing is ridiculous. I never realized it was that bad. On another note, Azure Devops has excellent support for AWS. It's better than Amazon's native solutions.
scarface74 7y ago
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 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. 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.
- GordonS 7y ago
  Octopus was popular in enterprise circles, but was far from the only way to deploy for .NET. TBH, the author makes himself look a bit silly by making this claim - the whole post comes across as "sour grapes" to me.
- paranoidrobot 7y ago
  > There were plenty of ways to automate deployments for .Net over a decade ago. 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.
zvrba 7y ago
From the linked (Aaron's) post: > .NET users need to culturally normalize the idea of adopting non-Microsoft .NET solutions when those third party technologies are better on the merits. 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. 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.
- reallydontask 7y ago
  I'm with you on this one. 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.
- tybit 7y ago
  I think to be fair even Microsoft doesn’t get this right consistently. 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).
  - zvrba 7y ago
    Yes, choosing EF Core is one of my biggest, if not THE biggest, regrets on the project I'm working on. Not because of the way it's packaged but because.. it's a heavy-weight ORM that stands in the way of using the database as a database. I want to write my queries in SQL and automatically map results to classes or even maps with correct types.
- Nullabillity 7y ago
  > Managing nuget packages can become hellish (looking at you Newtonsoft.Json) and MS at least takes some care with that. So.. MS wrote a horrible package manager, and the workaround is to use more MS products?
kaizendad 7y ago
I read this as "evil Microsoft Product Managers researched the market and understand the competition and if they decide to compete with you watch out because they will be evil folks who understand market needs deeply and are intimately familiar with competitors." 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.
gwbas1c 7y ago
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. 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. 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. 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.
- JMTQp8lwXL 7y ago
  These types of businesses shouldn't be taken past the concept stage. If the premise of your business is existing wholly on one other entity, it's a constant risk that'll never go away.
  - gwbas1c 7y ago
    I don't know if I'd be that blunt: Depending on the situation, a patent plus a buyout can be very profitable. That's one of the reasons why patents are useful, they encourage innovations on top of other peoples' products because you can use them to force the other party to pay you something when they try to copy your invention and undercut you. Makes me wonder why Autofac had no patents. Besides, there's nothing wrong with making a quick buck as long as you know it's a temporary situation.
smortaz 7y ago
Related: this guy rode through iran on 90cc bike and talks about his experience: https://youtu.be/_2LEgowbzSc https://youtu.be/_2LEgowbzSc
NicoJuicy 7y ago
> 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". Mmm, after research. I just used Jenkins at the time and I thought TeamCity was the other option.
- gortok 7y ago
  Having used all three, I was rather impressed by Octopus Deploy’s ease of use and deployment. You can set up Jenkins to do whatever you want but it’s a pain. You can also set up TeamCity to deploy, but again it’s a pain. Octopus Deploy is not a CI server, it’s a CD product. That’s Important. It specializes in deployment/delivery, and because of that it does better than Jenkins and TeamCity out of the box for deployments.
blt 7y ago
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. 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 will eventually try to replace the third-party tool with their own.
tybit 7y ago
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. 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?
devlife 7y ago
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. 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.

169 points by gortok 7y ago

lostmsu 7y ago

But for me theirs is 10 times better as I don't have to install it anywhere and then maintain it myself.

mikece 7y ago
There is that... but Microsoft screws up their advantage by constantly changing their product names (VSO? VSTS? Azure DevOps? Why don't we just use GitHub... and what is HockeyApp's new name?) to the point of confusing the very market they are trying to serve.
- cwbrandsma 7y ago
  Renaming stuff is just Microsoft's marketing department flexing. Don't ignore this history of bad names that group has created. ".net", WCF, WPF, Vista, etc.
  - mikece 7y ago
    I maintain that ".NET" is the single worst brand name to come out of Microsoft. I hope the new dotNet version 5 that is supposed to unify Standard and Core (or leave behind stuff like WebForms) gets a new brand name that doesn't have a period in it. Of course, knowing Microsoft they will recycle some name so even if it's better the Google Searches will be all screwed up, not knowing if it's the new Brand-X or the old one.
    - codysc 7y ago
      "Azure Dev Ops" is up there too. It turns out searching "Dev Ops" gives a lot of responses not relating to the product. Who could have possibly anticipated that? Side note, I like ADO. I just hate the name.
      - mikece 7y ago
        I especially hate the name for the on-prem version. Boss: "Why the [bleep] did you guys put our code out in Azure?" Team: "No, it's on-prem -- TFS is now Azure DevOps." Boss: "Why didn't you tell me that Microsoft was forcing us to move our code to Azure from TFS?" etc....
        fernandotakai 7y ago
        microsoft cannot get naming right. and it's not only the azure team, everything microsoft is weirdly named. a good example? the new console is called "xbox one x series". why microsoft.
      - SideburnsOfDoom 7y ago
        > It turns out searching "Dev Ops" gives a lot of responses not relating to the product. Good, "DevOps" is a philosophy of moving DEVelopement and OPerations together, operating in production, deploying and monitoring software, not merely a MS product. Arguably the monitoring and feedback part is more characteristic of "DevOps", because well, any software method that succeeds must involve deploys. And that's why it's an awful product name for a deploy toolset.
      - WorldMaker 7y ago
        My favorite naming trouble with Azure DevOps is trying to troubleshoot a project-level issue in Repos or Boards for example and trying to filter out the mostly unrelated Azure DevOps Projects (the almost-but-not-quite CloudFormation-like tool) documentation.
  - jaywalk 7y ago
    We almost had Windows .NET Server. I don't know how the Windows Server 2003 name managed to win out, but the world was better for it.
- flyingswift 7y ago
  Unfortunately, the org as a whole has completely collapsed as the result of the GitHub acquisition. I wouldn't be surprised to see ADO be deprecated in 2-3 years in favor of GH
  - delfinom 7y ago
    It's sad because GitHub is honestly a children's toy compared to ADO and GitLab in terms of large scale management of repos. GH shows no interest in fixing and improving long standing deficiencies.
    - strbean 7y ago
      Could you elaborate on these deficiencies?
  - ptx 7y ago
    I was confused for a moment there about how GitHub could be a replacement for Microsoft's ActiveX Data Objects.

mikece 7y ago

"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." 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. No, it's not "fair" but Microsoft isn't the only company doing this and it would be unfair to suggest they are doing this out of malice.

wolco 7y ago
Malice is a loaded term. 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.
- CrazyStat 7y ago
  How would you suggest changing the rules?
  - paulryanrogers 7y ago
    Maybe companies with an overwhelming share of a market/platform are restricted from expanding into adjacent verticals.
    - CrazyStat 7y ago

thrwaway69 7y ago

I wonder what can you do to stop a big company from devouring your share in the SaaS market. What strategies are there? GitHub devour-ed a lot of tools built for it. Google do it with their search cards, amp and many other micro things. Apple does it with incredibly popular apps and integration. 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. 0] https://tech.co/news/eu-fine-qualcomm-2019-07 https://tech.co/news/eu-fine-qualcomm-2019-07

mikece 7y ago
It's not only a software thing; Amazon has been accused (or sued?) for anti-competitive behavior by creating "Amazon Essentials" version of lots of very popular items being sold through their site, even advertising the Amazon branded item right on the original product's detail page.
- thrwaway69 7y ago
  Yeah. I think platforms should become neutral after certain adoption. It gives the company lot of unnecessary leverage. Apple can block off APIs to their apps only, google can do it, microsoft can do it, Amazon can (though they don't have as big of a share of online retail market but still enough).
  - tomnipotent 7y ago
    > become neutral after certain adoption No business should be required to let other businesses screw it over because "neutrality". There really is no such as a "neutral" when it comes to this anyway.
- wbl 7y ago
  You have been to a grocery store and seen the store brands? Same thing.
  - 7y ago

Dinux 7y ago

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. 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?

cc81 7y ago
I don't think it is necessarily about being fair it is just that the philosophy of developers in the .NET world has always been if MS has something then that is the thing we use. I've felt that within Java there are usually more competing products and flavors. 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.
- kevingadd 7y ago
  There are definitely cases where the community wins out because it delivers better quality - Newtonsoft.JSON eventually was recommended by MSDN documentation instead of the built-in .NET JSON APIs and the new in-development API is being written by the author of Newtonsoft.
  - cc81 7y ago
    That is true and that was a pretty big shift and together with embracing open source more, going all in on Azure, supporting Linux etc. there has been changes and that has reflected somewhat in the community as well. I also think people being used to npm in the frontend will make them more likely to start looking around nuget for things that can support their use case better than what exists by Microsoft.

noen 7y ago

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. 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. 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).

csharptwdec19 7y ago
Ehhh.... - 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.
- cpascal 7y ago
  Their pricing is indeed extremely overpriced, particularly their self-hosted pricing. 10 targets - free 25 targets - $2300/year 50 targets - $4500/year 100 targets - $8800/year 200 targets - $16800/year 400 targets - $32000/year 500 targets - $39000/year . . . 5000 targets - $290000/year inf targets - $420000/year https://octopus.com/pricing/overview https://octopus.com/pricing/overview
  - ska 7y ago
    That's, erm, aggressive.
  - scarface74 7y ago
    Luckily, all of our "targets" are moving toward Lambda and Fargate (serverless Docker). We just have it to run CloudFormation templates for deployments. That pricing is ridiculous. I never realized it was that bad. On another note, Azure Devops has excellent support for AWS. It's better than Amazon's native solutions.

scarface74 7y ago

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 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. 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.

GordonS 7y ago
Octopus was popular in enterprise circles, but was far from the only way to deploy for .NET. TBH, the author makes himself look a bit silly by making this claim - the whole post comes across as "sour grapes" to me.
paranoidrobot 7y ago
> There were plenty of ways to automate deployments for .Net over a decade ago. 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.

zvrba 7y ago

From the linked (Aaron's) post: > .NET users need to culturally normalize the idea of adopting non-Microsoft .NET solutions when those third party technologies are better on the merits. 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. 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.

reallydontask 7y ago
I'm with you on this one. 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.
tybit 7y ago
I think to be fair even Microsoft doesn’t get this right consistently. 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).
- zvrba 7y ago
  Yes, choosing EF Core is one of my biggest, if not THE biggest, regrets on the project I'm working on. Not because of the way it's packaged but because.. it's a heavy-weight ORM that stands in the way of using the database as a database. I want to write my queries in SQL and automatically map results to classes or even maps with correct types.
Nullabillity 7y ago
> Managing nuget packages can become hellish (looking at you Newtonsoft.Json) and MS at least takes some care with that. So.. MS wrote a horrible package manager, and the workaround is to use more MS products?

kaizendad 7y ago

I read this as "evil Microsoft Product Managers researched the market and understand the competition and if they decide to compete with you watch out because they will be evil folks who understand market needs deeply and are intimately familiar with competitors." 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.

gwbas1c 7y ago

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. 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. 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. 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.

JMTQp8lwXL 7y ago
These types of businesses shouldn't be taken past the concept stage. If the premise of your business is existing wholly on one other entity, it's a constant risk that'll never go away.
- gwbas1c 7y ago
  I don't know if I'd be that blunt: Depending on the situation, a patent plus a buyout can be very profitable. That's one of the reasons why patents are useful, they encourage innovations on top of other peoples' products because you can use them to force the other party to pay you something when they try to copy your invention and undercut you. Makes me wonder why Autofac had no patents. Besides, there's nothing wrong with making a quick buck as long as you know it's a temporary situation.

smortaz 7y ago

Related: this guy rode through iran on 90cc bike and talks about his experience: https://youtu.be/_2LEgowbzSc https://youtu.be/_2LEgowbzSc

NicoJuicy 7y ago

> 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". Mmm, after research. I just used Jenkins at the time and I thought TeamCity was the other option.

gortok 7y ago
Having used all three, I was rather impressed by Octopus Deploy’s ease of use and deployment. You can set up Jenkins to do whatever you want but it’s a pain. You can also set up TeamCity to deploy, but again it’s a pain. Octopus Deploy is not a CI server, it’s a CD product. That’s Important. It specializes in deployment/delivery, and because of that it does better than Jenkins and TeamCity out of the box for deployments.

blt 7y ago

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. 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 will eventually try to replace the third-party tool with their own.

tybit 7y ago

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. 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?

devlife 7y ago

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. 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.