This is Part 1 of a series about using vibe coding to fork open-core projects. Not as an abstract argument, but as a walkthrough of a real fork, a real roadmap, and a real example.

The Vibe Coding Argument Nobody’s Making#

Vibe coding gets a bad rap. The discourse is dominated by people building Yet Another Todo App with Cursor, or prompting their way into a GPT wrapper and calling it a startup. That’s fair sport for criticism, but it’s not what vibe coding is for.

A natural use case for vibe coding at scale is forking open-core products.

Open-core is a business model where a company releases a limited version of their software under an open source license and keeps the advanced features behind a paywall. The model itself isn’t evil. People at these companies need to get paid. But when the paywalled features are free models that the company contributed nothing to develop, the model stops being “open-core” and starts being “rent-seeking on packaging.”

This is where vibe coding becomes a legitimate tool. If you can read the source, fork it, and then use AI coding agents to fill in the gated features, you’ve done something the open source ecosystem has always done: taken a product that stopped serving its users and made it serve them again.

Meetily: A Case Study in Unnecessary Gates#

Meetily is an open-core AI meeting assistant. The MIT-licensed codebase (15K stars on GitHub) gives you real-time local transcription with Whisper or Parakeet, AI summaries via Ollama/OpenAI/Claude, audio import, and retranscription. It’s a genuinely good desktop app built on Tauri v2 with a Rust backend.

The Pro version costs $10/user/month. Here’s what you get for that money, straight from their pricing page:

FeatureCommunity (Free)Pro ($120/yr)
Enhanced accuracy models❌✅
Custom summary templates❌✅
Auto-detect meetings❌✅
Advanced exports (PDF, DOCX)❌✅
Priority support❌✅

Here’s the thing that jumped out at me: “Enhanced accuracy models.”

That’s a Whisper model. Probably large-v3-turbo or a fine-tuned variant. Those models are MIT/Apache licensed. They’re free. Meetily didn’t train them. They packaged them and put them behind a paywall.

The summary templates? The open source codebase has a complete template framework (validation, loading, rendering, three-tier fallback chain). All MIT. The only missing piece is a frontend editor UI.

The exports? Clipboard copy works in the OSS. PDF and DOCX are missing a few hundred lines of Rust code.

This isn’t a judgment on Meetily’s business model. They built a good product and people should be able to charge for software. But it’s an open door for a fork. The MIT license guarantees it.

The Forking Primer: Yes, Even the Name#

Before the roadmap, a brief note on what it means to fork an Open Source project.

When I helped fork Red Hat Advanced Server to create CentOS back in the day, the very first thing we did was rename everything. CentOS wasn’t just rebranded; it was a legal necessity. The open source license lets you take the code, but the project’s name, logo, and brand identity belong to the original authors.

I checked: LibreMeet is available. No existing project, no trademark conflict. It’s a placeholder. By the time you read this someone may have grabbed it, but the principle stands. The first commit of any fork is a search-and-replace across the entire codebase: config files, Tauri bundle identifiers, macOS entitlements, directory names, struct names. It’s mechanical but essential, and it’s a perfect warm-up exercise for AI coding tools that excel at cross-file refactoring.

The MIT license requires you keep the original copyright notice. Everything else is yours to change.

The Full Roadmap#

I analyzed the Meetily source code (every Rust module, every Tauri command, every frontend component) to build a grounded roadmap for a fork. Then I had a product manager review it against the actual codebase. Here’s the corrected result.

The effort estimates reflect the actual state of the code. Some features I expected to implement from scratch were already done. Some I thought were straightforward turned out to require architecture changes.

Phase 1: Foundation (Rebrand + Privacy)#

  1. Rebrand to LibreMeet (Low). Search-and-replace across ~30 files. Tauri config, bundle ID, macOS entitlements.
  2. Strip PostHog analytics (Medium). The codebase ships with PostHog telemetry (5 files, 24 command registrations). Remove or replace with zero-telemetry stubs.
  3. Parakeet GPU acceleration (Medium). Currently CPU-only via ONNX Runtime. Add CUDA/DirectML/Metal execution providers.

The PostHog finding was a surprise. The analytics module sends events to us.i.posthog.com. If your selling point is “privacy-first,” you can’t ship with telemetry baked in, even if it’s disabled by default. Stripping this is part of the rebrand.

Phase 2: Templates & Exports#

  1. Template editor UI (Low-Medium). Full framework exists in Rust (validation, listing, 3-tier fallback). Only missing a frontend drag-and-drop builder.
  2. More built-in templates (Low). JSON files following existing schema. Sales call, sprint retro, one-on-one, legal deposition.
  3. PDF export (Medium). No export code exists. printpdf crate + 300-600 lines of Rust.
  4. DOCX export (Medium). Same pattern as PDF.
  5. Formatted Markdown file export (Low). Wrapper around existing save_transcript command.
  6. Batch export (Low). Loop over meetings + progress UI.

Phase 3: Transcription Upgrades#

  1. Whisper large-v3 UI (Low). Model is already in the catalog. Users need a download button. (I originally had “add large-v3-turbo support” here, but a codebase audit showed it’s already there. What’s actually missing is a button to download it.)
  2. Speaker diarization (Very High). Legacy PyAnnote code exists from a screenpipe fork but isn’t wired into the active pipeline. Needs embedding model + clustering + UI + schema changes. The upstream hasn’t shipped this either.
  3. Enhanced accuracy models (High). The fork’s biggest gap. Pro uses proprietary models. Options: fine-tune Whisper, or optimize Parakeet with GPU support.

Phase 4: Calendar + Auto-Detect#

  1. Calendar API (Google, Outlook) (Medium). OAuth + API. Requires app registration in Google Cloud / Azure.
  2. Pre-populate meeting names (Low). Command already supports optional meeting names.
  3. Auto-detect meetings (Very High). Zero code exists. Requires macOS Accessibility API for window title monitoring. 4-6 weeks minimum for macOS-only.
  4. Auto-join meetings (Very High). Even harder than detection. Per-app automation logic for Zoom, Teams, Meet.

Phase 5: AI/RAG#

  1. Embedding + vector search (High). No infrastructure exists. No vector DB, no embedding model, no chunking pipeline. sqlite-vec or BYOK via Ollama.
  2. Q&A over meeting history (High). Depends on #17. Not independently estimable.

Phase 6: Enterprise (Deferred)#

  1. Multi-user support (Very High). Full architectural rewrite. Currently single-user SQLite with no auth.
  2. Web UI (Very High). Entire frontend is a Tauri desktop app. Next.js code sharing helps but still massive.
  3. SSO/SAML/OIDC (High). Enterprise requirement if targeting organizations.
  4. GDPR audit trail (Low). Adding database mutation logging. Conditional on analytics being stripped.

The Antidote: A Worked Example#

This is all abstract until you see it work. Let me show you how this actually plays out.

I picked PDF export from the roadmap, a Medium-effort feature with clear boundaries. I wrote a specification document for it, then fed it to Factory AI’s droid CLI (their autonomous coding agent).

Here’s the spec I wrote:

# SDD: PDF Export for LibreMeet

## Goal
Add PDF export of meeting summaries and transcripts. Users click "Export as PDF"
and receive a formatted document with meeting title, date, summary, and transcript.

## Constraints
- Add `printpdf` to Cargo.toml — no other new crates
- Reuse existing `tauri-plugin-dialog` for native save dialog
- Follow existing Tauri command patterns (see `api_save_meeting_summary`)
- Use embedded DejaVu Sans Mono for transcript rendering
- Must work offline — no HTTP calls

## Files to Touch
- `frontend/src-tauri/Cargo.toml` — add printpdf
- `frontend/src-tauri/src/lib.rs` — register module and command
- `frontend/src-tauri/src/export/pdf.rs` — NEW: PDF generation
- `frontend/components/SummaryUpdaterButtonGroup.tsx` — add button
- `frontend/hooks/useCopyOperations.ts` — add export handler

I ran this through droid with:

droid exec --use-spec --auto high --worktree libremeet-pdf-export \
  -f /tmp/libremeet-pdf-export-spec.md

In a single pass across 7 files, it produced this:

611 lines of Rust in export/pdf.rs: a complete PDF generation module with

  • A PageBuilder struct managing cursor position, page breaks, and layout
  • Line wrapping algorithms for both proportional text (summaries) and monospace text (transcripts with timestamps)
  • A4 page layout with configurable margins, fonts, and page numbers
  • Multi-page support with continuation headers ("[Section] continued")
  • Native macOS save dialog via tauri-plugin-dialog
  • Proper error handling with logging throughout
  • 7 unit tests covering filename sanitization, text wrapping, time formatting, and summary extraction

On the frontend side, it added an Export PDF button to the button group (following the same analytics pattern as the existing Copy button) and wired the invoke call through the existing hook.

The module needs a bundled DejaVu Sans Mono font before it compiles, and it would want a QA pass before shipping. But the point is: one SDD spec, one command, and an AI coding agent produced 600+ lines of production-quality Rust across 7 files in a codebase it had never seen. That’s the vibe coding loop.

What This Tells Us#

The fork is viable. The roadmap is grounded. The tools are ready.

The features Meetily gates behind Pro are, in most cases, either already in the MIT codebase (large-v3-turbo, confidence scoring, template framework) or a few hundred lines of Rust away (PDF export, DOCX export). The genuinely hard problems (speaker diarization, auto-detect meetings, RAG) aren’t in Pro either. They’re “coming soon” for everyone.

The one real gap is “enhanced accuracy models.” Pro ships with a different model on a different codebase. What that model actually is and how much better it performs are impossible to verify without access. The fork’s best response would be to ship with the largest available Whisper model by default and optimize GPU inference, but whether that matches Pro’s accuracy is a question only A/B testing could answer. Everything else is plumbing.

In Part 2, I’ll walk through the actual process of forking the repo, running the rebrand, and having an AI coding agent implement the template editor UI. We’ll see whether the droid spec pattern holds up on a second feature.

But the thesis holds already: vibe coding isn’t about building Yet Another Todo App. It’s about taking software that’s been locked in a box and giving it back to the people who should have had it all along.