We've always been open source, so I'm not sure I understand what this is about! This is linking to our `posthog-foss` repository which has been a thing for years now, it's simply the main repository without the `ee/` folder - which is not a folder we have a lot inside anyways, we've never tried hiding anything behind it intentionally.
edit: the title originally read "Posthog has been open-sourced" but it's now updated to better reflect what this is about, thanks mods!
Presumably so folks can be sure they're not accidentally pulling in proprietary code.
> This repo is available under the MIT expat license, except for the ee directory (which has its license here) if applicable.
> Need absolutely 100% FOSS? Check out our posthog-foss repository, which is purged of all proprietary code and features.
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.
It's still great to make the code open, but it's not usable anymore for a self-hosted setup.
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.
I think is a bit of product slopification.
IDK what the prior AI behaviors have been, but for me, what they have now is an ~idealized version of AI product.
It is basically what I'd do if they didn't offer it but not as well: export data, import their docs in md., import some industry best practices in analytics into context etc.
Except its all right there. Not sure of the economics of it, as it was on a free account and some reasonably good model was powering the discussion. But it was about as engaged as I've been with an analytics tool.
To each his own though.
Also i don't like how "People" is not buried in data now, pretty sure this was just in the left hand bar. I can "star" it, but its still nested in a wierd UI drawer. I wish it was pinned by default, or a way I could re-pin it.
A message of some kind (You may have already done this) to accept the new defaults or keep the some of the original defaults would of been cool.
On a broader note, I loved the simplicity of what you guys made, and it feels like the product has too many moving pieces available to me. I build my own product as well and I get the rub here, you want to support so many more use cases and re-organize things to do so , but in the end it feels bloated. I love the idea of using AI and in some cases when i needed to mine my data some it was super nice, though most of the time from a founder perspective I'm looking at largely the same data/metrics over and over, and don't need to be creating new graphs every day. So the launchpad /w chatbox as the primary thing as a default feels a bit lost on me.
All that said, I still looooove your product and would still use it 1100 times over GA any day. <3
I also agree that the nav, structure, and defaults changing keep being un-intuitive and are making it harder to find the things that I use and that matter to me and my orgs.
That has changed though. Last time I used PH, I found myself not finding the things I needed so ended up connecting the mcp and asking claude to change things for me.
MCP was a nice addition, so thanks for that. The problem of mcp is that it prevents product discoverability. You are adding many things lately and since I'm using the MCP for my "part of the job" I will never visit your site anymore and see what's new.
On the server side, queue all analytics call and run them after the main request completes (on next.js it would be within an after() function on the server side).
You can paste this comment into Claude and it should handle the refactor just fine.
Note with the changes in analytics scheduling, you will lose out on real time analytics in favor of better time to first load. So keep the trade-off in mind.
Please update title accordingly.