[jauntywundrkind]

InfluxDB 3 just went alpha, and they similarly have very severe limitations on what their open-core product will do, very strongly drive folks to upgrade to enterprise.

https://www.influxdata.com/blog/influxdb3-open-source-public... https://news.ycombinator.com/item?id=42684524 https://news.ycombinator.com/item?id=42703113

While I admit that I don't think losing open source developers is actually that big a harm to many projects (there's just not enough people out there to drive by big valuable amazing features), I feel like the open core approach shuts yourself off from most people who are looking for open source solutions. The core is not enough.

No one's going to be happy running a 500x slower python project knowing there's the real deal running elsewhere, with a hip new runtime they can't get.

I recognize that for some of these companies, this probably is a necessary move. They need revenue to do what they do and it's hard to get revenue in open source. But these are both interesting products that I was hopeful for that I can't imagine adopting anymore. That's fine, I don't demand being served by anyone, but it is really sad to see, and I wonder how many awesome projects that would have grown big stop these technologies will never be created, because of these shifts.

Matrix especially feels like a brutal loss, because we are so short of good communication systems. I regret not seeing DataFusion & Arrow being out to use & integrate on with InfluxDB 3 but at least there's a lots of time-series databases available. Matrix's whole ecosystem has been slowly slowly slowly building momentum & acceptance, but there's so much less diversity & offerings, & that now Synapse Pro is needed if you want more than a simple instance.

[pauldix]

Our intention with InfluxDB Core is that it's useful to large audience. Just not the group of people seeking a historical TSDB. It's a collector, processor, and recent data TSDB. If you're familiar with the TICK stack from our 1.x line, it's like Telegraf (the data collector), Kapacitor (the processor and monitoring agent), and an InfluxDB that is better on the most recent data.

The InfluxDB part of it is more narrowly scoped than previous versions, but the Telegraf and Kapacitor parts are much more feature rich than those previous products.

[Arathorn]

woah there - hang on a sec

> No one's going to be happy running a 500x slower python project knowing there's the real deal running elsewhere, with a hip new runtime they can't get.

What if the current python project got 500x faster in general? As optimisation work for Synapse is not being paywalled - it’s just the worker scalability, which is not a bottleneck for normal sized servers anyway.

The reason Matrix servers are typically slow today is that state resolution and storage is algorithmically slow; federation is fullmesh and doesn’t support “thin server” approaches for participating in busy rooms, and joining big rooms still blocks on loads of state being synchronised before you can see other members & history.

Fixing this (and more) is very much on the menu for FOSS Synapse - and won’t be helped by faster workers, given workers are just for scalability, not for core performance. Conversely, $ from Synapse Pro will hopefully fund that work, which otherwise has been stuck for years now thanks to lack of $.

(Also: if you did decide Element had gone mad and don’t want anything to do with Synapse, you can try a different homeserver like one of the Conduit forks; don’t throw Matrix under the bus with Element :)