It's also worth noting that in 2023 they abandoned their Kubernetes support which was relied upon by a full 3.5% of their users: https://posthog.com/blog/sunsetting-helm-support-posthog

In their rationale for this:

> We also learned that the tools to do that automation just don't exist. We kept finding new failure modes. When onboarding a new customer we would have to vet their engineering team for Kubernetes experience so that we'd be confident they could help us debug issues in their PostHog deploy. Folks that didn't have infra experience would often be able to get something set up, only to get stuck when something went wrong.

I empathize that this is a sane choice for PostHog to make as a business. But - if you can't deploy and dogfood your changes, are you truly able to maintain a fork with customizations? And if you can't use your own changes, is the software open-source, or source-available?

Perhaps the punchline is that any scalable & performant web analytics platform must necessarily be a distributed system of ingestion and storage services, and that complexity is like oil and water with the classic "you should be able to swap out the dependencies on your systems with ones you fork" open-source ethos.

PostHog had an opportunity to break this trend, to innovate and invest in those automations they correctly said didn't exist - and I was cheering them on. I've been saddened to see them move in the opposite direction.

Agreed, I tried self-hosting it a couple of month ago and it was impossible. I spent the day on it but the setup process was broken because of a recent change which was made for their cloud offering. Managing both a codebase both adapted to a cloud deployment with a huge amount of users and to a self-hosted way small deployment is very hard and requires a lot of resources. It's hard to justify investing this much time and money in making it work well for a self-hosted setup, and it seems like they stopped doing so.

It's still great to make the code open, but it's not usable anymore for a self-hosted setup.

I think posthog is one of these businesses where the COSS model does not work well.

COSS works well when there is a large distribution advantage of being OSS. This could be bacuse a large portion of users (need to) self-host the solution. This is true for databases, people will always need to self-host dbs (e.g. as part of their docker compose in dev, etc...). These people are also hard core engineers that will 1) talk about the db and 2) contribute to the project. So an OSS db have a large network effects and distribution advantage.

Posthog had a distribution advantage from OSS in their beginnings -- their beachhead was the self-hosting oss community. Now, it does not add much value -- It's unlikely Github adds much for their distribution. So, it does not make sense for them to do much more than just maintain it lightly. In fact, they try to push you from self-hosting by having great free tiers and startup programs.

They want you to buy their hosted service, that's where the convenience is sold. If they give you a one liner script you can paste in or a docker compose that does everything from scratch they cannot sell their hosted services.

It seems like an odd thing to run locally with so many dependencies.

we went from batteries not included to BYOAi

Would love for you to try Amplitude. We've put a lot of work into making sure the core is usable. We've also started to fix a lot of the most common complaints about our pricing.