For many years we explicitly denied any startup that was already launched.
This was back in the day where most startups had a long "pre-launch" phase where they would be collecting user feedback through private betas, etc before launching publicly.
I wanted BetaList to be focused on early-stage startups and to avoid a lot of debates about what is and isn't "early-stage" I decided on that clear policy.
We also denied startups for other reasons such as using an over-used homepage template (they never converted well for our audience as they'd see the same one multiple times a week) or simply having a dime-in-a-dozen product (which also didn't get many signups when featured on BetaList).
This is an interesting approach especially if you factor in that re-minting a key is usually a lightweight task compared to what most API calls have to interact with.
If the re-minting happens transparently with a user interaction then you spread out some of the request velocity that can come with that (if you're operating at a large enough scale for it to matter for this to be a concern).
Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
I've been using calendar versioning quite happily with my mobile apps for a while now. It reduces the amount of angst and bike-shedding that comes along with otherwise rev'ing a major version number.
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
Ah, I was using GH's webui instead of downloading to view the PDF and it stopped loading at slide#47...rereading it now paints a much better picture. Thanks!
Is it too much to ask for a not-vibe-coded billing system? In my opinion, we need better systems to hold these companies accountable as I don't believe the $20/dispute they're paying means much given how common other customers are complaining about billing irregularities just in this thread alone.
Is there a name for the practice of embedding a completely unrelated video into the middle of an article? I find this practice to be so mystifying. Does that work on readers?
Fairly accurate, you can only get support if you're using their cloud product.
"We no longer support paid, open-source deployments and it is no longer possible to buy licenses for self-hosted versions - we instead recommend migrating to PostHog Cloud." - from: https://posthog.com/docs/self-host
OP's ask was: "Is this another one ... where open source is used more as a marketing gimmick"
My original comment wasn't intended to indicate that there is an obligation to provide support. The deliberate choice to: a) not offer paid support for open-source deployments, and b) sunsetting the Kubernetes deployments in favor of their cloud version, is a signal that shows PostHog doesn't /really/ want you to be running the software in a self-hosted manner.
Just look at the "Open-source hobby deploy" (from the README in git) which calls out that it "should scale to approximately 100k events per month" but their cloud offering gives you 1 million events per month for free. What is the point of the hobby "deploy"?
Back to OP -- my answer is yes, this is a source-available service that you can modify and play around with locally. The source and documentation behind the operations of PostHog aren't available.
The math didn't add up for us (I work at PostHog). At the rate we were scaling, we would have needed an entire call center's worth of highly trained Kubernetes support engineers to debug everyone's "my pods just died" / "Kafka just stopped" / "what is Zookeeper" problems.
This stack isn't straightforward to manage, and we couldn't crack the code of doing it at scale for other people without even having access to their systems. There was no malicious intent.
I disagree with the notion that oss is used as marketing bait.
a) offering paid support for bespoke selfhosted installations is an entirely different business model than building a managed service on your oss offering
b) maintaining k8s/helm charts is work - who is paying for that? The selfhosting users certainly aren’t and usually contributions are not enough and even then still need reviews.
You think it’s a deliberate choice.
Yes it’s the choice between going out of business and continuing.
Could you share why?