Hey, Rafa from PostHog here :)

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!

• thatxliner

  today at 5:49 PM

  Oh thanks for the clarification

Open sourced ?! I believe it was open source from day one.

Does anyone know what the context for this is? Because https://github.com/PostHog/posthog exists as well

• lfittl

  today at 2:53 PM

  My assumption is that its based on that repo but with the "ee/" folder removed, per https://github.com/PostHog/posthog#open-source-vs-paid

  Presumably so folks can be sure they're not accidentally pulling in proprietary code.

• theHocineSaad

  today at 4:40 PM

  From the repo's about section: PostHog FOSS is a read-only mirror of PostHog, with all proprietary code removed. NOTE: This repo is synced automatically from the main PostHog repo. Please raise any issues and PRs there.

• eightysixfour

  today at 2:53 PM

  From the repo you linked:

  > 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.

• carimura

  today at 2:56 PM

  The PostHog Enterprise license (the “Enterprise License”)

  • coloneltcb

    today at 3:30 PM

    Open* is not Open

Last time I checked, Posthog self hosted was basically unusable. They have a hobby deployment script which just pulls the latest build from master which varies from “somewhat works” to “completely broken”

• btown

  today at 4:15 PM

  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.

• geekuillaume

  today at 3:18 PM

  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.

• resiros

  today at 4:41 PM

  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.

• zacksiri

  today at 4:07 PM

  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.

• osigurdson

  today at 4:10 PM

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

• cyanydeez

  today at 3:17 PM

  we went from batteries not included to BYOAi

• sskates

  today at 3:43 PM

  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.

  • lta

    today at 3:58 PM

    How is this relevant ? We're talking about open source analytics, and this looks like a shameless plus

    • ctxc

      today at 4:34 PM

      Yeah weird, bc I just checked and it isn't oss. Only the SDKs are OSS, which...doesn't help much

  • victorbjorklund

    today at 5:17 PM

    So the solution to ”this open source project is really bad at self-hosting” is ”let’s use a 100% proprietary system that does not allow any self-hosting at all”?

I used to like their product but now they too many modules and knobs that I find it difficult to understand and navigate.

I think is a bit of product slopification.

• paularmstrong

  today at 3:49 PM

  They've been using AI to shove a lot of AI into their product and trying to force everyone to use AI. I really don't understand the why of any of it. The product was working great for what it needs to do. I don't need AI to make guesses about data for me and I especially do not want _yet another product_ trying to write features in my codebase (which is their latest push).

  • bredren

    today at 4:30 PM

    I used their AI chat last night and I was impressed with the product implementation. I was able to use it to make quick sense of data and even generate prompts to solve problems locally.

    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.

  • leros

    today at 4:40 PM

    I'm normally not a fan of AI being shoved into products but I love it in PostHog. I can ask it a product question, ask it to slice and dice data, etc and it does a really good job of sifting through my events, doing analysis, building dashboards, etc. It's normally boring tedious work to do that stuff in PostHog so I'm impressed and glad it works.

  • dmix

    today at 4:51 PM

    I recently set up Posthog in production on 3 apps and Posthog's MCP and integrated AI chat were very helpful for onboarding (verifying integrations, setting up and recommending dashboards, debugging an event not being tracked properly, etc).

    To each his own though.

• xtracto

  today at 4:45 PM

  I remember around 2 years ago give or take, we used it at a company for A/B testing. The UI was sensible enough. But fast forward to a couple of weeks ago, I opened an account and I just could not understand what I saw. I remember it being pretty good, too bad the UI got crappified with AI.

• timgl

  today at 3:49 PM

  founder here, what specifically do you use posthog for that you now find hard to find?

  • blueshoe

    today at 4:19 PM

    Couple things for me: - I missed the default dashboard being my homepage and not having to navigate to it via an extra step. I just noticed that i can change that default, but personally found that a bit annoying largely because I felt lost.

    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

    • paularmstrong

      today at 4:27 PM

      It's all the AI bloat for me. It keeps getting shoved in my face and they _really_ want me to use it. But I neither want nor need it. The product itself was so good that it doesn't need this whole guessing-machine-layer on top of it.

      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.

  • heyheyhouhou

    today at 4:35 PM

    I dont think is something in specific but I used to love the simplicity of PostHog and that's why I pushed my team moving to it from Google Analytics.

    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.

    • osigurdson

      today at 5:15 PM

      I've notice that as well. If you don't know how to do something having an agent with tools is great (in general, not just PH). But, its also quite slow and imprecise. I think that having the agent act more as both a teacher and "doer" is best.

I just recently switched to posthog self hosted and it works fine

• mlnj

  today at 4:11 PM

  Spent a day trying to get it running 2-3 weeks back. Gave up after a day.

I recently had to turn off posthog on my app, it was collecting so much information that wasn't needed that it was making my app unusably slow. I'm sure i'm missing some knob, but the fact that after an hour long claude code session i couldn't figure out how to fix it means posthog has gotten too fiddly.

• hawtads

  today at 4:39 PM

  If you are on react/next.js, defer the client side initialization until after your app has painted. PostHog (especially with their session recording feature) likes to initialize a little before the rest of your app loads through either their context provider or instrumentation.ts (if you are on next.js). It's generally insignificant except if you are building a B2C web app where the extra 100ms makes a difference in retention.

  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.

It's hard for me to express how much I dislike their marketing website. Sometimes when you have a "cool idea" you should sit with it a moment and then pull back.

• sv123

  today at 3:35 PM

  I'm a fan of the posthog product but agree with the site. I appreciate the retro styling and all but opening all the windows for everything is disorienting and kinda breaks web navigation that we have all gotten used to for the past 30 years.

  • osigurdson

    today at 5:21 PM

    I don't think it is meant to be objectively the most efficient interface. It is more about being remarkable in a Seth Godin sense. For me I just want things to be blazing fast inside the dashboard.

  • shshsjsj

    today at 3:44 PM

    wait i don’t see this happening!

I'm surprised - weren't they always OSS?

PostHog has always been open source.

Please update title accordingly.

The sheer number of files in the root of that project is making my OCD itch like crazy. That would drive me insane.

um... we've had this posthog-foss repo for years now. No idea why it made front page. This is not news.

Source: I was there

To clarify: PostHog has been MIT licensed since day 1, with the exception of the `ee/` folder. This `posthog-foss` repo is a mirror of the main `posthog` repo with the `ee/` folder removed. We've had it for ages.

The AGENTS.md is interesting, apparently the primary most important principle is, "Avoid em-dashes like the plague".

That's an odd request. I always use my own voice for certain things, such as posting to hacker news, or writing my thoughts on a proposal. But for other things such as writing up a bugfix, if I'm getting an AI to write it, I'd rather not hide the fact I've done so.

In fact I usually go out my way to mark it as AI written, to give a heads up to any human reader so they don't waste their time if they don't want to read it.

edit: I'm not sure why my comment is attracting downvotes, perhaps it's being interpreted as anti-AI. I'm not against AI writing, but there are contexts where people would like to know whether something is AI written or not. I would rather it was well identified than hidden, so people can make their own judgement whether to gain insight into a human writing or whether it's just process they can skim or feed through their own agent.

"Avoid em-dashes" just seems like a crude attempt to avoid AI writing coming across as such.

• bachittle

  today at 3:12 PM

  ...and then scroll down a few lines and you will find tons of em-dashes in the AGENTS.md

What the actual fuck is going on with web development nowadays?

Look at the sheer number of ancillary files in this repo:

    .agents
    .claude
    .config
    .cursor
    .dagster_home
    .depot
    .flox
    .github
    .husky
    .idea
    .interface-design
    .pi
    .posthog-code
    .run
    .semgrep
    .stamphog
    .vscode
    .zed
    agent-os
    bin
    cli
    common
    devenv
    docker
    docs
    frontend
    funnel-udf
    livestream
    nodejs
    packages/quill
    patches
    playwright
    posthog
    products
    proto
    rust
    services
    share
    terraform
    tools
    .cursorignore
    .cursorrules
    .dockerignore
    .editorconfig
    .env.development
    .env.example
    .env.local.example
    .env.services
    .envrc
    .git-blame-ignore-revs
    .gitattributes
    .gitignore
    .kearc
    .mcp.json
    .nvmrc
    .oxfmtrc.json
    .oxlintrc.json
    .stylelintignore
    .stylelintrc.js
    .test_durations
    .test_quarantine.json
    .watchmanconfig
    .worktreeinclude
    .worktreelink
    AGENTS.md
    AI_POLICY.md
    CHANGELOG.md
    CLAUDE.md
    CONTRIBUTING.md
    Dockerfile
    Dockerfile.llm-analytics
    Dockerfile.ml-mirror-image-scrub
    Dockerfile.node
    Dockerfile.playwright
    Dockerfile.recording-rasterizer
    Dockerfile.sandbox
    LICENSE
    README.md
    conftest.py
    dagster_cloud.yaml
    depot.json
    dist-workspace.toml
    docker-compose.base.yml
    docker-compose.dev-full.yml
    docker-compose.dev.yml
    docker-compose.hobby.yml
    docker-compose.multinode-clickhouse.yml
    docker-compose.playwright.yml
    docker-compose.profiles.yml
    docker-compose.sandbox.yml
    greptile.json
    hogli.yaml
    manage.py
    otel-collector-config.dev.yaml
    package.json
    pnpm-lock.yaml
    pnpm-workspace.yaml
    postcss.config.js
    posthog.json
    pyproject.toml
    pytest.ini
    tach.toml
    tsconfig.dev.json
    tsconfig.json
    tsconfig.kea-typegen.json
    turbo.json
    unit.json.tpl
    uv.lock

How can anyone in their right mind look at this kind of setup and feel good about it?

• osigurdson

  today at 5:17 PM

  Do people normally check in dot files? I find that strange but perhaps I am in the minority here.

Needs (2020) I guess?

Very interesting but why would they do this?

• ctxc

  today at 4:39 PM

  It was always this way!

• khurs

  today at 3:15 PM

  So non-posthog employees contribute and they can move faster?

Looks like they created mess with AI and then open sourced it. I remembered I had to shift from them to metabase because they closed sourced their deployments docker/kubernetes I guess it was 3 years back.

But now AI screwed them over so they come with their own open-source spaghetti.

• robbie-c

  today at 3:38 PM

  PostHog has always been open source. I'm not sure why this has been shared on HN at all.

  • ameliaquining

    today at 4:18 PM

    PostHog has always been open core and source-available. What's new is that they now publish a GitHub repo containing just the open source parts.

  • stronglikedan

    today at 4:22 PM

    Has it? This is from that repo, "PostHog FOSS is a read-only mirror of PostHog, with all proprietary code removed." Seems they have some proprietary code in the non-open-source version.

  • mooreds

    today at 3:56 PM

    I thought the same thing. What changed, if anything?

  • opem

    today at 4:03 PM

    Exactly, I was thinking this too!

Lol, is github down again?

Congratulations!

in the youtube video, by 'product' do they mean 'website' ?

I feel I'm missing some basics as to what this can do for me or what problem it solves.

edit so it's like google analytics .

I have a weird memory of PostHog.

I remember applying sometime ago, not really knowing what they did. They then spammed me with marketing mail, now they're open-sourced and had received a (supposedly marketing) job posting?

Granted in this entire history I had no idea what their product was. Seems flakey, but I haven't used it.

• gavinray

  today at 3:37 PM

  Why would you apply to a job for a company you don't even know what they do?

  • lucyjojo

    today at 3:43 PM

    money?