Which means that these new ALv2 forks will produce respectively the elasticsearch-oss and kibana-oss rpms that OpenDistro plugins are based upon, right?
That would allow the community members that are solely interested on Elasticsearch and kibana core to contribute on the ALv2 forks regardless of OpenDistro plugins that flavors them on top.
Maybe it’s too early to ask, but is there already some interest shown around this effort, or we run the risk of multiple independent forks that can potentially just split the community (e.g. logz.ioexpressed their interest to fork )
We are working with AWS and many other companies to create the community around this hopefully without fragmentation. I have another call with AWS folks on Monday to hopefully discuss some governance, naming, and other ideas around where we believe this should go. I will keep monitoring this and collecting interested folks in our sheet. If you are interested you can fill out this form: ElasticSearch and Kibana Open Source Community Participants or just email us at open-es-k@logz.io and we will be sure to notify you when the community gets going. We will also post on this forum, twitter, reddit, and other places where the community lives today.
@spapadop Correct. Individual repos, so you could definitely run them without any Open Distro plugins.
It’s open source, so if someone wants to fork from this, they are free. However, working together would be more advantageous for everyone, I would think.
@searchymcsearchface thanks, I’m with you on that, of course. The only real question is what happens with governance, both for the new Elasticsearch/Kibana forks and for OpenDistro plugins. I don’t want to question AWS commitment to a forever-ALv2 project, but business is business and sadly promises can fly away anytime. Anyways, we’ll be awaiting for further news/updates, looking forward to bring this forward!
@spapadop I hear you. We haven’t worked that out but it’s definitely on our minds. Governance is not something you work out over the span of a week and not something you do alone.
A few of my own thoughts, ELK user and tech adviser. I recommended ELK long time ago, and now am pretty embarrassed by the vendor lock-in I’ve put my collegues into.
Nice to see this post does not goes to much in name calling, and finger pointing like the other one side. Second part goes a bit too much in that path, which is unfortunate.
Please lets put emotion away and do as much transparency and openess as possible. This is the only way we can exit this trust crisis.
I wonder why you take grafana as a succesful fork project example. Not sure if that is really a fork. The blog post does not really suggest that, the current code does not either afaics.
Jenkins is for me a good example of successful. Of course each side is calling the other the fork. If you clone yourself, both end will truly believe they are “the real one”. That will happen for this project, obviously.
Mariadb is for me a really good example of a successful community fork. Mysql is still very much alive for those who want Oracle support.
I really would like this new project follow the path of mariadb
@tardyp Grafana was originally a fork of Kibana, and then each went their own way. Today they are very dissimilar, largely due to Kibana being almost completely rewritten. Nonetheless, Grafana was a fork.
As you mention MariaDB is another example of a successful fork.
I can’t imagine how confusing it would be to call it the Elasticsearch fork. Going forward it is very likely to assume the functionality will diverse and that the code and modules will be structured differently. It is not realistic to assume any project / product from this fork will be compatible with future Elastic’s products (e.g. Kibana fork talking to future Elasticsearch from Elastic, Elastic’s Elasticsearch client talking to this Elasticsearch fork, … etc). If one of the main reasons behind forking is to enable inovations then sooner or later the interfaces will not be compatible (and that is not a bad thing!).
Going forward the name must change, including all opendistro plugins, forums, … etc. IMO this should happen before the very first fork repo is made public.
Second, the need of NEUTRAL governance.
As far as I can tell AWS is now the largest entity investing into forking. Do not get me wrong, anyone making public commitment to build and maintain large open source project and community deserves respect. However, I can imagine that it is natural for AWS to find a legitimate reasons to align some parts of this Elasticsearch fork with some of its cloud technologies / services, and although this is not a bad thing it could put “openess” and “transparency” into question.
I understand it can take time to build or join neutral governance but it is absolute critical goal, and as such this goal should be part of public plan with clearly defined milestones.
Naming is high up on my list to discuss with AWS and our legal teams. I agree it needs to be done pre-launch!
Governance is my #1 concern and discussion item with the team that is coming together. It must be multiple organizations. We actually have interest and participation coming together with several other large organizations. It will not be an AWS initiative as OpenDistro has been. Stay tuned.
Where was that attitude back when you started Elasticsearch, Shay? You could have easily collaborated with Solr back then to make it better, but you chose to go your own way. And you know what? That’s all good, b/c Solr is Apache licensed and built into the Apache license is the idea that you can do whatever the hell you want to do with it as long as you don’t claim you wrote it and you don’t call your thing the same thing as the Apache thing. You full well knew this when you choose the Apache license way back when and if you didn’t, shame on you
Companies who have to litigate to keep market share never last. Besides, are you saying you were never “inspired” by a Splunk feature, your main competitor?
You don’t think I’ve heard the FUD and the outright lies your reps have said? I’m not saying I’m pure here, but gimme a break about casting stones on ethical behavior in your rise to IPO. “He who is w/o sin may cast the first stone…”
I’m very happy to see this moving forward as a community effort, thanks to @jkowall@searchymcsearchface and others for taking this on. I really think this is a win for everyone - the community gets a FOSS distribution, which is no longer driven by Elastic’s profit motivation (yes, it will be partially/mainly driven by Amazon’s instead, but their motivation is to offer a solid core hosted product, not add-ons), and it frees Elastic up to focus on their commercial customers and add-ons (although they probably don’t see it that way, but maybe they’ll come around).
“There were two panels in the first version of Grafana. The graph panel was originally called graphite; it started as a fork of the Kibana histogram panel with built-in support for graphite only.”
Good article, we are focused on license and governance right now as the key areas. I think we have enough folks who want to contribute that are employed by a company or are going to work on it for their own interest levels that it shouldn’t be a problem.
