Every repo is a product

firetasks lives as its own repo — not as a folder inside a mega-project, but as a standalone product with its own README, issues, and release cadence.

That pattern repeats across the lab.

One repo, one job

Monorepos are fine for teams that need them. We are not that team right now. Each Firefly project solves one problem:

• firetasks — tasks
• firekeep — credentials
• firecalendar — events
• firemusic — playback

Splitting them means you can install, fork, or ignore any single tool without inheriting the whole suite. It also means each repo can fail or evolve independently without dragging everything else along.

Ownership is clarity

When a repo is a product, decisions get easier:

• Does this feature belong here, or in a different tool?
• Is this repo stable enough to recommend, or still experimental?
• Who answers issues?

Blurry boundaries create blurry software. We prefer hard edges.

The suite still exists

Separate repos does not mean disconnected tools. Shared conventions, install paths, and cross-project utilities keep the lab coherent without collapsing everything into one codebase.

The suite is an ecosystem, not a monolith. The repos are the atoms.