Show HN: OpenSnowcat – A fork of Snowplow to keep open analytics alive
Show HN (score: 8)Description
What made me fall in love with Snowplow was that it was unopinionated, gave access to raw event data, and was truly open source. Back in 2013, that changed everything for me. I couldn’t look at GA the same way again.
Over the years, analytics moved into SQL warehouses driven by cheaper CPU/storage, dbt, reproducibility, and transparency. I saw the need for a democratized Snowplow pipeline and launched a hosted version in 2019.
In January 2024, Snowplow changed its license (SLULA), effectively ending open-source Snowplow by restricting production use. When that happened, I realized the spirit of open data and open architecture was gone.
A week later, I forked it, I wanted to keep the idea alive.
OpenSnowcat keeps the original collector and enricher under Apache 2.0 and stays fully compatible with existing Snowplow pipelines. We maintain it with regular patches, performance optimizations, and integrations with modern tools like Warpstream Bento for event processing/routing.
The goal is simple: keep open analytics open.
Would love to hear how others in the community think we can preserve openness in data infrastructure as “open source” becomes increasingly commercialized.
That's it, I should have posted here earlier but now felt right.
More from Show
Show HN: ccrider - Search and Resume Your Claude Code Sessions – TUI / MCP / CLI
Show HN: ccrider - Search and Resume Your Claude Code Sessions – TUI / MCP / CLI I built a tool that stores your full Claude Code history to let you easily find and resume sessions. It has TUI, CLI and MCP interfaces. It's a single Go binary, and the session history is synced to SQLite each time you use it.<p>Default mode is the TUI with a session browser and full-text search. Once a session is selected you can browse and search within it, resume it or export to markdown.<p>The MCP server provides tools to let Claude search back through the session for pre-compact context or pull from prior sessions. I use this constantly.<p>I've seen elaborate continuity systems to give Claude Code access to history but this simple approach has been very effective.<p>Installation:<p>macOS: brew install neilberkman/tap/ccrider<p>Linux/other: git clone <a href="https://github.com/neilberkman/ccrider" rel="nofollow">https://github.com/neilberkman/ccrider</a> && cd ccrider && go build<p>MCP server: claude mcp add --scope user ccrider $(which ccrider) serve-mcp<p>Source: <a href="https://github.com/neilberkman/ccrider" rel="nofollow">https://github.com/neilberkman/ccrider</a>
Show HN: OSS sustain guard – Sustainability signals for OSS dependencies
Show HN: OSS sustain guard – Sustainability signals for OSS dependencies Hi HN, I made OSS Sustain Guard.<p>After every high-profile OSS incident, I wonder about the packages I rely on right now. I can skim issues/PRs and activity on GitHub, but that doesn’t scale when you have tens or hundreds of dependencies. I built this to surface sustainability signals (maintainer redundancy, activity trends, funding links, etc.) and create awareness. It’s meant to start a respectful conversation, not to judge projects. These are signals, not truth; everything is inferred from public data (internal mirrors/private work won’t show up).<p>Quick start: pip install oss-sustain-guard export GITHUB_TOKEN=... os4g check<p>It uses GitHub GraphQL with local caching (no telemetry; token not uploaded/stored), and supports multiple ecosystems (Python/JS/Rust/Go/Java/etc.).<p>Repo: <a href="https://github.com/onukura/oss-sustain-guard" rel="nofollow">https://github.com/onukura/oss-sustain-guard</a><p>I’d love feedback on metric choices/thresholds and wording that stays respectful. If you have examples where these signals break down, please share.
Show HN: Open database of link metadata for large-scale analysis
Show HN: Open database of link metadata for large-scale analysis
Show HN: TinyPDF – 3KB PDF library (70x smaller than jsPDF)
Show HN: TinyPDF – 3KB PDF library (70x smaller than jsPDF) I needed to generate invoices in a Node.js app. jsPDF is 229KB. I only needed text, rectangles, lines, and JPEG images.<p><pre><code> So I wrote tinypdf: <400 lines of TypeScript, zero dependencies, 3.3KB minified+gzipped. What it does: - Text (Helvetica, colors, alignment) - Rectangles and lines - JPEG images - Multiple pages, custom sizes What it doesn't do: - Custom fonts, PNG/SVG, forms, encryption, HTML-to-PDF That's it. The 95% use case for invoices, receipts, reports, tickets, and labels. GitHub: https://github.com/Lulzx/tinypdf npm: npm install tinypdf</code></pre>
No other tools from this source yet.