Era Software’s flagship product is EraSearch, an observability and analytics platform that provides a low-cost, high-performance log management experience on workloads of any size. We give our users real-time visibility into all their log sources without sacrificing retention or suffering through the operational complexity of other products.
We’re a fully-distributed team that thrives on solving hard problems at petabyte scale. We cover 100% of employee benefits and have a 401(k) with company match, offer a generous home office stipend, and sport an unlimited vacation policy.
You can apply for the above positions at https://era.workable.com or send us a note at careers@era.co.
Former co-founder and CTO of InfluxData here, currently building a new company in this space. My strongly-opinionated view on this is that Elasticsearch is not a time-series database and asking it to handle large volumes of logs (fundamentally a time-series use case) is always going to be painful and expensive.
We've built a product called EraSearch that mimics the Elasticsearch APIs for ease of integration but is built with a significantly more efficient (read time-series) architecture. We can handle ingest volumes with about 1/10th of the hardware required for Elasticsearch while still offering comparable (or faster) query performance. If you are generating large amounts of logs (~1TB per day or more), my guess is that this will resonate with you.
If any of this sounds interesting, drop me a note at todd@era.co - I'd love to hear more about your use case. Or even if you just want to talk about time-series data, I'm game. ;)
We've actually been doing some internal work with OpenTelemetry and Jaeger - we would love some feedback on it. Drop me a note at todd@era.co and we can get you set up with a demo instance.
The funny thing to me, which I haven't seen anyone else mention yet, is that way, way back in the old days, Grafana started out as a fork of Kibana. Go take a look at the first commit in the Grafana source:
https://github.com/grafana/grafana/commit/75d03fc49ab4f95ee4...
Before there was any code, there was a permissive license. If the choice had been made 8 years ago to make Kibana less-permissively licensed, it's very likely Grafana wouldn't exist right now.
> If Kibana had been an AGPL project, would Grafana even exist? Are we being hypocritical?
> I asked Torkel, and he said that If Kibana had been an AGPL project, Grafana would likely have been AGPL from day one.
> This is of course a hypothetical question, so it’s difficult to determine how that would have affected subsequent business decisions the company might have made.
> Making business decisions to increase the likelihood of commercial success of our company while also supporting the health of our thriving Grafana community on the basis of new information and an evolving situation is not hypocritical.
IMHO, his answer doesn't address the GP’s point; that the original, permissive license inherited from Kibana arguably enabled the growth & survival of Grafana.
But the point is that they acknowledge that they forked Kibana and why. It’s no different than if someone forks Apache code to form a proprietary software company. The permissive license contributed to the success of many companies. They further acknowledge that Apache based Grafana can be forked too, but they’re betting on themselves to continue to succeed long term by focusing on good software, branding and community. The GP’s point seemed to indicate that “no one” acknowledged the Kibana origins when in fact Grafana themselves have.
You're right - I hadn't seen that in the Q&A, so I appreciate you pointing it out.
Listen, at the end of the day, it's their legal right to choose the licensing strategy that they think is right for their business, shareholders, employees, customers, peace of mind, etc. I feel like asking if it's hypocritical is a bit of a straw man, though. It's not hypocritical per se - I just feel that it's a bit disingenuous to say "hey, we have this large, successful business to protect" without also openly acknowledging that it may never have existed without the tailwinds of an era where the open source community embraced permissive licenses. Simply dismissing the question as "hypothetical" is what I take issue with.
Also, I see your shiny, new account and feel it's likely that you are really just here to defend Grafana. I get it. I don't think this change is a bad idea, necessarily. I just want some of these licensing shenanigans to be more brutally honest.
> IMHO, his answer doesn't address the GP’s point; that the original, permissive license inherited from Kibana arguably enabled the growth & survival of Grafana.
Why's that? If Kibana had been AGPL and Grafana had been AGPL from day 1, how would the growth and survival of Grafana have been any different?
The Grafana Enterprise point is the most salient here. The answer is no, they wouldn't have been able to create closed source plugins for a commercial product. Only AGPL code. As I've stated before: copyleft licenses are an evolutionary dead end: https://www.influxdata.com/blog/copyleft-and-community-licen....
Many companies ban agpl code, this came from legal and is taken seriously by business. Ops guy says it won't touch anything else, business says don care no.
I think I'm right in saying that, providing you fork from any commit before the introduction of the AGPL license, you can continue with Apache-licensed Grafana. Sounds like the way forward.
They amount to the same thing. A git repo is an historical document. All commits (and forks) up to the one changing to the new license "going forward" are available under the original license.
Yeah, that's pretty speculative to assume what would have been, but forking and improving/shifting direction of kibana would have been definitively possible from a license POV.
Their FAQ even says:
> I asked Torkel, and he said that If Kibana had been an AGPL project, Grafana would likely have been AGPL from day one.
i wonder how much of that original Kibana code remains today (my guess is not very much), and if it were originally AGPL, would a completely rewritten codebase still be subject to it?
The license talk about derived work. And even if every line of code has been changed, it is still a derived work as it was progressively changed. So pattern and desings from the original are still in use. The Ship of Theseus is still the Ship of Theseus.
> The Ship of Theseus is still the Ship of Theseus.
you state this as if it's a settled fact (it isn't).
If you take a Shakespeare novel and replace every word in it with another word, and then remove and add many chapters to it, then shuffle all the pages, is it still a Shakespeare work or even recognizable as being derived from one? I think most would say "no".
In the case of Ship of Theseus, if you replaced every part with a different looking part, removed 30% of the parts entirely and added another 300% parts such that the function was expanded by 1,000%, would anyone recognize it as the same thing?
There has to be _some_ threshold beyond which you cannot reasonably claim the work is derivative.
If version B is modified from version A as a derivative work (therefore licensed as A) and version C is modified from version B as a derivative work of B, then would C not still be licensed same as B, and therefore A?
It seems it depends on how you view the accumulation of differences. If your only comparison is always against version A, then yes, eventually there must be enough accumulation of differences that one could claim a work is no longer derivative. But if you consider all versions between A and yours, then suddenly its just a series of gradual changes, none of which individually cause the work to become non-derivative. The Ship of Theseus parable seems to also fit this latter interpretation more -- it is after all about replacing items one at a time.
I agree with you from a practical legal point though. My argument above seems to imply that there's only been derived work since the first cell split in two. In practice this would be a nightmare; There should be a threshold whereupon a work can qualify on its own merits.
> it is still a derived work as it was progressively changed.
I think that depends. If it was progressively changed to something completely different, then, no.
Let's say in 10 days you replaced 10% of the code, with the same amount of code from a different program by another author. During those 10 days there'd be compilation errors, and thereafter the original work and copyright would be all gone (except for in old revisions in the repo), and the copyright holder of the new program could license it however s/he wanted.
It is still likely a derived work. Looks more to me in the example it was just practised the right to make changes to the original work which one could do under the given circumstances which is normally a reciprocal license - floss or else - which means even when if 100% of all letters in all files have been changed, one could still not do more than the original license granted.
and that is normally _not_ what you wrote:
> the copyright holder [sic!] of the new program could license it however s/he wanted.
However if sole copyright holder - real, not imagined - she sure can license it - or not. Or different another day.
Chiming in with a definite bias. I'm one of the co-founders of InfluxDB, and while we're still somewhat young, we actually just hit the 1-year anniversary of our first commit today. We're currently a team of 5 full-time developers, dedicated to making InfluxDB the best time series database available. We've also got some strong institutional backing, so we're not going anywhere for a very, very long time.
If there are any questions we can answer to help you make a more informed decision, drop us a line at support@influxdb.com or reach out to the community: https://groups.google.com/d/forum/influxdb
Currently, the conditions are user-defined on a per-metric basis. Future versions of the agent will calculate a baseline for each metric and use that as a means of performing automatic anomaly detection.
Those are both good questions. Currently, we're a team of two trying to maintain and evolve a production application. Believe me, we'd both love to have spent more time pushing the ball forward on Ember Data, but it just wasn't feasible. Besides, it's already on a maturation path that will resolve all of the issues before long - it just needs a little more time.
In the meantime, we're just keeping it simple and making magic with D3 and plain jQuery. We pushed all of the CRUD back to Rails, which is probably where it should have been in the first place.
Regardless, it was a great learning experience. I still highly recommend giving Ember a shot on something that's not on a tight deadline to get deployed to production.
