Hacker News Reader

Comment by CaptArmchair | Hacker News Reader

I think I have grown a rather hard stance on this over the years: putting an open source license on a product isn't a business model. It's, by and large, a part of a larger business model.

A license is a choice. It means you choose to not gain revenue by directly licensing the IP. Instead, you choose to put the code out there without any further legal obligations on your part as well as those who use that code.

It also means that you have to find alternate ways of making revenue e.g. by providing consultancy, building services or licensing the trademark (which is an entirely different ball game from open sourcing the code!).

The trouble isn't that Amazon decided to use ElasticSearch in their own offering. The trouble is that Amazon simply out-competes ElasticSearch with their own product when it comes to consultancy, services, etc.

To add insult to injury, Amazon made the mistake of leveraging the ElasticSearch brand a few times too many in ways that just rub the ElasticSearch people the wrong way.

Of course, the founders of ES could never predict how successful their product would become after a decade. There are plenty of open source products engineered by commercial companies that never catch the eye of behemoths like Amazon.

View on HN

> Amazon simply out-competes ElasticSearch with their own product when it comes to consultancy, services

You're kind of right about this, but it's the issue that AWS just has a massive head-start with any client that already uses AWS. They don't really out-compete, they just use their existing vendor lock-in to gain an advantage. And really, by using your dominance in one "market" to gain an advantage elsewhere ends up feeling like a bit of a grey area.

> To add insult to injury, Amazon made the mistake of leveraging the ElasticSearch brand a few times too many in ways that just rub the ElasticSearch people the wrong way.

You're phrasing this in a way like Amazon "leveraging the ElasticSearch brand" isn't a trademark issue. Is "leveraging the trademarks of another company" suddenly okay (as long as you don't do it 'a few times too many') as long as you're Amazon? What if Amazon started selling smart thermostats by "leveraging" the Nest brand?

At my job, we evaluated moving from AWS hosted ES to several of the Elastic offerings. Many of them were more expensive than AWS was before taking hardware into account (as in comparing cost of Elastic licensing vs the whole cost from AWS). This made it exceedingly difficult to justify the move. It's not only the headstart with the client (billing relationship in place), but the cost that hampers them.

But isn't a big part of the reason Amazon can offer better pricing because of the scale of their existing client base? I'm not saying that they are doing this, but they could if they chose operate on very thin margins or even at a lost to keep their hold on clients and make up with it on other products in their ecosystem.

Hmm. Operating on thin margins to gain market share and drive competitors out of business, then making up the difference by creating sales in related businesses in their ecosystem doesn't sound much like Amazon...

In my experience it is that Elastic does not understand the market.

About four years ago we have attempted to get their software . It felt like I was dealing with Cisco sales people circa 1998. They were clueless on how to do a multi hundred thousand dollar deal - think slow, inefficient, inflexible, unwilling to compromise on extra $500 add on that would have ended up being a rounding error.

That's how it is for a lot of companies, not just Elastic. We have to deal with jfrog, who has separate billing teams for SaaS and on-prem so for us to switch from on-prem to SaaS is a pain in the ass. If AWS ever offers artifacts storage with more artifact types, then obviously we're switching. And that's just 100% so we don't have to deal with jfrog's dumb ass contracts anymore, never mind pricing.

ugh the pain that comes from negotiating our contract every year. Or the pain that comes from trying to get trial licenses. Or the pain we're seeing now from switching to SaaS.

And that's why AWS eats their lunch. Execs of Elastic ( and other companies ) should deal with their inept sales force rather than point fingers at AWS.

> You're kind of right about this, but it's the issue that AWS just has a massive head-start with any client that already uses AWS. They don't really out-compete, they just use their existing vendor lock-in to gain an advantage. And really, by using your dominance in one "market" to gain an advantage elsewhere ends up feeling like a bit of a grey area.

I'm not sure if it's actually a gray area, since I'm pretty sure leveraging your market dominance in one area to compete in another is illegal anti-competitive behavior. Isn't that what the whole Microsoft antitrust case was about? It's too bad the government pretty much gave up on enforcing antitrust law for 20 years, since it feels like similar practices became normalized due to lack of enforcement.

> leveraging your market dominance in one area to compete in another is illegal

Leveraging your monopoly to compete in another area is illegal. Leveraging a strong position isn’t and Amazon is a long ways from a monopoly.

That depends on jurisdiction.

In the EU, it is "dominant market position" (and explicitly so) that's the threshold for the Commission to take competition action, for instance.

would AWS be considered "dominant" though? they are the indisputably the market leader, but there's plenty of competition

(not trying to argue they aren't dominant. just curious)

I don't see why not.

British Airways only had a 38% market share when they were sued for abusing their dominant market position in 1998 (which was upheld by the Court of Justice in 2007)

Presumably they could. I mean, if the EU legislators had intended for a monopoly to be necessary to be considered “dominant”, then they could have written “monopoly”, couldn't they? They didn't write that, so it seems safe to presume they didn't intend that. And if anyone is dominant, then who, if not the market leader?

> Leveraging your monopoly to compete in another area is illegal. Leveraging a strong position isn’t and Amazon is a long ways from a monopoly.

That really depends on interpretation, which has shifted over time and continues to shift. IIRC, recent interpretations of some types of anti-competitive behavior have been rather literal and required something very close to a literal monopoly, which has had the effect of neutering antitrust law in all but the most blatant of cases.

My understanding is that it's arguable that it's anti-competitive to leverage market share advantages more broadly (e.g. antitrust law could be used to constrain/break-up a duopoly).

Amazon, Google, Microsoft is not a duopoly :)

And while there are probably some services on AWS you can’t find at a competitor - that’s mostly a choice (aka profit margin) made by the competitor.

The grey area here is more about what the "market" is defined as here. It's not entirely clear that the existing dominance that AWS has is different enough from "hosted search services" to be considered a different market (from an anti-trust point of view)

Yes, thats all this comes down to in the end.

Open source works fine, and does quite well as a business model (use it as free advertising).

What has happened here is a plain old case of monopoly.

Once markets are no longer efficient, the model breaks down. Amazon can use its resources to extinguish competition with their own product.

This is why we need antitrust law.

It's not a failure of capitalism, its not a failure of the businesses involved its just what happens when you run a freeish market. That is, things get out of whack to the point we the people feel it is unjust, it would eventually right itself but this would take a long time and likely do more interim damage than its work allowing, so we fiddle with it, hopefully not breaking anything in the process.

> its just what happens when you run a freeish market... it would eventually right itself but this would take a long time

If we think of the system as a delicate natural balance that we should try our best not to disturb too much I think we've immediately taken a very specific stance which itself shouldn't be above critical examination. It is, after all, just a social system and all social systems involve some level of design whether we like that fact or not.

In theory, we could conceive of the possibility of an economic system that both preserves the autonomy and independence of its actors while also preventing monopolies from emerging in the first place. Its a hard problem to wrestle with but its preferable to acquiescing to the blind faith in the invisible hand. We should never give up on an effort to understand how we could evolve our current systems into ones that work better (imagine if we took the same stance with technology).

I think there's a subtlety in the way Amazon as a company markets what they do and leverages the brand that's important here.

Take for instance Amazon RDS which is a family of managed relational database services. I don't think "Amazon RDS for MySQL" is an unfair use of the "MySQL" trademark, even if Amazon haven't asked Oracle's permission. The reason here is that it's much clearer in the way RDS is branded that it's not endorsed by the database engines it supports, it uses their trademarks to describe the engines they integrate with which seems reasonable in my view. Amazon RDS is still its own independent brand.

"Amazon Elasticsearch Service" crosses the mark in my opinion because it blurs the line between the two brands and in many ways implies that Amazon actually made Elasticsearch themselves.

>> Amazon simply out-competes ElasticSearch with their own product when it comes to consultancy, services

Can't client run his own Elasticsearch inside AWS? By installing and maintaining it yourself (or contracting someone to do it for you).

Then I don't see vendor lock-in sense: "We choose AWS to host us, now we have no real choice but to use Amazon Elasticsearch Service". Am I missing something here?

> They don't really out-compete, they just use their existing vendor lock-in to gain an advantage.

For the customer, the biggest advantage of AWS' SaaS offerings over a 3rd party's (hosted on AWS) is the billing. AWS Marketplace negates that. Maybe at some cost to the provider, but I just found ScyllaDB and RedisLabs there, so it must be working for some.

> but I just found ScyllaDB and RedisLabs there, so it must be working for some.

No, it doesn't work for RedisLabs. Amazon offers managed Redis called AWS EC Redis and recently someone I knew decided to move their entire Redis (multiple) clusters from RedisLabs to AWS EC. RedisLabs lost hundred of thousand dollars.

I would like to think there are other definitions for a successful business than it being a single vendor.

RedisLabs is probably the vendor that foot the bill for Redis software development end-to-end.

While I understand that some people viewed a successful OSS project is akin to Wordpress: lots of hosting providers, rich ecosystems, _and_ Wordpress main company is still making good money out of it; this is not apple to apple comparison (can't compare Redis and Wordpress).

Redis belongs to the group of MongoDB, ElasticSearch, etc.

They don't outcompete. AWS's ES is a steaming pile of crap and everyone I've ever met with a real usecase that needs ES on AWS rolls their own on their own EC2 instances.

I quake to think of how bad ES's own managed service must be if it still gets customers then. I don't know anyone that uses the services offered by ES so I can't ask directly.

> The trouble is that Amazon simply out-competes ElasticSearch with their own product when it comes to consultancy, services, etc.

I don't know if it out-competes them on those terms exactly, rather than the advantage of "Well I'm already on AWS and they offer an ES service so why not just use that".

true - but that's exactly how it out-competes. It's a repeating pattern. Setting up an agreement with a 3rd party provider has friction. The bigger the client, the higher the friction. If $BIGCO has an enterprise agreement with $BIGCLOUD, then $SERVICE hosted on $BIGCLOUD is nearly always going to win against $SERVICE's own commercial offering.

Right, but that's the sort of setup that's detrimental to society and therefore we ought to consider regulating or otherwise setting up an environment that is disadvantageous to it.

Why do enterprises make it difficult to add a new vendor? Because they are careful with their data and legal obligations. Regulatory and auditing obligations are no joke and onboarding a new vendor is a nontrivial problem to do in a compliant fashion. The only aspect of this which is "detrimental to society" arguably is the legal requirements, but even then you might argue its better for a large organization to pay attention to other companies' licenses instead of stepping on them.

spot on. The lesson for would-be companies formed around open source is pretty stark: if your stuff is any good, then assume the clould vendors will offer it. If they do, it's going to be really hard for you to compete with a separate commercial offering.

Not only has the cloud vendor already gone through the hoops of getting an enterprise agreement in place. They're also big, and recognised, and know how to deal with Procurement. And Risk. And Compliance. And Legal.

Not saying I like that situation. It does seem unjust that the big guys can just cherry-pick good products and monetise them without giving anything back. It offends my sense of fairness. But that's commercial reality, at least in today's markets.

The whole reason I would choose an open-source tech against closed source is so that I can go to whoever I want for support and future enhancement, that I'm not dependent on this tiny company for my business continuity. Sometimes that tiny founding company may not be the best to offer the kind of support and enhancements I need.

A real personal example I experienced: at one time, the founding team behind a project I happened to use at work actually told me they didn't want to do the enhancement I was asking for because my particular scale-out needs were too niche and none of their other paying customers need that and they didn't have the engineering bandwidth to build my feature (the opportunity cost for them was too high to abandon building features needed by their other customers).

So I had to solve this scale-out problem by myself - which was painful (we had high opportunity cost too).

In that situation, if my cloud vendor were to say they would solve that problem for me as they would be willing to invest whatever engineering bandwidth required to make it happen, then I would go with them.

Now if that happens a few times, the cloud vendor's service offering will be much superior to the original project founding team's offering.

Over time, the cloud vendor's offering will also be cheaper.

Of course the trick here is to be watchful of being sucked into a lock-in by the cloud vendor. You will have to insist that all of the features they are doing for you are actually open-source and portable to another cloud. Many companies define such requirements as part of their procurement process and audit for it.

As more companies start to push for such guardrail requirements to prevent cloud lock-in, the open-source commercial support model may still have a chance – but unfortunately that doesn't necessarily mean the project founding company will do well.

> In that situation, if my cloud vendor were to say they would solve that problem for me as they would be willing to invest whatever engineering bandwidth required to make it happen, then I would go with them.

Aren't cloud vendors generally less willing then smaller SAAS companies to do custom engineering work for their customers?

The other way in which they are detrimental to society is by taking revenue away from companies such as elastic that are actually developing technology. In general there is economic hazard with any large company. There are also benefits and I don't think they should be eliminated entirely. But I do think they should be curtailed and the economy biased towards smaller companies.

The key enabler here is IAM and data (at rest and moving).

If we want to encourage free markets, the GDPR et al. need to be very careful to disincentivize "traffic within different parts of the same entity."

As is, if my regulatory compliance is satisfied through AWS's data and IAM handling, then if an Amazon-hosted service better integrates with those components, it strictly dominates competition.

That's a pretty unregulatable quality, and one easily optimized by Amazon (for itself), and impossibly by everyone else (on Amazon).

This weaponizes data protection regulation into a moat around large everything-and-the-kitchen-sink I/PaaS providers.

There needs to be balance between (a) protecting data & (b) ensuring a competitive ecosystem with multiple viable solutions.

You could have a lot of the benefits of both if Amazon was partnering with these companies instead of copying the product.

> The only aspect of this which is "detrimental to society" arguably is the legal requirements

When it's hard to make a living out of open source software, that's detrimental.

How is increasing consumer choice and offering a cheaper product detrimental to society? It's beneficial to everybody besides Elastic's shareholders.

I wouldn't exactly call that "competition" though.

Correct. Customers are looking for a cloud platform to run their apps, all the services are just features.

Elastic is a feature, event bus is a feature, database is a feature, compute is a feature.

Do you not think distribution is part of a product?

I interviewed at Amazon, and researched their offerings to better prepare.

Until reading this news, I never realized ElastiSearch wasn't an Amazon product, I always believed ElastiSearch was Amazon's invention, because of how Amazon employees talk about (always "Amazon ElastiSearch" phrase, often dropping the "service" part of it, so is easy to assume it is "Amazon's ElastiSearch" like "Microsoft Windows")

So it is not just... "a few times too many", if I am interviewing for the company and got extremely confused, how other people wouldn't be confused too? And that is the whole point of trademark laws!

The problem here is that Amazon is infringing on copyright, using the "Elasticsearch" trademark and lying about a partnership in a tweet.

> A license is a choice. It means you choose to not gain revenue by directly licensing the IP. Instead, you choose to put the code out there without any further legal obligations on your part as well as those who use that code.

Open source doesn't mean you can infringe on its copyright and use trademarks everywhere you like.

> It also means that you have to find alternate ways of making revenue e.g. by providing consultancy, building services or licensing the trademark (which is an entirely different ball game from open sourcing the code!).

You didn't read the whole article?: "I took a personal loan to register the Elasticsearch trademark in 2011 believing in this norm in the open source ecosystem."

Please don't confuse trademarks and Copyrights - they are entirely separate things. Using a trademark is not infringing Copyright. It may or may not be infringing the trademark, but that's a whole different thing.

In general, anyone can use your trademark as long as they are using it about you or your product. I can say "I like Coca Cola, it tastes great" or even "Coca Cola is disgusting" but if I put Coca Cola on the menu but give you Pepsi, that's infringing.

This is why some projects have generic names and brand names for the commercial version. PhoneGap and Cordova, RedHat and Centos, etc. Amazon can offer a machine and say "This is Centos, it's mostly the same as RedHat", but they can't say "This is RedHat" unless they pay for actual RedHat.

Don't you need permission to advertise your product with Coca Cola™?

Or in this case, would Amazon not need Elastic's permission to say "we use Elastic" to advertise AWS?

Trademark law is very different than copyright law. You are allowed to use trademarks in certain circumstances. You can’t imply a relationship that doesn’t exist, but AWS saying - this is a hosted version of Elasticsearch would probably be okay (but IANAL).

Where they’d get into trouble is if they said they offered a hosted Elasticsearch, but under the hood it was something else. But, even then they could probably say that their offering was Elasticsearch compatible.

The real question is: was AWS misleading customers? I don’t make any claims one way or the other about this specific case. But I wanted to point out that you don’t always need permission to use another’s trademark.

From [1]:

> Nominative use permits the use of a trademark – even in commercial contexts – if it is the most accurate way to refer to a good or service without misleading consumers as to its source.

[1] https://google.github.io/opencasebook/trademarks/#fair-use-d...

> if it is the most accurate way to refer to a good or service without misleading consumers as to its source.

But if you're buying a service from AWS the source is not Elastic.

You might be able to say compatible with elastic search. But using the name in your own product name seems unlikely to hold.

I think this is shortsighted on Amazon's part, because it probably wouldn't cost all that much to make a joint offering.

I would be curious to know where those lawsuits went. Because it seems like something that should have been resolved, and for which you could get an injunction.

The problem is clearly that people think they are getting a service supported by ES, when they are getting a look-a-like copy service. Which is what trademarks are intended to resolve.

In hindsight, maybe it would have worked better for ES, had they called the open source product something else, like how centos isn't called RedHat.

> clearly that people think they are getting a service supported by ES

Something like this is also asserted in the OP. However, I'm not so sure that is the case. I don't think it's clear at all.

Knowing that Elasticsearch is (was) open-source, I'd assume that I'm getting an AWS hosted installation of Elasticsearch... which is entirely accurate. If you can install the software on your own server, and AWS offers a managed version of it, I have no expectation that the original developers are involved at all.

Ever since the original release, it looks like AWS has been much better at avoiding any mention of Elastic.co. The original announcement Tweet was definitely misleading.

> In hindsight, maybe it would have worked better for ES, had they called the open source product something else, like how centos isn't called RedHat.

I think this is the major problem, and you're right. Elasticsearch was the original trademark and is the accurate mark for the software. They only formed Elastic.co later, and this is where a lot of confusion originates. Elasticsearch != elastic.co

It might be better for AWS to just include a disclaimer like "AWS Elasticsearch Service includes the open source Elasticsearch software, but is not supported by the original developers." Something like that...

> The real question is: was AWS misleading customers?

Hell yes. I thought it was Amazon's trademark!

> Don't you need permission to advertise your product with Coca Cola™?

Not if what you're selling is Coca Cola

Genuine question: why Amazon EKS and not Amazon Kubernetes then? I noticed every single managed Kubernetes doesn't call it Kubernetes.

Huh?

EKS => Amazon Elastic Kubernetes Service

Kubernetes is a little different here... it seems a bit more nebulous from an installation/instance point of view. It's a bit like saying we use "Linux". Which Linux? Debian? Ubuntu? RHEL? SUSE?

Because that Trademark is owned by the Linux Foundation who are very well positioned and financed (AWS themselves are Platinum members) and published clear usage instructions.

As someone else said, what constitutes "Kubernetes" isn't well defined, and so the CNCF put limits on using the terminology in product names.

You don't fix trademarks disputes by changing software licenses. Elastic appear to have a sound argument on the trademark front but to conflate that with changing the license of their product is disingenuous.

I read their argument as 'suing Amazon in the courts for trademark infringement is an insufficiently expedient remedy.'

It does OSS no good if Elastic prevails on merits the day after they go out of business from lost revenue.

And what remedy do they have to a copyright license infringement? The same glacial pace legal system.

The damages and ramifications for violating software copyright are much clearer than the nuanced world of trademark infringement.

The change in ElasticSearch license here is well publicised. If AWS were to continue to incorporate new changes to ElasticSearch it would be obvious they had deliberately violated the terms of the license and it's much easier to pursue a legal case.

> The trouble isn't that Amazon decided to use ElasticSearch in their own offering. The trouble is that Amazon simply out-competes ElasticSearch with their own product when it comes to consultancy, services, etc.

I kind of disagree here, the main reason it outcompetes is based on the network of linked self serve services in the ecosystem. We spend a ton of money on Amazon in general, and I would not tout thier consultancy as being anything but ok if not underwhelming.

That's a fair point.

> it outcompetes is based on the network of linked self serve services in the ecosystem

You have to differentiate between business concerns.

First, the concern of those who are willing to buy an IP license because they think the product is useful to them (akin to buying a Windows license key).

ES doesn't make any revenue here. They don't sell IP licenses. That's a direct consequence of putting an open source license on your product. Anyone can just get a copy of the code and spin up their own instance, no strings attached.

Second, the market of those who are looking towards assistance in using the product (consultancy, support, servicing, hosting,...). You can spin up your own instance and do all the work yourself independently. But for organizations, operating software is an expense: often it's cheaper to outsource those costs towards specialists... such as ES offering consultancy services.

The product license and the type of support you want/need are different business concerns. You can choose to an open source product and host everything yourself, you can choose a closed source product and host it yourself, or you can outsource hosting and support to a partner like ES or AWS.

> We spend a ton of money on Amazon in general, and I would not tout thier consultancy as being anything but ok if not underwhelming.

Don't get me wrong here... But the moment you open up your wallet for AWS, you've already contributed to AWS' market position against ES.

Sure, your experience with AWS might be underwhelming, and that's totally valid. But that doesn't matter if you still go ahead and choose to pay for their services.

A market position isn't tied to the quality of service. It's tied to how much potential customers a business can sweep up and convert into hard revenue. The quality of the service is tangential to that.

You can create an absolutely shoddy user experience, and still dominate a market if you happen to position yourself at the right time, with the right product to the right people.

Agreed.

We actually were customers of Elastic's offering for a while, but they went down 3 times in a quarter, which was simply unacceptable. We had to switch, and have been okay since. Our bill is also more than half of what it used to be.

The AWS implementation is quite limited in many ways, and there could be a point where we switch back or host it ourselves.

In a way it's hinting at the need for anti-trust barriers similar to how India barred Amazon from both running a product marketplace and offering it's own products in the same marketplace.

I can see both sides of it though. If there are an anti-trust barrier between running AWS and offering major services on top of it, there would be a better overall segregation and likely more innovation overall. On the other hand, putting up a barrier there would be both complex and leaky, and cause missing out on sorts of efficiencies from close integration of cloud platform + services.

This subthread was originally a reply to https://news.ycombinator.com/item?id=25834523. We sometime prune these when they get too top-heavy aren't tightly semantically coupled.

Reply on news.ycombinator.com