The Roster Fills Out — and the First Recommendation Goes Stale

Backfilled 2026-08-15, covering 2026-05-27 through 2026-07-20 — the stretch between founding the repo and deploying the first client stack.

Why Care?

Between scaffolding the repo and putting anything in production, the interesting work was deciding what belongs in the stack at all. Three tools got added, three categories got invented to hold them, and one existing recommendation turned out to have quietly stopped being true.

That last part is the one worth reading. A repo whose product is a table of recommendations has a maintenance problem most repos don't: the world changes underneath the advice, silently, and nothing breaks to tell you.

What's New?

• Plunk — transactional, campaign and automation email in one app on an SES backend. The open answer to Mailchimp / Kit / SendGrid.

• Postiz — write-once-publish-everywhere social scheduling with unlimited self-hosted users. The open answer to Hootsuite / Buffer / Sprout Social.

• Karakeep — bookmark-everything with AI tagging and full-text search, multi-user with invite-only signup. Replaces Raindrop.io / Pocket / Instapaper.

• Three new README categories to hold them: Email Marketing & Broadcast, Social Media Scheduling, Research Capture & Bookmarking.

• A correction to the Calendar & Scheduling category.

• Watchlist-Interesting-Tools.md — a low-ceremony landing zone for ~36 scouted tools that don't yet fit anywhere.

The cost trap these two share

Plunk and Postiz were added together because they attack the same shape of problem: the surfaces a firm scales spend on fastest.

Hootsuite meters seats and connected accounts. Buffer meters channels. Sprout Social is $199 per seat per month, so every additional person is another ~$2.4k a year. Mailchimp meters contacts, so a growing LP list costs more to email even when the content is identical.

Self-hosting doesn't make those tools cheaper — it removes the meter. That is a different argument from "open source is free," and it is the one that actually lands with a small firm.

Fork-pointed vs upstream-pinned

Adding these forced an explicit distinction the repo had been carrying implicitly. twenty-crm and papermark point at lossless-group forks; plunk, postiz-app and karakeep pin plain upstream.

The rule that emerged: fork only when deploy-side modifications are actually needed. Nothing required them, so nothing got forked. Every tool added since — including Plane — has followed the upstream default.

The recommendation that rotted

Cal.com moved its commercial codebase closed-source in April 2026. The genuinely open remainder was split off as a separate MIT project, Cal.diy.

The README's Calendar & Scheduling category was still recommending "Cal.com (self-hosted Enterprise)" as a free, fully open-source path. That had stopped being true roughly three months earlier, and nothing in the repo noticed. Self-hosting the old Enterprise edition now requires an active paying relationship and a private-repo invite — a materially different thing from what the table promised.

This is the failure mode specific to publishing recommendations. Code that breaks gets a red build. A recommendation that goes stale just sits there, looking fine, being wrong — and the reader who acts on it finds out for you.

The fix was the correction plus a note explaining the split, so a reader encountering Cal.com elsewhere understands why we point at Cal.diy and are watching Tymeslot.

It also set a precedent that has paid off repeatedly since: when a tool's licensing or availability changes, that is a changelog-worthy event, not a quiet edit.

The watchlist, and why it isn't a category

Scouting turned up ~36 individually interesting OSS tools. Most don't cleanly earn a core/ row — some are single-machine desktop utilities with no deployable surface, some are agent/dev infrastructure in a different lane entirely, some overlap an existing category and need a bench-off rather than an addition.

Forcing each into the taxonomy on arrival would have been more analysis than a "huh, that's neat" deserves. So they land in context-v/explorations/Watchlist-Interesting-Tools.md and get sorted later — graduated to core/, folded into an existing row, or recorded as considered-and- rejected.

That file has since done real work. When the portal catalog was built, the watchlist was the source for the "on the bench" tier, and its explicit non-fit notes are what kept desktop utilities and iOS keyboards out of a client-facing page.