Especially considering ~11 of the Apache Lucene committers are Elastic employees as well as 10 members of the Apache Lucene Project Management Committee.
Disclosure: I work for AWS where I build infrastructure services that sit low in the stack. I am a relative novice when it comes to Java-heavy codebases like Apache Lucene, Elasticsearch, or OpenSearch. But I know a thing or two about Open Source and Communities.
I think it is hazardous to count the number of committers and PMC members that are part of a project that is built at the Apache Software Foundation. It is helpful to keep track of these things to make sure that the project keeps its independence, and is not unduly influenced by the interest of any one company or organization. Committers and PMC members earn their position based on their own efforts as individuals. They don't represent their employers.
The current Apache Lucene PMC chair just happens to work for Amazon today. A number of folks that used to work for Elastic now work at Amazon. But over-focusing on that, and keeping careful track of what company contributes how much to ASF projects, is bad for community health in my personal opinion.
I think it's reasonable to expect that corporate citizens worth billions of dollars would do their fair share of open source contributions. I'm curious why you think this is bad for community health.
It is totally reasonable to expect for-profit corporations to be good stewards of shared resources, such as the public goods that make up the Free and Open Source Software (FOSS) commons. I think it is important to all users of FOSS that the software is well maintained, and is able to grow to meet the changing needs of users. We often call achieving a system where sufficient value created by FOSS can be captured in ways that funds its ongoing development and maintenance achieving a "self-sustaining" system. One view on sustainability in FOSS can be found in this Apache Software Foundation blog post [1].
Companies should also be respectful of the communities that produce and maintain software, including understanding the philosophy and governance that communities have adopted. For the Apache Software Foundation, this is being mindful to not unduly influence the project, such as to try to control it through employing a majority of the people who work on the project, or otherwise weaken the independence and autonomy for the community that builds and maintains the software. [2]
I've seen situations in the past where companies employ an open-source marketing strategy that ends up encouraging unhelpful activity in open source communities. This can also happen when companies measure the performance of a software developer based on metrics such as "number of patches accepted in an open source project." This kind of thing is generally unwelcome in open source software communities. See this thread on HN [3] on the Linux kernel development list, TL;DR - "Please don't waste maintainers' time on your KPI grabbing patches."
There is a ton of work on top of Lucene. And Lucene is still OSS. So yes what Amazon is doing is stealing Elastic’s work.
I’m sure this will change how every other company is the OSS world will operate from now on. CockroachDB for example is already preventing a monopoly like Amazon from taking over.
1. All of which is useless without Lucene. In fact, it wouldn't have been possible without Lucene. Thus, by your own twisted argument, Elastic "stole" Lucene's work.
2. Not all of the code in ElasticSearch is written by Elastic. Co. It's not their sole codebase. They have no monopoly on it. Maybe if they never took in contributions from others, but they did.
And Lucene is still OSS.
OpenSearch is still OSS. The ES base that OS forked from is also OSS.
... a monopoly like Amazon from taking over.
Now I know you're being dishonest. Amazon never had a monopoly on ES, it still has no monopoly on OS. It's Elastic (like CockroachDB, that you mention) that are trying to enforce an artificial monopoly. Of themselves.
If you want to find out whether ES is really the "little guy" or the "monopolist", try providing a hosted service of their latest release and see how they react. It doesn't matter if you've contributed code to ES before, it doesn't matter if you're the most prolific contributor to Lucene.
It doesn't matter if you can build a better version of ES or provide better service. Elastic Co. (and CockroachDB Inc.) will simply not allow you to compete.
----
For once, try pointing the finger fairly, at everyone. Try judging everyone with the same set of laws/morals. Hold your heroes to the same standards, at least, as your villians.
CockroachDB is doing the right thing and I bet ES would have done it much sooner if they had any clue that Amazon is going to screw the small guy.
Also your arguments doesn't make any sense. Lucene is still OSS and OpenSearch is not Lucene but built of Elastic code. They didn't rebuild everything from scratch but literally used the code Elastic wrote.
No one argued OpenSearch is not OSS.
And sorry - if you think Amazon as a company is not screwing the small guy, I feel sorry for you.
Elastic also screwed plenty of small guys to get to where they are. And they're no longer small.
Also your arguments doesn't make any sense.
Thank you, I used your twisted logic to arrive at them.
Lucene is still OSS and OpenSearch is not Lucene but built of Elastic code.
And Elastic is not Lucene but built of Lucene code. So why is it okay for Elastic to build a proprietary package using OSS code, but not okay for AWS to build an OSS package using OSS code?
They didn't rebuild everything from scratch but literally used the code Elastic wrote.
1. OpenSearch is more than ES Community Edition. OpenSearch does have some code of its own; significant enough to matter. Code that was considered basic featureset that Elastic refused to add, even rejecting PRs. What do you do when your PRs that add significant features are rejected? Especially when the reason is, "because we don't want you to compete with our proprietary packages"? How FOSS is a project, really, when it refuses such PRs?
2. Like Elastic didn't rebuild everything from scratch but literally used the code (as a library) Lucene authors wrote. So why is it morally okay for Elastic to profit off of OSS work they didn't do, but not for AWS to build OSS off of OSS?
No one argued OpenSearch is not OSS.
You called it 'stolen'. Why is it not stealing when Elastic builds a proprietary package off of OSS code, including code that was donated specifically to be included in an OSS package, when you claim it is 'stealing' to make an OSS package of the same license and with copyright notices preserved from another OSS package.
Amazon as a company is not screwing the small guy
I know exactly where and how Amazon as a company is screwing the small guys. This is not one of them. This is a field so full of strawmen it is difficult to see where it ends.
I feel sorry for you.
Please keep your sympathies to yourself. You need it more than I do right now. If nothing else, then for the simple task of judging your heroes with the same yardsticks as your villians.
Comments
Did Elastic do the hard work, or Lucene?
There's so much on top of lucene that I'd say both
Especially considering ~11 of the Apache Lucene committers are Elastic employees as well as 10 members of the Apache Lucene Project Management Committee.
Disclosure: I work for AWS where I build infrastructure services that sit low in the stack. I am a relative novice when it comes to Java-heavy codebases like Apache Lucene, Elasticsearch, or OpenSearch. But I know a thing or two about Open Source and Communities.
I think it is hazardous to count the number of committers and PMC members that are part of a project that is built at the Apache Software Foundation. It is helpful to keep track of these things to make sure that the project keeps its independence, and is not unduly influenced by the interest of any one company or organization. Committers and PMC members earn their position based on their own efforts as individuals. They don't represent their employers.
The current Apache Lucene PMC chair just happens to work for Amazon today. A number of folks that used to work for Elastic now work at Amazon. But over-focusing on that, and keeping careful track of what company contributes how much to ASF projects, is bad for community health in my personal opinion.
See also Doug Cutting at https://twitter.com/cutting/status/1359160158723711002
I think it's reasonable to expect that corporate citizens worth billions of dollars would do their fair share of open source contributions. I'm curious why you think this is bad for community health.
It is totally reasonable to expect for-profit corporations to be good stewards of shared resources, such as the public goods that make up the Free and Open Source Software (FOSS) commons. I think it is important to all users of FOSS that the software is well maintained, and is able to grow to meet the changing needs of users. We often call achieving a system where sufficient value created by FOSS can be captured in ways that funds its ongoing development and maintenance achieving a "self-sustaining" system. One view on sustainability in FOSS can be found in this Apache Software Foundation blog post [1].
Companies should also be respectful of the communities that produce and maintain software, including understanding the philosophy and governance that communities have adopted. For the Apache Software Foundation, this is being mindful to not unduly influence the project, such as to try to control it through employing a majority of the people who work on the project, or otherwise weaken the independence and autonomy for the community that builds and maintains the software. [2]
I've seen situations in the past where companies employ an open-source marketing strategy that ends up encouraging unhelpful activity in open source communities. This can also happen when companies measure the performance of a software developer based on metrics such as "number of patches accepted in an open source project." This kind of thing is generally unwelcome in open source software communities. See this thread on HN [3] on the Linux kernel development list, TL;DR - "Please don't waste maintainers' time on your KPI grabbing patches."
[1] https://blogs.apache.org/foundation/entry/the-apache-way-to-...
[2] http://community.apache.org/projectIndependence.html
[3] https://news.ycombinator.com/item?id=27629366
Indeed commit count is a silly metric. I reminds me of the bad incentives of the hacktoberfest
There is a ton of work on top of Lucene. And Lucene is still OSS. So yes what Amazon is doing is stealing Elastic’s work.
I’m sure this will change how every other company is the OSS world will operate from now on. CockroachDB for example is already preventing a monopoly like Amazon from taking over.
1. All of which is useless without Lucene. In fact, it wouldn't have been possible without Lucene. Thus, by your own twisted argument, Elastic "stole" Lucene's work.
2. Not all of the code in ElasticSearch is written by Elastic. Co. It's not their sole codebase. They have no monopoly on it. Maybe if they never took in contributions from others, but they did.
OpenSearch is still OSS. The ES base that OS forked from is also OSS.
Now I know you're being dishonest. Amazon never had a monopoly on ES, it still has no monopoly on OS. It's Elastic (like CockroachDB, that you mention) that are trying to enforce an artificial monopoly. Of themselves.
If you want to find out whether ES is really the "little guy" or the "monopolist", try providing a hosted service of their latest release and see how they react. It doesn't matter if you've contributed code to ES before, it doesn't matter if you're the most prolific contributor to Lucene.
It doesn't matter if you can build a better version of ES or provide better service. Elastic Co. (and CockroachDB Inc.) will simply not allow you to compete.
----
For once, try pointing the finger fairly, at everyone. Try judging everyone with the same set of laws/morals. Hold your heroes to the same standards, at least, as your villians.
CockroachDB is doing the right thing and I bet ES would have done it much sooner if they had any clue that Amazon is going to screw the small guy.
Also your arguments doesn't make any sense. Lucene is still OSS and OpenSearch is not Lucene but built of Elastic code. They didn't rebuild everything from scratch but literally used the code Elastic wrote.
No one argued OpenSearch is not OSS.
And sorry - if you think Amazon as a company is not screwing the small guy, I feel sorry for you.
Elastic also screwed plenty of small guys to get to where they are. And they're no longer small.
Thank you, I used your twisted logic to arrive at them.
And Elastic is not Lucene but built of Lucene code. So why is it okay for Elastic to build a proprietary package using OSS code, but not okay for AWS to build an OSS package using OSS code?
1. OpenSearch is more than ES Community Edition. OpenSearch does have some code of its own; significant enough to matter. Code that was considered basic featureset that Elastic refused to add, even rejecting PRs. What do you do when your PRs that add significant features are rejected? Especially when the reason is, "because we don't want you to compete with our proprietary packages"? How FOSS is a project, really, when it refuses such PRs?
2. Like Elastic didn't rebuild everything from scratch but literally used the code (as a library) Lucene authors wrote. So why is it morally okay for Elastic to profit off of OSS work they didn't do, but not for AWS to build OSS off of OSS?
You called it 'stolen'. Why is it not stealing when Elastic builds a proprietary package off of OSS code, including code that was donated specifically to be included in an OSS package, when you claim it is 'stealing' to make an OSS package of the same license and with copyright notices preserved from another OSS package.
I know exactly where and how Amazon as a company is screwing the small guys. This is not one of them. This is a field so full of strawmen it is difficult to see where it ends.
Please keep your sympathies to yourself. You need it more than I do right now. If nothing else, then for the simple task of judging your heroes with the same yardsticks as your villians.