I maintain 20+ open-source projects across 4 ecosystems. Should I have focused on just one?
I look at my GitHub profile and sometimes wonder if I'm doing this wrong 🤔
Here's what I currently maintain, solo:
WP Bones — a Laravel-like framework for WordPress plugins. PHP, Composer, Blade templates. 169 stars, v2.0.3, active since 2018.
20+ Mantine UI Extensions — React components for Mantine: Parallax (Apple TV card effect), Split Pane, Window (draggable/resizable), Rings Progress (Apple Watch style), QR Code, Onboarding Tour, and more. TypeScript, published on npm.
FinderGit — a native macOS app that turns Finder into a Git-aware file browser. SwiftUI, no Electron, with inline diffs, Git actions, and AI commit messages. Free, in public beta.
octoscope — a terminal dashboard for GitHub. Go + BubbleTea, with 7 themes (including a CRT phosphor mode), single binary via Homebrew.
Four languages. Four ecosystems. Four very different user bases. One person.
The conventional wisdom says: pick one thing, go deep, build a moat. And honestly, there are days where I think the advice is right. The Mantine extensions alone could be a full-time job. WP Bones has a community that deserves faster iterations. FinderGit needs a proper Apple Developer ID. octoscope just shipped 7 themes when it could use better error handling.
But here's what I've noticed after doing this for years:
Skills transfer in unexpected ways. Building the list view table for Mantine directly inspired FinderGit's sortable columns. Go's concurrency patterns improved how I handle async in WP Bones. SwiftUI's declarative approach changed how I think about React.
Different ecosystems = different feedback loops. WordPress users file detailed bug reports. React developers open PRs. macOS users send emails. Terminal users tweet. Each community taught me something about building for humans.
Breadth prevents burnout. When I'm stuck on a SwiftUI layout, I switch to shipping a Mantine component. When npm publish feels like a grind, I write Go. The variety is what keeps me shipping after 40+ years.
But I also know what I'm giving up. No single project has the depth it could have. I'll never compete with Tower on Git features, or with a funded Mantine component team on polish. I'm spread across four surfaces, each one thinner than it should be.
So I'm genuinely asking:
If you maintain multiple projects — how do you decide when to consolidate vs. when to keep building across boundaries? Is the "focus" advice overrated, or am I the exception that proves the rule?
Replies
octoscope
For context, here are the projects I mentioned:
— WP Bones: wpbones.com
— Mantine Extensions: mantine-extensions.vercel.app
— FinderGit: findergit.app
— octoscope: gfazioli.github.io/octoscope
Happy to answer any questions about the stack or the process behind any of them.
do you maintain all of these as a full-time job, or are these side projects outside your main work? And roughly how much time do you spend per week on each one?
octoscope
@julia_zakharova2 Great question — these are all side projects. My full-time job is Lead Developer, where I work with React, TypeScript, and Go.
The open-source work happens in evenings and weekends, and the honest answer is: the time distribution is very uneven.
Mantine Extensions get the most consistent time — maybe 5-6 hours/week. Each component is self-contained, so I can ship one in a weekend and forget about it until someone opens an issue.
FinderGit goes in bursts. Some weekends I’ll spend 10+ hours on a feature (like the AI commit messages). Then nothing for two weeks. SwiftUI work requires focus blocks that are hard to find on weekdays.
WP Bones is mostly maintenance now — maybe 2-3 hours/week. The framework is mature, so it’s bug fixes, dependency updates, and answering questions on Discord.
octoscope is the lightest — maybe 1-2 hours/week. Go compiles fast, the scope is small, and the codebase is simple enough that I can pick it up after a month and still understand everything.
Total: roughly 10-15 hours/week on open source, depending on the week. Some weeks it’s 20, some weeks it’s 3. The key is that none of these projects need me every day — they’re designed to survive my absence.
What about you — do you work on anything outside your main job?
apideck
I maintain a single open-source project, and now I'm thinking of expanding it to many. Whereas you've done the opposite. I'm the creator of Resume Matcher, an open-source AI resume builder, since 2019. Grown it to have 100K+ users & 26K+ stars.
And I've learned a lot of things since then, like:
Communication: making sure everyone who's contributing is aware of what's being developed.
Programming & git
Marketing& DevRel.
Late-night debugging and fixing issues, because it works on my machine but doesn't on yours.
Now, I should use my skills to do something better and more amazing.
octoscope
@srbhr 26K stars on a single project — that’s serious traction. Respect!
Your situation is interesting because you’re considering the opposite move from mine. A few things I’d think about before expanding:
The hardest part of going from one project to many isn’t the code — it’s the context switching tax on your community. With Resume Matcher, your users know where to find you, where to file issues, where to contribute. The moment you split attention across multiple repos, that relationship gets diluted. Contributors start wondering “is this project still active?” when you go quiet for two weeks because you’re deep in something else.
What worked for me: each new project has to be completely independent — no shared dependencies, no shared release cycles, no shared community channels. WP Bones users have no idea octoscope exists, and that’s by design. If project B’s issues ever slow down project A’s releases, you’ve coupled them wrong.
One thing you mentioned that resonated: “late-night debugging because it works on my machine but doesn’t on yours.” That problem multiplies with every project. My survival trick: keep each project’s scope small enough that a cold start (coming back after weeks away) takes under 15 minutes. If it takes longer, the project is too complex for a solo maintainer.
Curious: what kind of projects are you considering branching into? Same domain (career/HR tools) or completely different?
Great job, respect! I like the multitude of technology stacks and programming languages - that's how I never get bored at my job. Answering your actual second question: I guess that the focus advice (as any other advice) is just very individual, and you happened not to be a person that needs to follow it ;)