517
Rybbit - Open source Google Analytics replacement (lemmy.world)
submitted 11 months ago by to c/selfhosted@lemmy.world
82 comments fedilink hide all child comments
 

Hi guys, I've been working on a self-hostable web analytics platform since the start of this year after being frustrated with Google Analytics and Plausible.

I've packed a bunch of cool web analytics features into Rybbit, but I've tried very hard to keep the interface simple to use,

https://github.com/rybbit-io/rybbit

Check it out!

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 14 points 11 months ago (12 children)

Only very slightly so. One of the reasons I created Rybbit is because platforms like plausible and fathom have much inferior self-hosted versions (very limited featureset and basically never updated). We have a comparison here

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 25 points 11 months ago* (10 children)

    @Goldflag

    I appreciate the intent behind Rybbit, but I have to respectfully disagree with the "only very slightly so" characterization. Looking at your official comparison table, the self-hosted version is missing:

    • Pages View
    • Web Vitals
    • Email reports
    • Google Search Console integration
    • VPN/Crawler/ASN tracking
    • Google/GitHub OAuth
    • Email support

    That's 7 significant features—which seems more than "very slightly" different.

    More importantly, this raises AGPL compliance questions. Under AGPLv3 Section 13, if users interact with modified AGPL software over a network (your cloud version), you're required to make the complete corresponding source code available to those users. If these cloud-only features are integrated into the same AGPL-licensed codebase, withholding them from the public repo while running them as a network service appears to conflict with the license terms.

    There are really only two compliant scenarios here:

    1. These features exist in the public repo but are just marketed as "cloud-only" (in which case the comparison table's misleading)
    2. These features are truly separate proprietary code that interfaces with Rybbit without being part of the AGPL-licensed work (which would require careful architectural separation)

    If it's neither—if these are AGPL-covered features running in your cloud service but withheld from the repo—that's exactly the "loophole" the AGPL was designed to close. The irony is that you criticized Plausible and Fathom for having "much inferior self-hosted versions," yet this appears to be a similar approach.

    Could you clarify the licensing status of these cloud-only features? Are they in the public repo but disabled by default, or are they proprietary additions that don't derive from the AGPL codebase?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 1 point 11 months ago (4 children)

    AGPL means they are licensing it to you, they are not bound by the license because they are the copyright owners.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 11 months ago (3 children)

    That's misleading. While copyright owners aren't bound by their own license, AGPL Section 13 requires that when they run AGPL software as a network service, they must make the complete source available to users.

    The AGPL was specifically designed to close the "SaaS loophole." Being the copyright owner doesn't exempt you from AGPL's network service requirements if you're distributing under that license.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 11 months ago (2 children)

    This is flat out wrong. If you're the copyright owner, you're not licensing the code to yourself. The AGPL is the license under which they're making the open source version available to YOU. The version they run themselves is proprietary.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 11 months ago (1 child)

    That's inacurrate. Licensing representation matters. If the cloud service is genuinely presented as AGPL-licensed, Section 13 obligations apply regardless of copyright ownership. However, copyright owners remain free to maintain truly separate proprietary versions under dual licensing.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 0 points 11 months ago*

    Licensing representation matters

    It doesn't, because they're the copyright owners. Think of their software as dual licensed: They run it themselves under a proprietary license, under which they reserve all rights. That has nothing to do with the AGPL version that they license to you. The AGPL doesn't take away the rights they have as copyright owners, nor does it preclude dual licensing.

    (Are you a bot? Your reply is written like ChatGPT, and it has that self-defeating logic that ChatGPT has sometimes.... eg. you wrote that you disagree with me, but then parroted the exact thing that I said.)

  • permalink
  • fedilink
  • source
  • parent
  • [–] [S] 1 point 11 months ago (2 children)

    Everything is in the repo and cloud features are just toggled off in the self-hosted build.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 6 points 11 months ago

    @Goldflag,

    Thanks for clarifying! Good to hear everything's in the repo and that it's truly AGPL compliant.

    Since as self-hosters we already carry the burden of maintenance, updates, security, and infrastructure costs that cloud users don't, would you consider documenting how to enable the cloud features in self-hosted setups?

    I see the docs cover basic environment variables, but not for Pages View, Web Vitals, or VPN/ASN tracking. Even if some features need extra config (SMTP, OAuth creds), having that documented would help those of us willing to do the work.

    That would truly differentiate Rybbit from Plausible/Fathom—not just code parity, but empowering self-hosters with full feature access.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 11 months ago

    Cloud features aren't just a toggle away for self-hosters because setting CLOUD=true enables unwanted restrictions like Stripe billing endpoints and event limits—it was intended as a binary switch for enabling the entire cloud infrastructure.

    Rybbit wasn't architected so self-hosters could modularly enable advanced features. To solve this, I've forked the project and made all enterprise features modular and enabled by default, so people can test them.

    Of course, it would be desirable that @Goldflag implements this himself because I'm sure he could do it more elegantly and maintain it properly as part of the official project going forward.

  • permalink
  • fedilink
  • source
  • parent