Hacker News new | ask | show | jobs
by jimmychangas 2714 days ago
> there's no intrinsic reason that the same company that gives away labour as OSS should also make the best complements to that OSS

There are no guarantees that they will provide the best complements to their own product, but the common sense is that they will. From a marketing perspective, I think it makes complete sense, especially when selling to enterprise customers.

1 comments

But they don’t.

The best complement for server side software is often being able to do it reliably, globally, redundantly, managed, on demand, and cheaply. The only three companies that can do that reliably as far as most customers are concerned are Amazon, Microsoft, and Google.

I agree, I think Docker is an example on how to almost completely fail to take advantage of being first to market. Redhat, AWS, Google and others were quicker to monetize on docker (the runtime) than Docker the company.
Docker are actually an example of a pattern, one that also impacts MongoDB and many other companies. That pattern is that they intentionally branded the product and the project with the same name (in this case Docker) to help with slipstreaming on the community mindshare they were building.

The flip side of that which eventually comes home to roost though is that it means the two are easily confused . If I'm a customer and I can download X or buy X from you, and the two are virtually identical, you better have a damn good story as to what your value proposition over and above the project is.

Red Hat actually arguably only just got themselves out of this. Originally there was just Red Hat Linux, regardless of whether you paid them a cent. The split into Fedora (Core) - the free distribution - and RHEL - the enterprise distribution with paid support subscriptions - is a not insignificant part of why the company still exists today. This transition was not without controversy, and arguably created the space into which Canonical and Ubuntu emerged, but it was a necessary step to disambiguate the project and the thing people actually pay for with its own value prop and messaging around it.

It's somewhat surprising that so many of these companies proclaim they want to be the next Red Hat, but ignore the prior art for how that came to be.

I don't see anything Mongo could have done differently. Even if Mongo were completely proprietary software, it wouldn't have affected AWS. They didn't use Mongo's code just emulated their API. That's basically the same thing that kicked off the entire PC industry -- clean room cloning BIOS.
Emulating a propietary API would open up the door to litigation with uncertain outcome, generating distrust and bad press for Amazon. So not the same.
This has already been settled in the courts: APIs are not subject to copyright and may be freely reverse engineered, provided the usual cleanroom methods are followed.
The original PC BIOS was also proprietary.

Google did the same thing with Java. It’s up in the air how that will turn out.

> as far as most customers are concerned

Probably true for the average punter, but we shouldn’t overlook the other players, like Alibaba, DigitalOcean, IBM, Vultr, Oracle, Linode and more.

A serious enterprise is not going to bet their cloud infrastructure on Linode. AWS offers a lot more than just a bunch of hosted VMs.

A serious CTO whose neck is on the line is not going to go with a small player.

To paraphrase an old saying.

“No one ever got fired for buying AWS”

For an MS shop, the same could be said for Azure.

If you go with AWS because they have the best SLA, or GCE because they have better managed K8 offerings, then fine.

But going with AWS because ‘no-one ever got fired’ for it, or picking Azure because you play squash with a guy from Microsoft’s sales team is just lazy. Not that I’m saying it doesn’t happen.

Forbes and Gartner might ignore the other players, doesn’t mean we can’t be better informed.

Well, let’s look at where the phrase originated and how that turned out.

If someone had bought a mainframe IBM system in 1980 to run their COBOL system over their competitor, 40 years later, they could still buy a compatible system from IBM. It’s competitors - not so much.

On the other hand, idealism has its place, but when things hit the fan because of your choice of vendors, it’s a lot easier to justify a buying decision by saying the vendor was in the second quadrant of Gartner’s Magic Square.

more than VMs. yes, and that's the vendor lock in part.

sometimes it's okay though.

but AWS monoculture is not a bright future.

All of the services with no lock in

Elastic Cache - hosted Redis and Memcached

Aurora - compatible with MySQL and Postgres

RDS - hosted versions of Mysql, MariaDB, Sql Server, and Oracle.

Redshift - yes it uses a proprietary/columnar store engine but it is compatible with Postgres.

Etc.

But the bigger point is that you’re always locked into your infrastructure, do you think your CTO is going to move from their million dollar Oracle infrastructure because you used the Repository Pattern?

AWS has quite a few other solutions that you haven't mentioned that are not so portable.

I'm not advocating simply ignoring AWS's strengths because let's say Lambda/EBS/ELB/etc. is proprietary, but this is a very real, very simple risk. As AWS can, it will raise prices.

And sure, maybe it doesn't matter because you can always just fall back to using whatever you use on simple VMs, and AWS will always have some competition in the simple VM hosting space and VM prices will therefore will be low.

However, I'm on the opinion that institutional inertia will "kick in" (to use a rather bad figure of speech for something that is about as agile as a drum of molasses) and will simply let AWS rent-seek.