toddpersen
Joined 14 years ago
Joined 14 years ago
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 [email protected].
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 [email protected] - 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>
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.
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.
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...