Hacker News Reader

Comment by tempest_ | Hacker News Reader

Assuming they didnt make them an offer they couldn't refuse.

You know, work with us or we'll OpenDistro you.

This is how software is supposed to work. If your enterprise value-add can be replicated by a two pizza team and that team is cheaper than your licensing fees then it's barely even a question as to whether it's worth it. We do this all the time on a smaller scale at our company to avoid license fees. We need one small feature from the enterprise offering so we implement it ourselves to say with the free oss/community version.

Except that Amazon isn't "a two pizza team", it's a 1.5 trillion dollar company that could replicate any startup ever with 6-12 months and a hundred engineers.

I think in the business world this would be called "not having a moat." There's basically only one to proceed if your product can be semi-trivially copied by someone throwing money at the problem. You have to sell it to them for less than it would cost to build in-house. Sure they could throw money at the problem but they won't when it's cheaper to just buy it.

When you have that much money, moats don't matter.

Code commit.

It is so horrible compared to GitHub.

Don't forget their continued lack of anything to compete with Heroku (that is, hook up to GitHub, deploy automatically from master, with less than 20 clicks in the web UI).

EBS was never it, and Lambda is a different type of product (and also won't autodeploy from your GitHub master without custom CI/actions/whatever).

Then there's Lightsail, which is perhaps the lamest DO ripoff that could possibly be engineered. I'm sure there are other examples, too, but those are the ones with which I'm familiar.

It doesn’t guarantee that they can execute, only that they can easily do so with that much money. Not everything needs to be conquered nor makes sense to do so at that scale.

> enterprise value-add can be replicated by a two pizza team and that team is cheaper than your licensing fees

This is always easier if the starting point of that two-pizza team is fairly close to "clone the version that already works, change the name, and run the deploy script".

> We do this all the time on a smaller scale at our company to avoid license fees

There is a huge difference between you doing something for your in-house use, and Amazon doing something in order to turn around and re-sell it.

> This is always easier if the starting point of that two-pizza team is fairly close to "clone the version that already works, change the name, and run the deploy script".

This model only works with the OSS/community versions of software. If the the only value of your hosted offering is the hosting I would expect you to get eaten by a company with cheaper hosting costs than you. I'm talking specifically about a clean-room reimplementation of proprietary add-ons that typically make up the "enterprise" version of lots of software.

> If the the only value of your hosted offering is the hosting I would expect you to get eaten by a company with cheaper hosting costs than you

By this logic Google and Amazon should just own-all-the-things because they have the cheapest hosting costs?

> I'm talking specifically about a clean-room reimplementation of proprietary add-ons that typically make up the "enterprise" version of lots of software.

I don't know what you mean here. As far as I know this is not what is being discussed. Amazon has done no "clean-room reimplementation" here.

That's not what I'm saying at all. I'm saying that if you write a piece of OSS software and your plan to monetize it is just hosting it then you're going to get eaten by companies who are better at hosting than you. Your valuable asset and your core business is your software not your ops.

Next, if the way you plan to monetize your OSS software is by selling a proprietary "enterprise" version but the features that version includes are easy to clone and your licensing costs are high then large companies will just hire people to develop their own in-house version and they might kill your business by open sourcing their version because they don't need to sell their in-house version to make it worth the cost.

Maybe they're referring to DocumentDB versus Mongodb? My understanding was documentdb was wire compatible but a clean room reimplementation of it?

It's always amusing when I see corporate engineers espouse some open source value and then follow it up with, "That's how it's supposed to be!" They totally ignore that if you entirely profit off of grafana and then destroy grafana labs in the process then they will be the maintainers of grafana and since that will go well beyond a "two pizza team" AWS will drop it.

tldr: corporate engineers have to be trained to respect and understand open source and it's just weird.

I am not wholly convinced.

There is a considerable problem in enterprise software where trivial features are enormously expensive. If you hide all of the useful authentication features behind thousands (or tens, or hundreds of thousands) them don’t be surprised when somebody scoops you.

Value add needs to be more like added value than ransom.

But that's because the non-trivial stuff, the real meat of the core product, is free right? Almost every dual (or more) priced (core) source available (at least) is enterprises with the money subsidising it for people/companies for whom the alternative is not to use it, not to pay for it.

If you have any emotional response like that it's 'ransom', then you're probably not the target audience for the enterprise tier.

(And I don't mean that you don't need/can't make use of features hidden in that tier, just that if there are many in the same boat, then the provider misjudged the contents of that tier.)

I get the feeling you are talking about Elastic here, and I 100% agree that core authentication and security features (and sane defaults) being "Enterprise" is a bonkers decision.

Core authentication and security features in Elasticsearch have been free and not Enterprise features since last May: https://www.elastic.co/blog/security-for-elasticsearch-is-no...

Sweet, I didn't know that had changed. Good decision.

Disclosure: I work for AWS

Free for some to use under certain restrictions. Therefore not Open Source (which is totally OK, I just want to make sure there's no confusion).

> There is a huge difference between you doing something for your in-house use, and Amazon doing something in order to turn around and re-sell it.

Is there? Or is it your bias against commercialization or profit motive of modifications to free software? It seems to me that it's the same changes to the code.

I think they're talking about the scale of the tooling and integrations into existing systems required to roll out Grafana to hundreds of thousands of people.

> There is a huge difference between you doing something for your in-house use, and Amazon doing something in order to turn around and re-sell it.

There really isn't. If you make your work available to the world so that everyone has the right to not only use it as they see fit but also extend it to fit their needs then you cannot complain that someone is using said work as they see fit and extending it to fit their needs.

While I get the sentiment, this activity is what is killing open source. If you like a tool, contribute or license it to keep it a float. Don’t just rip it and do your own thing. There are maintenance costs that aren’t associated with the feature development. There are liabilities, legalese, indemnity, etc you should worry about.

Support open source.

Free software means freedom to modify it and build a paid service from your private fork.

If you can't do that, it's not free software, despite what the AGPL torch-carriers think. Freedom means free to do things that may be contrary to the desires and interests of the original authors: this is why software with "no military/no missiles/no bombs/etc" clauses in their licenses are not free software.

And why the JSON license isn't Free or Open Source since you're not allowed to use it for evil.

Reply on news.ycombinator.com