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).
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.
They're not exploiting the model to charge money for it.
I know Octopus Deploy uses proprietary code.
But if you're going to complain about the model, at least know what the model is. It's not about the amount of money you must pay to obtain a copy.
That's why they asked "How much of that money does the OSS see?"
If it's getting a significant chunk, then things are great.
If all the money is going to the proprietary part, then they have no high ground over Microsoft.
Nobody is complaining about money charged for OSS support and development.
- 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.
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
On another note, Azure Devops has excellent support for AWS. It's better than Amazon's native solutions.
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?
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.
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.
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.
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.
Edit: Removing "amusing"
A more correct analogy would be that team with overall lower salaries can cheat, or otherwise get advantages during the game not afforded to the team with more money.
Sports have salary caps and governments have anti-trust. Once companies become defacto governments it's reasonable for regulation to step in to level the field.
Defining "adjacent verticals" also seems super tricky and open to abuse.
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.
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.
This is the earliest article I could find about using TFS for deployments from 2010.
Don’t get me wrong, while for the most part, I hate dealing with “pets” and I was hired partially to kill all the servers we could and go all in on AWS’s native hosted toolings, Octopus Deploy is a joy to use even just to deploy CloudFormation templates where the actually code is either in S3 (lambda) or ECR (Docker) not to mention deploying to our remaining pets.
Just the ability to use Octopus Deploy’s library sets that are scoped to environments that can be referenced in Config files and templates is worth paying for.
On the other hand, I am on a mission to kill Jenkins and replace it with AWS CodeBuild - Serverles builds using a Docker Containers.
> .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.
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).
I want to write my queries in SQL and automatically map results to classes or even maps with correct types.
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.
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  for above. It doesn't seem to happen with SaaS.
- 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.
For system products that would be:
1) Build on Kubernetes. This is the only true open ecosystem.
2) Go Multicloud. Always support at least three clouds.
3) Make the edge your primary target.
That is probably fine in this case but what reason is there for them to not lose money to control other parts of the market?
Facebook brought whatsapp, mind you and many others.
Tech is accessible everywhere. What it does is set certain expectations for users in different countries. In india, most people won't pay for apps and they are not profitable to run many services which big companies do for free.
Maybe it's good in the short term. For consumers, certainly but I wonder if tech will become stagnated like other industries with monopolistic control.
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.
Make a product that seamlessly integrates with the rest of their ecosystem so they're more likely to acquire you than replace you.
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.
If you get squashed by virtue of clout then competition gets eliminated.
If get bought out to avoid getting squashed then potential competition gets eliminated.
Or you don't bother to compete and there's no competition to begin with.
From the US constitution:
> To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries.
You could argue the monopoly grant is purely intended as an incentive to publish. I think the accepted interpretation is that it is intended as an incentive to invent as well as publish those inventions.
IMHO the merits of that logic are open to debate though. Not a big fan of IP myself.
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.
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.
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.
Side note, I like ADO. I just hate the name.
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?"
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.
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.
Mmm, after research. I just used Jenkins at the time and I thought TeamCity was the other option.
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.
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?