Hacker News Reader

> Now that the gorilla has been enraged woe to the thing that pissed it off. We'll see if amazon actually contributes to the new fork.

Elastic loses nothing by pissing off AWS, this was clearly the right move. AWS has contributed very little to the project so far, so if they took their toys home in a huff it makes no difference to Elastic. And if AWS does contribute significant development to their new fork, Elastic is free to copy any worthwhile commits into the official repo under the terms of the license Amazon has released their fork under. The only thing Elastic is going to suffer for this is some people whinging on HN about whether or not it’s “really open source” anymore.

Just curious, have you ever operated Elasticsearch at scale? I haven't operated at the petabyte level but I have at the terabyte level, and everything I've seen tells me that this move is going to hurt Elastic immensely. They've forced Amazon to create the Elastic equivalent of postgressql/mariadb/jenkins ci.

What downside exists for Elastic from making this change? If AWS makes valuable contributions on their fork, Elastic will absorb them, but the converse is no longer true. If the downside is that the AWS hosted ElasticSearch service will become successful, well, that was happening anyway before the relicensing.

I don’t see a path for absorbing and relicense. Especially if the core code method signature diverges in the future. It is going to be a lot of trouble for Elastic to absorb non-trivial contributions from the fork.

Aws has an advantage of the manpower. They can easily move ahead of origin and ES can never catch up.

> Amazon can easily fund developers, they just didn't because they didn't have to.

Disclaimer: worked at AWS.

Yes, Amazon has a vast number of engineers. They also have a vast need for engineers.

So they have to make a business case to continue to fund engineers, and I don't think one exists for the type of development we're wanting.

To be clear, there is some development they could justify.

If they are replicating new features that Elastic releases, so they're not falling behind the market, the business case is retaining customers. But that's playing catch up.

If new features optimize the service, the business case is being able to advertise lower TCO, which attracts customers. That could be quite beneficial, but there's usually not a ton of optimization you can do.

There is a business case for new features that increase integration with other AWS services. That increases customer usage of AWS. But AWS is so proprietary this would likely be useless outside AWS.

So none of that, I think, is the development people are looking for.

What we'd want are features a software business develops to differentiate their product in the market. If the features go into the open source version, however, then by definition they aren't differentiating.

This is the key business contradiction in AWS trying to fund open source development.

Maybe I'm missing something and they can make the business case for continued differentiating feature development. So, I'd say I'm wrong if after two years we're seeing such features being released to the commnuity.

> Amazon can easily fund developers, they just didn't because they didn't have to.

Looking at the various projects at https://github.com/opendistro-for-elasticsearch/, the most prominent ones seem to only have a handful of somewhat active developers, almost two years after launch.

If AWS hires a lot of people to work full time on their ASL2-licensed Elasticsearch and Kibana forks, then ... that's not necessarily _just_ bad for Elastic? I doubt Elastic execs thought AWS would just fall over and discontinue something that's probably billions in revenue at this point. If AWS actually starts contributing code beyond trivial bug fixes, code Elastic can legally fold into their own Elasticsearch (via the ASL2-licensed fork) if it's good enough, then ... good for both?

Apache 2 license doesn’t allow you to relicense. So absorbing changes from AWS’ fork won’t be clear or easy as many in this thread suggest.

Apache 2 license explicitly does grant the right to sublicense. See §2.

Honestly I don't know how that works. My understanding is that you cannot move existing ASL code under a different terms other than ASL unless you are the copyright holder. All modifications you done can be subject to whatever terms you liked. This seems to match what they said http://www.apache.org/foundation/license-faq.html#Distribute...

I think this important bit is sublicense v.s. relicense, where in sublicense case, you have to retain the original terms carried for the original code.

Now, Elastic relicensed the whole software stack under SSDL. So to integrate any parts AWS done, they need to license Elasticsearch back to some mixture of SSDL and ASL, which would be weird.

"Amazon can easily fund developers, they just didn't because they didn't have to"

That may be true for a few OSS projects, but if they were forced to do that for ALL the projects they're profiting from the math would probably not look as simple.

Of course Amazon will contribute to the new fork. They have many thousands of paying customers who have little incentive to switch, for better or worse. The only thing that might actually call for a migration is a significant decline in feature development.

Your argument illustrates the hard fact revealed by the Parler ban. No, Amazon isn't a monopoly (I'm using an Elastic cluster on Azure), but they wield influence as though they were.

> The fact that amazon is in a better position to make money off of open source software is part of the calculation that startups should be making if they are writing open source software

So what you're saying is people shouldn't work on open source projects. That's essentially what your statement boils down to.

No, it's a fair thing to consider when you're creating a business based on a project that can be forked, that someone with more money and resources than you can fork it and run you out of business.

That doesn't mean people shouldn't contribute to open source projects.

I should point out too, most companies actually can't afford to fork and take over projects. At $PreviousJob we wrote proprietary software but used open source software (for example Intel DPDK). If DPDK were to suddenly switch their licensing, we would never have the resources to maintain something like that long term. So just because it _can_ be forked and "taken over" by another company doesn't mean will. It most likely won't.