It is not just that AWS, Azure etc. are eating your lunch, it is that the big enterprise customers are actively asking them to eat your lunch. Enterprise customers hate dealing with multiple vendors and they are always looking to reduce the number of vendors and legal agreements they have --- so they encourage the bigcos to deliver more services.
I have been in meetings where I was asked to explain why we can't just use AWS Redis instead on using RedisLabs. Since I was a big fan of Redis , I had to painstakingly explain with cost projections of the implications of using AWS services for this solution.
In a large enterprise, you have to be really passnionate about a new technology to get it approved through a series of excrutiatingly long review process while also working on your assigned projects. Nobody will mind or question your decision if you choose to use MS SQL or Oracle for KV stores because they are corporate standards. Presenting a new technology like Redis requires one to prepare documents for backup, failover , load balancing, support,iniciden management process anlong with a slew of security related reviews. Did I mention that all this while you are also responsible for staying on to of your JIRA tasks ? And even if you do get this technology certified, it means almost nothing on your bonus or yearly review.
So yes .. one has to be a "fan" to push new techologies or vendors like RedisLabs in the enterprise. And yes, the process will make you a tad annoyed.
That seems...sensible. When you start using a new product there's a lot of hidden costs associated with it (backup, failover, load balancing, support, incident management) so you need to take the time to explain why the benefits of that shiny new thing outweigh the costs of all that other stuff.
I can’t understate this enough. A client will often go with a platform solution that is 80% of what they need than the bespoke one simply because it avoids 3-6 months of procurement delay. Even if you develop a novel infrastructure technology, AWS’ implementation will be better in the eyes of a corporation because it comes from AWS.
You’re right; these platform services are often more expensive — but the critical thing is that the company gets a management benefit from this in that their existing tool stack around things like IaC or CI/CD will mostly just work. They can easily use the security standards and setup they already have without having to run the solution through a full security review or build a bunch of tooling around a third-party product.
The only exception to this is when we’re talking about revenue-generating activity driven by the business. Often differentiating tech is needed there, but it’s also the same situation with platforms like SAP and Salesforce sucking most of the oxygen out of the room. But infrastructure is a particularly bad place to be as a software vendor right now; even the “success stories” like Snowflake are running into headwinds competing with platform services.
TLDR: time to market is the main reason pushing people to platform services. This is making it increasingly difficult for ISVs / SaaS — even large ones — to make inroads to displace their competition.
There's also the "Nobody gets fired for buying IBM" principle at work here. AWS is a safe choice that no one will question you on later, even if it's not the right choice or the best one.
This kind of problem is not going to be solved by clever licensing or whatever.
Yes, it is open source, not free software, so you can prohibit people from making money by hosting it and selling it as a service, but this is not ideal, because sometimes you want this to happen.
The problem is when a oligopolistic entity does that, because by their sheer power it means you will be squeezed out of the very market your product created.
Monopolies and oligopolies, by definition, are market failures, they can't be fixed by the market, they require government intervention.
The only sustainable, long term solution for that is to mobilize politically for a government that have a more activist role in fighting market concentration and abuse.
That was nearly two years ago. A lot of effort has taken place since then to scrutinize the big clouds. I don't know if it's enough, and I'm not taking either side, but the situation isn't going unnoticed.
It has little to do with monopolies and oligopolies.
Suppose AWS, Azure, GCP, and all the other large cloud providers were split up into 10 providers each. So now we have several dozen cloud providers, all much smaller than when it has only a handful.
They would still almost all be much bigger and offering a much wider range of products than a small company that has on product--a DB, a messaging service, a cache, etc--that is useful to cloud providers and cloud provider customers.
Those dozens of providers will still find that the small companies product is a compliment to the cloud provider's products and services, and it will still make sense for the cloud providers to offer that service themselves to make it so they are a one stop source for as many of their customers cloud needs as possible.
Agreed. This is an anti-trust issue, not a strategy problem for small businesseses to figure out a solution to. What's the solution? The same one used on Standard Oil.
From the cloud provider perspective, number 7 is by far the most important but the article really under-sells it.
Cloud providers don't hunt around for SaaS products to rip off; they are approached by customers who are unhappy with the status quo. There could be any number of things the customer dislikes about your VC-floated company - pricing structure, dealing with your sales people, risk of you getting bought by another cloud provider and taken off the market, etc.
Don't blame big companies when your value proposition is wafer thin and your customers are required to be fellow tech bros in order to want to deal with you.
This is the sad truth about open source software - if you have a good product, giving others access to the core software often means you can develop a community that will help you develop and create a company around it. But a large company will often be able to produce a more commercially version - cheaper, better support, wider availability, integration with other services etc.
No, the mistake is trying to make money from open source in the first place. That's. Not. The. Point.
Paying for developers to work on some open source project that you rely on, absolutely, great idea. But trying to monetize an open source project itself is myopic - obviously the solution if you want to do that is to make the project not open source as you say.
This isn't a problem with open source software, it's a feature and it's part of why it's so ubiquitous - no one company pulling the reigns who can fuck it up.
> No, the mistake is trying to make money from open source in the first place. That's. Not. The. Point.
But the point is people are trying to make a living using their software development skills, not specifically make money from open source. As part of that the question is should they release their code as open source or keep it closed.
But their point is not "you should make money from open source", but "open sourcing your code makes it easier for corporations to eat your lunch with a closed source solution, so you need to be able to compete, which requires money."
Someone who wants new software to be developed that doesn't exist yet. (Or improvements to existing software that don't exist yet).
Developer/Designer/QA/PM/Whatever time is the thing that actually has meaningful cost here, not the act of sending bits across a wire. So that's the thing that the market should be paying for.
The difference with proprietary software is just that you can get people to pay for those man hours after release time - in OSS you don't have that luxury, and pretending that you do, or that you're actually fundamentally charging for something else is a mistake.
Get a job then. Open Source is for people who want to have their cake (be their own employer / business owner) and eat it too (not actively compete in the market, just ask people to pay for their work since they are doing a service to the community).
Then they shouldn’t get shocked when it works against them. If you are releasing open source (especially under permissive licenses) you are relinquishing your rights - so do it from a view that its charity to the world, but don’t expect to get all the compliments for doing OSS work but also _expect_ market rates for the work you did. No one agreed to pay you for it, no one agreed to pay you royalties for using your product in theirs and so forth.
I have a very nice one doing enterprise consulting, and for what I care we could be back at PD and Shareware, which is what killing GPL will do anyway.
The thing is, if these big corps wanted they could just re-implement the whole product with the same API so it doesn't matter if your product is open source or closed source. The only thing that matters is if they find it worth the hassle.
I'm starting to think "source available" or extreme AGPL is the only way to compete with the likes of the famgopolies.
If you open source, anyone can use your code. In the previous world this was good. In the new monopoly world, the giants clone your product, make it a paid feature, and outcompete you. You'll be out of business with nothing to show for it.
Famgopolies shouldn't be allowed to access open source unless they open source their entire stack.
Searching google for the definition of "famgopoly" leads back to your previous HN comments on various aggregators, and nothing else.
I like that you're single handedly trying to make this word happen against the crushing weight of social inertia and multibillion PR departments. It feels very appropriate for the topic.
Have you been able to piece together a definition for the word? I've yet to be able to tell from context what it means (it's a portmanteau of "monopoly" and "FAANG" I think? But is it supposed to mean all of those companies, individually, are operating as monopolies and should be broken up, or that those companies collectively form a cartel and should be banned from operating as such, or some third meaning I have yet to identify?)
I think InfluxDB has a license that prevents anyone from offering influxdb as a saas on their platform. You can deliver it part of a product but it cannot just be influxdb.
Technically I'm sure that's true, but the number of acquisitions of small software startups the giants make for large amounts of money suggest that they don't view the process of cloning a product as easy.
Cloning a product requires you to clone the API bug-for-bug an locks you in architecture-wise quite a bit, since your interface must be similar. This requires you to solve problems the same way the original software did, but doing so similarily well might not be easy. Also, this takes time.
Then, once you cloned the software, you still need to convince the customer base to switch.
It's far easier to simply write a check and get code, talent and customers at once without delay.
Two years later I’m living out this scenario again. I’m at a startup with competition looming from AWS and Google. Even the slack anecdote played out almost the same way. I’m sticking to this playbook.
You can also focus upon a specific niche and dig in.
The big cloud vendors are looking for products with mass appeal or that they think will have mass appeal.
So if you are building for with a business plan that calls for a hundred of thousands of users and more as fast as possible, you will quickly come up on the radar of the cloud providers (and others).
If you find a niche to be in, you probably won't be a unicorn in 5 years, or ever, but there is good money to be made and successful businesses to create. (Not nearly as sexy)
Of course, you can still get ripped off by a company wanting to be in the same space, usually, but not always, this becomes a fight between two companies of non FAANG status, so competition is a bit fairer.
It really help to hire domain experts in your niche.
They dont have to be technical at all.
Just have long experience with the business domain adn
be able to talk to executives and be taken seriously.
Coming in as a "hot startup" is in my experience not impressive to potential clients.
I worked for one company who did all this and they are still going strong making good money. Often in this space you can charge a lot of licenses.
I started my own several years ago and we outcompeted the legacy offering. Our biggest problem was that clients were locked into multiyear contracts with the competition, so conversion, even if interested was high, took time.
The one about multi-cloud support is a valid point, I can remember quite a few times when companies I worked at chose products with multi-cloud support in order to avoid vendor lock-in.
Regarding being careful about open sourcing: it is truly unfortunate that that is the case, but I can see the point that the author is making.
surely this is very likely.
the way Amazon did with retail: look at high-demand items and then make AmazonBasics version of those and kill those brands.
similar might happen with other businesses that use AWS, Azure, GCP clouds.
also they have your data with them, for 'test driving' their products.
reminds me of "the cloud is just somebody else's computer"
>I advise companies to guard their product and not go open-source, or to limit their vulnerability if they already open-sourced, as Confluent did by changing their licensing when AWS pulled the same maneuver with Kafka, the open-source software from Confluent.
If you were building a product from scratch today, what business model would you choose? (Assume we're building horizontal infrastructure software, like Pinecone, and we'll offer a SaaS option.) a) Open source SSPL, b) Closed source commercial license for offsite use, c) Just straight SaaS.
Such is the world without patent protection. Once they grew large, these behemoths sent their lobbyists to Washington and quashed the patent system. They cried "patents are bad" and the brainwashed masses, including the readers of Hacker News, eagerly agreed.
I anticipate this being downvoted by people who aren't aware of the nuance of the idea here (although, to be fair, that's because the nuance wasn't properly explained), so I'm going to explain it:
Patents allow smaller inventors a monopoly on their inventions. Without this monopoly, then because of their massive amounts of capital and engineering talent, massive megacorps/conglomerates are able to easily copy (even if imperfectly) most things that you might want to invent, with little recourse from the inventors.
(yes, behemoth organizations can still get patents - that's often still a better trade for a smaller inventor)
...that said, I'm still not convinced that software patents are a good idea.
In theory patterns would protect the small innovative inventors - but in reality software patterns are used like nuclear weapons - to frighten anyone to not sue - or you would be sued back with a bunch of pattern like round corners, comments in source code, a program that can accept connections, etc...
We however have copyright. So the big companies can't just copy your software and sell it as is... unless you open source it using a MIT licence, then they will copy it, make some closed source changes and compete with you.
Scylla [1] is a cloud key / value store competing directly with DynamoDB. They have an interface identical to DDB to make transitioning easier [2]. They outperform DDB for many tasks, and have many added features.
My point is this often is AWS, Azure, GCP vs. start-up, but there are counter examples.
I played around with OCI this weekend , and it is good too. Offering more than others for free, maybe because they are lagging behind. DB side they are powerful than competitors.
My 2 cents no point in reinventing the wheel. Instead use infrastructure to create something disruptive as they say it ( wonderful was sounding a bit lame :) ), spending money will automatically mean commercial software. At a quality worth spending money on.
Open source has its own charm, you are aiming for fame than money I guess ? Collaboration with strangers - keep your mind and heart open to new ideas and that can burn out software developers like us. Where we intent on creating something with a strong will, to learn something ( rust is a b**h ).
There are companies such as Sentry which switched preemptively to time limited BSL licenses ( code available, but the license prohibits certain types of use that might come into competition with the publisher), and 2 years old code is under the MIT license. IMHO a decent balance, and Sentry seem to be doing well, without competition based on their code, but idk if they can be considered successful.
Grafana Labs recently switched to AGPL for all their software.
There are others such as Redis, Elastic and Confluent which switched to more restrictive licenses after managed versions of their software appeared on Bug Clouds, and they're still around.
I think the article is less about grafana/elastic/mongo type scenario and more about closed source SaaS.
We were in the "other side" of this situation a couple of years ago in a previous startup: We were almost ready to sign with DataRobot what we thought was a shitty deal. We were a pretty established FinTech with a good DataScience team looking for ways to streamline our ML process. DataRobot was a good option but the terms were super crappy, and the "aura" of the company was like "though luck if you don't like it". Just about 1 week before we were going to sign, AWS released their ML engine SageMaker with the typical "pay as you go" billing. We lucked out and went with that. Not sure what datarobot is doing now but SM deffinitely cost them a sale.
I have been in meetings where I was asked to explain why we can't just use AWS Redis instead on using RedisLabs. Since I was a big fan of Redis , I had to painstakingly explain with cost projections of the implications of using AWS services for this solution.