Discussion summary

PostHog has open-sourced a version of their project with some licensing differences, and there is discussion about the principles in their AGENTS.md file, notably avoiding em-dashes. Contributors and licensing details are also discussed.

What the discussion says

  • Some find the AGENTS.md principle about em-dashes odd.
  • There is curiosity about the purpose of the open-source repo.
  • Questions about licensing and contributions from non-employees.
  • Concerns about project structure and file organization.
The AGENTS.md says 'Avoid em-dashes like the plague'.
xnorswap
Is this open-source version based on the main repo?
thatxliner

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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.

  • ...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
    
    
    What percentage of those files are actually directly related to the source code of the software? 1%?

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

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

  • PostHog has always been open source.

    Please update title accordingly.

  • I just recently switched to posthog self hosted and it works fine
  • Spent a day trying to get it running 2-3 weeks back. Gave up after a day.
    by mlnj
  • The sheer number of files in the root of that project is making my OCD itch like crazy. That would drive me insane.
  • 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.

  • 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.
  • 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).
  • founder here, what specifically do you use posthog for that you now find hard to find?
  • 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.
  • 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.
  • 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”
  • we went from batteries not included to BYOAi
  • It seems like an odd thing to run locally with so many dependencies.
  • 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.
  • 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.

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

  • Does anyone know what the context for this is? Because https://github.com/PostHog/posthog exists as well
  • The PostHog Enterprise license (the “Enterprise License”)
  • 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.
  • 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.

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

  • Open sourced ?! I believe it was open source from day one.
  • 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!

  • Oh thanks for the clarification