Back to Blog
Apr 1, 20264 min readOnuzulike Anthony

Managing Multiple Open Source Projects as a Solo Developer

Practical strategies for context-switching, documentation, versioning, and avoiding burnout when maintaining several active open source projects simultaneously.

EngineeringOpen SourceProject ManagementEngineeringSolo Development

Maintaining one open source project is straightforward. Maintaining four simultaneously — while each is in active development — requires deliberate structure. This is what's worked across Claude Code, Cognix, Neural Nexus, and NodWatch.

The Context-Switch Tax

Every time you move between projects, you pay a re-orientation cost. You need to remember: where did I leave off? What's broken? What's the next priority? Without a system, this cost is 15-30 minutes per switch.

The fix: leave a note for your future self. After every working session, write one sentence at the top of your TODO file:

# Cognix
NEXT: fix the intelligence pipeline to handle empty claims array
BLOCKED: waiting on user feedback about answer style UI

Three lines, under two minutes. Next time you open this project, you start immediately.

Project State Files

Each project gets a .session file (gitignored) with current state:

markdown
# Current
Working on: background service interval configuration
Last touched: src/services/ingestion_worker.py
 
# Known issues
- BM25 search fails on empty corpus (line 87)
- Intelligence pipeline slow on large files (>5MB)
 
# Next
1. Add configurable intervals to wrangler
2. Fix the empty corpus guard
3. Write tests for chunk deduplication

This is not documentation — it's a cheat sheet for re-entry. Update it before you close the editor.

One Release Cadence Per Project

Different projects move at different speeds. Don't try to synchronize them. Instead, each project has its own release cadence:

  • NodWatch: weekly releases (user-facing, fast feedback loop)
  • Cognix: bi-weekly (research-driven, slower iteration)
  • Neural Nexus: monthly (academic, stability matters)
  • Claude Code: release when features are complete (internal tooling)

The cadence isn't about when things are done — it's about when you decide to tag and document a stable snapshot.

Git Branch Conventions

Consistent branches across all projects means muscle memory transfers:

main          — production/stable
dev           — active development
feat/<name>   — new features
fix/<name>    — bug fixes
docs/<name>   — documentation-only changes

Never commit directly to main. Even for solo projects: the PR review process forces you to read your own diff, which catches 80% of bugs before they ship.

Documentation as a First-Class Task

Documentation written immediately after implementation takes 15 minutes. Written three weeks later from memory, it takes an hour and is less accurate.

The rule: before you close a feature branch, the docs are updated. Not "I'll do it later" — the PR doesn't merge until docs match code.

For APIs, automate it: if your function signature changes, the doc comment must change in the same commit. Code review catches mismatches.

Avoiding Burnout

The biggest risk of multi-project maintenance is spreading thin and making no project feel like progress.

Two practices that help:

Time-boxing: each project gets one focused block per week. Trying to touch all four in a single day means none gets deep work.

Shipped-not-perfect: shipping a working feature beats waiting for the ideal implementation. A real user seeing a rough feature provides more value than a theoretically perfect feature that ships two months later.

When to Archive

Not every project needs to live forever. Signs a project should be archived:

  • No external users (just you)
  • The core problem was solved and you learned what you needed
  • Maintenance cost exceeds the value delivered

Archiving isn't failure — it's acknowledgment that scope is finite. A clear archive notice ("this project is no longer maintained, see X for an alternative") is more honest and useful than a zombie repository with open issues.

Tooling That Scales

  • Single monorepo vs separate repos: separate repos win for projects with different audiences. Keeps git history, issues, and PRs scoped.
  • GitHub Projects: one board per project, three columns (To Do, In Progress, Done). No subtasks, no dependencies — complexity is a productivity killer.
  • Automated CI: even basic CI that runs tests and type-checks on push catches regressions without manual effort.
  • Dependabot: enable for all projects. Security patches and minor version bumps are handled automatically; major versions require a manual decision.

The overhead of setup is 2 hours per project. The time saved over six months is significant.