7 ms·

Full disclosure: This is my tool that I'm using to generate the insights. When OpenSearch was announced, I shared some insights into how both Elasticsearch and

by sdesol 5y ago

Full disclosure: This is my tool that I'm using to generate the insights. When OpenSearch was announced, I shared some insights into how both Elasticsearch and OpenSearch were evolving, and I'll share some more up to date insights here. Looking at recent pull request activity, OpenSearch had 52 contributors https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D120&t=crc-insights&tb=all&v=opensearch-project%2FOpenSearch%3A%3Agithub%3Aopensearch-project%2FOpenSearch%3A%3A%3A%3A https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D... while Elasticsearch had 181 https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D120&t=crc-insights&tb=all&v=elastic%2Felasticsearch%3A%3Agithub%3Aelastic%2Felasticsearch%3A%3A%3A%3A https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D... The metric that I'm most interested in, is knowing how many people committed within the last 14 days compared to those that committed more than 14 days ago. For Elasticsearch, they had 87 contributors which accounts for 68% of all contributors. OpenSearch had 20, which accounts for 67%. With these numbers, I can ball park how many people are working on Elasticsearch and OpenSearch full time and I would say Elasticsearch at the present moment has probably 5 times more people working on it fulltime vs OpenSearch. An important thing to note is, Amazon has other projects that are related to OpenSearch so these numbers don't necessary give the full picture, but it is pretty obvious that Elasticsearch is evolving at a much faster pace and time will tell if they (OpenSearch) can keep up.

TSiege 5y ago
I'll be curious to see what happens as well. I ended up going with Opensearch since I use AWS. I figured I'm already locked in to that environment anyways, so why not
- sdesol 5y ago
  Somebody that does consulting work with Elasticsearch mentioned that they had some pretty innovative features in the pipeline and these are the things that can really pull people away from OpenSearch. It could also be that, people only really want basic search functionality so who knows right :-)
  - deknos 5y ago
    i think that for all the people which just want a logging system in their k8s, opensearch is pretty good. lots of software ist stable and just works. everyone uses bash. let the elastic guys make their new software more shiny, good for them. i am now glad i can use a real opensource version at home and for small to midsized projects. if opensearch won't cut it? no problem, the customer can pay elastic :)
  - nostrebored 5y ago
    I’m increasingly pessimistic on ES as a solution. Everyone is coming to eat their lunch. APM? Datadog. Product search? Algolia. I think the next wave of search tech will be 1. Leveraging automated ingestion optimization. 2. Capable of searching across mixed media: text, audio, images to start out with. This is only possible because of optimized ingestion. The ingestion layer will perform vectorization of the inputs. The vectors will be the entires stored in inverted indices. 3. A great jump from two to an optimized data store for searching mixed media. People obsessing over elastic/splunk features are lost. Nobody will care in 5 years. Both will be legacy enterprise tech.
CSDude 5y ago
Elastic is already a mature product, with little to improve. Even 8.0 release is focused on speed and footprint. Many companies still use 2.x happily. License implications are not worth it.
- dhd415 5y ago
  Having interacted with Elasticsearch a lot, I assure you there is a lot for them yet to improve. Frankly, I think Elasticsearch followed the MongoDB model of "make it easy for developers to adopt and then make it good." MDB did that by making it easy to throw "schema-less" documents into their database and then later working on "advanced" things like avoiding data loss [0]. Elasticsearch did something similar in that you don't have to run a separate cluster coordination server like Zookeeper which Solr requires. It's also easy to get up and running with indexing unstructured data. Running it at scale with heavy workloads? There are still plenty of rough edges there. It's a good way to gain market share and both products have definitely improved, but I wouldn't want my day job to involve the operation of a large Elasticsearch cluster. [0] https://pastebin.com/raw/FD3xe6Jt https://pastebin.com/raw/FD3xe6Jt
  - elesbao 5y ago
    Indeed, there is a lot of room to improve. I managed a cluster that grew from 9 to 40 then to 60 EC2 Servers over 2 years, with all updates and support we could afford. It was a a nightmare to manage. The amount of cluster rebalancing, magic nodes that claim to be leader and then do not behave like it is amazing. I don't want ever to get back managing it again. Last thing I did (ES7 at the time) was to split the cluster in many smaller clusters, reimplement all counters on relational databases and use as little of ES as possible. As a former colleague used to say: Elasticsearch is MongoDB for people ashamed of using MongoDB. Hope AWS and Elastic tension helps them to do a better job there.
    - rmbyrro 5y ago
      Curious, I never came across someone using ES as a replacement for Mongo.
myroon5 5y ago
Can see the number of commits drastically drop off where OpenSearch forked Elasticsearch: https://github.com/elastic/elasticsearch/graphs/contributors https://github.com/elastic/elasticsearch/graphs/contributors https://github.com/opensearch-project/OpenSearch/graphs/contributors https://github.com/opensearch-project/OpenSearch/graphs/cont... Over an order of magnitude more development on Elasticsearch than OpenSearch since that fork
- sdesol 5y ago
  Here's the activity difference for the last year repo | commits | authors ------------+---------+--------- elastic | 2719 | 179 opensearch | 265 | 54 Here's a breakdown based on commits with at least 15 lines of code churn (lines added, changed or deleted). repo | commits | authors ------------+---------+--------- elastic | 1681 | 122 opensearch | 153 | 41 What is interesting about these numbers, is they clearly show a lot of people (57 authors) took the time to create a small pull request, which goes to show how popular the project is.
  - cancomposeup 5y ago
    I think part of the challenge looking at these metrics is the project versus repo structure. For instance, contributions to security are included in the elasticsearch repo but not in the core OpenSearch repo e.g. https://github.com/opensearch-project/security/graphs/contributors https://github.com/opensearch-project/security/graphs/contri... But I still think having a bunch of folks contribute isn't trivial and worth highlighting (57 is a ton for many projects) and anytime I see a truly OSS project at this scale I think it's a good thing.
    - sdesol 5y ago
      > I think part of the challenge looking at these metrics is the project versus repo structure For my tool, I can analyze any combination of repositories so getting the bigger picture isn't challenging. Out of curiosity, I decided to index all the opensearch repos which will take a few hours to index and I'll update this post if I can or just reply to it when the other repos have been indexed.
jillesvangurp 5y ago
Thanks for gathering some data here. Very insightful and it confirms some suspicions I've had. I'm one of the people that is no longer creating pull requests for Elastic. I was never a big contributor and I only did a handful of small PRs. But all little bits matter and I was OK with doing that under the Apache 2.0 license and putting my time in and doing my small part. That's not a thing for me anymore. I charge money for commercial software development. In practical terms, I now have to worry about supporting both Elastic and Opensearch as a consultant (always looking for new customers to help, if you need some advice) and I can't really recommend people stick with Elastic with a straight face either because Opensearch really is a decent alternative and increasingly the default for new users; as I have noticed with my own customers. I maintain a Kotlin client for Elasticsearch and I have started work on making that work for both Elasticsearch 7, 8 and Opensearch; something that is complicated by the fact that Elastic intentionally made sure their Java client (which I depend on) no longer talks to opensearch. They also deprecated it and introduced a completely new one recently. And of course the recently released Elasticsearch 8 complicates things with a few new features, compatibility breaking changes, etc. On top of that, Opensearch is starting to get its own features or alternatives to Elastic-only features. I agree that the momentum is still with Elastic but it is not the case that Opensearch is a dead fork. I know of several people that quit their jobs at Elastic because of the license change and that are now working on Opensearch or on Opensearch plugins. It will be interesting to see how the two forks evolve. IMHO, the license change is long term a mistake for Elastic. They've cut themselves off from open source contributors who can still contribute to making Opensearch, Lucene, or Solr better. So, that's long term not going to be helpful. Elastic has always leaned on opensource heavily for contributions and hiring. A lot of their early hires came from the Lucene community and the many researchers contributing to that and later from people contributing to Elasticsearch. Additionally, a lot of value gets added to the ecosystem by OSS plugins. The authors of those now have to choose between Opensearch and Elastic. That's long term not good for Elastic as a lot of cutting edge stuff usually starts in the plugin community. I don't necessarily like what Amazon did but I do think they did it the right way from the point of view of creating a credible alternative. And I think that the way Elastic responded to that is throwing out the baby out with the bathwater. Perhaps the most striking statistic is that the total number of PRs for both combined declined: everybody loses. IMHO, they should just roll back the license change and grow their community rather than fragmenting and shrinking it. Amazon is going to get some of their customers either way. I actually think the fork is working out better for Amazon than it is for Elastic currently. It was a mistake. Amazon is not the most likely steward of open source. But stranger things have happened. Take MS in recent years for example. It's a sound business strategy to not piss off OSS developers. Elastic would do well to take note of that.
snoopdog23 5y ago
I believe Amazon does most of their current feature development in separate repositories for their plugins whereas Elastic has their plugins (x-pack) merged into their core repository. Would be interesting to see that taken into account too (along with the actual lines committed, i.e. 10 commits vs 10 commits but one has 10x the code).

by sdesol 5y ago

TSiege 5y ago

I'll be curious to see what happens as well. I ended up going with Opensearch since I use AWS. I figured I'm already locked in to that environment anyways, so why not

sdesol 5y ago
Somebody that does consulting work with Elasticsearch mentioned that they had some pretty innovative features in the pipeline and these are the things that can really pull people away from OpenSearch. It could also be that, people only really want basic search functionality so who knows right :-)
- deknos 5y ago
  i think that for all the people which just want a logging system in their k8s, opensearch is pretty good. lots of software ist stable and just works. everyone uses bash. let the elastic guys make their new software more shiny, good for them. i am now glad i can use a real opensource version at home and for small to midsized projects. if opensearch won't cut it? no problem, the customer can pay elastic :)
- nostrebored 5y ago
  I’m increasingly pessimistic on ES as a solution. Everyone is coming to eat their lunch. APM? Datadog. Product search? Algolia. I think the next wave of search tech will be 1. Leveraging automated ingestion optimization. 2. Capable of searching across mixed media: text, audio, images to start out with. This is only possible because of optimized ingestion. The ingestion layer will perform vectorization of the inputs. The vectors will be the entires stored in inverted indices. 3. A great jump from two to an optimized data store for searching mixed media. People obsessing over elastic/splunk features are lost. Nobody will care in 5 years. Both will be legacy enterprise tech.

CSDude 5y ago

Elastic is already a mature product, with little to improve. Even 8.0 release is focused on speed and footprint. Many companies still use 2.x happily. License implications are not worth it.

dhd415 5y ago
Having interacted with Elasticsearch a lot, I assure you there is a lot for them yet to improve. Frankly, I think Elasticsearch followed the MongoDB model of "make it easy for developers to adopt and then make it good." MDB did that by making it easy to throw "schema-less" documents into their database and then later working on "advanced" things like avoiding data loss [0]. Elasticsearch did something similar in that you don't have to run a separate cluster coordination server like Zookeeper which Solr requires. It's also easy to get up and running with indexing unstructured data. Running it at scale with heavy workloads? There are still plenty of rough edges there. It's a good way to gain market share and both products have definitely improved, but I wouldn't want my day job to involve the operation of a large Elasticsearch cluster. [0] https://pastebin.com/raw/FD3xe6Jt https://pastebin.com/raw/FD3xe6Jt
- elesbao 5y ago
  Indeed, there is a lot of room to improve. I managed a cluster that grew from 9 to 40 then to 60 EC2 Servers over 2 years, with all updates and support we could afford. It was a a nightmare to manage. The amount of cluster rebalancing, magic nodes that claim to be leader and then do not behave like it is amazing. I don't want ever to get back managing it again. Last thing I did (ES7 at the time) was to split the cluster in many smaller clusters, reimplement all counters on relational databases and use as little of ES as possible. As a former colleague used to say: Elasticsearch is MongoDB for people ashamed of using MongoDB. Hope AWS and Elastic tension helps them to do a better job there.
  - rmbyrro 5y ago
    Curious, I never came across someone using ES as a replacement for Mongo.

myroon5 5y ago

Can see the number of commits drastically drop off where OpenSearch forked Elasticsearch: https://github.com/elastic/elasticsearch/graphs/contributors https://github.com/elastic/elasticsearch/graphs/contributors https://github.com/opensearch-project/OpenSearch/graphs/contributors https://github.com/opensearch-project/OpenSearch/graphs/cont... Over an order of magnitude more development on Elasticsearch than OpenSearch since that fork

sdesol 5y ago
Here's the activity difference for the last year repo | commits | authors ------------+---------+--------- elastic | 2719 | 179 opensearch | 265 | 54 Here's a breakdown based on commits with at least 15 lines of code churn (lines added, changed or deleted). repo | commits | authors ------------+---------+--------- elastic | 1681 | 122 opensearch | 153 | 41 What is interesting about these numbers, is they clearly show a lot of people (57 authors) took the time to create a small pull request, which goes to show how popular the project is.
- cancomposeup 5y ago
  I think part of the challenge looking at these metrics is the project versus repo structure. For instance, contributions to security are included in the elasticsearch repo but not in the core OpenSearch repo e.g. https://github.com/opensearch-project/security/graphs/contributors https://github.com/opensearch-project/security/graphs/contri... But I still think having a bunch of folks contribute isn't trivial and worth highlighting (57 is a ton for many projects) and anytime I see a truly OSS project at this scale I think it's a good thing.
  - sdesol 5y ago
    > I think part of the challenge looking at these metrics is the project versus repo structure For my tool, I can analyze any combination of repositories so getting the bigger picture isn't challenging. Out of curiosity, I decided to index all the opensearch repos which will take a few hours to index and I'll update this post if I can or just reply to it when the other repos have been indexed.

jillesvangurp 5y ago

Thanks for gathering some data here. Very insightful and it confirms some suspicions I've had. I'm one of the people that is no longer creating pull requests for Elastic. I was never a big contributor and I only did a handful of small PRs. But all little bits matter and I was OK with doing that under the Apache 2.0 license and putting my time in and doing my small part. That's not a thing for me anymore. I charge money for commercial software development. In practical terms, I now have to worry about supporting both Elastic and Opensearch as a consultant (always looking for new customers to help, if you need some advice) and I can't really recommend people stick with Elastic with a straight face either because Opensearch really is a decent alternative and increasingly the default for new users; as I have noticed with my own customers. I maintain a Kotlin client for Elasticsearch and I have started work on making that work for both Elasticsearch 7, 8 and Opensearch; something that is complicated by the fact that Elastic intentionally made sure their Java client (which I depend on) no longer talks to opensearch. They also deprecated it and introduced a completely new one recently. And of course the recently released Elasticsearch 8 complicates things with a few new features, compatibility breaking changes, etc. On top of that, Opensearch is starting to get its own features or alternatives to Elastic-only features. I agree that the momentum is still with Elastic but it is not the case that Opensearch is a dead fork. I know of several people that quit their jobs at Elastic because of the license change and that are now working on Opensearch or on Opensearch plugins. It will be interesting to see how the two forks evolve. IMHO, the license change is long term a mistake for Elastic. They've cut themselves off from open source contributors who can still contribute to making Opensearch, Lucene, or Solr better. So, that's long term not going to be helpful. Elastic has always leaned on opensource heavily for contributions and hiring. A lot of their early hires came from the Lucene community and the many researchers contributing to that and later from people contributing to Elasticsearch. Additionally, a lot of value gets added to the ecosystem by OSS plugins. The authors of those now have to choose between Opensearch and Elastic. That's long term not good for Elastic as a lot of cutting edge stuff usually starts in the plugin community. I don't necessarily like what Amazon did but I do think they did it the right way from the point of view of creating a credible alternative. And I think that the way Elastic responded to that is throwing out the baby out with the bathwater. Perhaps the most striking statistic is that the total number of PRs for both combined declined: everybody loses. IMHO, they should just roll back the license change and grow their community rather than fragmenting and shrinking it. Amazon is going to get some of their customers either way. I actually think the fork is working out better for Amazon than it is for Elastic currently. It was a mistake. Amazon is not the most likely steward of open source. But stranger things have happened. Take MS in recent years for example. It's a sound business strategy to not piss off OSS developers. Elastic would do well to take note of that.

snoopdog23 5y ago

I believe Amazon does most of their current feature development in separate repositories for their plugins whereas Elastic has their plugins (x-pack) merged into their core repository. Would be interesting to see that taken into account too (along with the actual lines committed, i.e. 10 commits vs 10 commits but one has 10x the code).