[kirankgollu]

We don’t have plan to open source at this time. Many observability solutions are closed source. Could you please describe why you would require this to be open source vs open source compatible?

We think Oodle combines the benefits of open source (compatibility, no lock-in) with the operational simplicity, reliability of commercial vendors. Some products might give a false illusion of no-lock in just because it's open source, it wouldn’t mean you don't have lock-ins. We believe what really matters is "Open Source Compatible" - i.e. how easy it is to get in? How easy is it to switch out? (to a de-facto open source standard like Prometheus/Grafana should you need to disconnect ties with the vendor). Security and compliance is the other big part - we are working on adding compliance like SOC2, CCPA etc.

[thinkmassive]

The primary benefit of FOSS is the ability to inspect and patch the software yourself. Another important benefit for any large FOSS project is knowing it’s been heavily reviewed.

Protocol compatibility is a baseline requirement for a drop-in replacement. Without that, your product would need to be like 10x cheaper than Prometheus for anyone to consider devoting engineering resources to switching to it.

Existing FOSS solutions are reliable and inexpensive enough, not even considering the effort and unknowns involved with swapping out a major component of the observatory stack. Between that, your distorted view of open source, and your focus on checkbox compliance, I’m unlikely to ever consider trying your software. I wish you luck though, and I hope you learn more about the value of FOSS.

[kirankgollu]

Thank you for the feedback. we will keep an eye out for more inputs from our users on this topic.

We believe there are clear benefits of open source. In fact, we believe in it so much that we made our product OSS compatible from Day 1. (btw, not every observability product is OSS compatible).

We also understand not everyone's evaluation criteria is the same. Upon speaking with number of our early users, we repeatedly found that what really matters is "is the product reliable, cost-effective?", "is the product easy to use and open source compatible?", "is the product easy to migrate in/out?". So, we tried to address those head on. We also heard some open source solutions are indeed unreliable especially at scale e.g. Prometheus has scaling challenges beyond 2M+ active time series / hour and it is not horizontally scalable. People tend to over-provision CPU/Memory, despite that queries time out at any meaningful scale high cardinality queries (this is a well understood problem).

Ability to inspect code, do patches themselves may be an evaluation criteria for some users, we found that it was not the major evaluation criteria among our users. I've led multiple evaluations at Rubrik (open source + non-open source), ability to patch software was not the most important criteria - reliability, operational overhead, cost, ease of use, and ability to switch in/out were may more important.

[thinkmassive]

I’m curious what you think it means to be "open source compatible"