toddpersen

Congrats to Richie and Ryan for building so much momentum in a short period of time!

Era Software | Multiple Roles | Full-time | Anywhere | 100% Remote | https://era.co

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 hiring for multiple roles:

* Database Engineer (Rust, distributed systems, k8s)

* Full-Stack Engineer (React, Golang, NodeJS, NextJS, TypeScript, Cypress)

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.

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.

<shameless-plug>

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. ;)

</shameless-plug>

Oh, hey! Nice to have at least one person here that isn’t going to jump on the AGPL bandwagon. ;)

Would Torkel have decided to fork Kibana in the first place if it were AGPL?

Would the same level of community have formed around Grafana?

Would it have received as many contributions and support for new backends?

Would Raj have wanted to acquire Torkel + Grafana for the original Raintank company if it were an AGPL project?

Would they have been able to as successfully build and monetize a Grafana Enterprise product with the requirements of AGPL in place?

It seems naive to argue that none of those would have been impacted by a more restrictive license.

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.

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...

Anyone want to guess what the third commit was? That's right, it was an Apache 2 license: https://github.com/grafana/grafana/commits/master?after=2bb7...

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.

And for historical fun, here's the first commit from Torkel after the fork from Kibana v3: https://github.com/grafana/grafana/commit/50e42c8bdd2099552d...

Also, as soon as this PR is merged, there will be a Homebrew recipe available on OSX: https://github.com/Homebrew/homebrew/pull/40878

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.