Ask HN: Hosted Fossil for small teams – interesting, or wrong call?
What I'm building: a hosted home for Fossil repos. Same onramp feel as a code host, but each project is a single self-contained SQLite file you can clone, email, or walk away with. The open source omnibus (Django + Postgres + Redis + Caddy + Litestream-to-S3) is at fossilrepo.io. The hosted version will be in private beta soon.
My rough thesis: 1. Fossil is already federated by design. Every clone is the entire project: issues, wiki, forum, history, code. That's the federation discussion happening on the front page right now, just with a 15+ year-old tool the SQLite project itself uses. If fossil clone works between any two hosts, lock-in basically dies.
2. AI agents need integrated context. A Fossil repo is one queryable SQLite file. An agent reads code + tickets + wiki + history with SELECT * instead of 47-odd GraphQL calls. RAG and MCP setups become trivial. Also has a cli tool thats super easy to use.
3. Small-but-serious teams are underserved. Git+GitHub won the macro market and that's not changing. But the 1-50 person team where the spec, the tickets, the wiki, and the code all belong in the same place... the integrated model is just better/easier.
Things I'm worried about: - Network effect — a repo isn't very useful if nobody else can find it - Inertia — Git muscle memory is hard to break - Codeberg / Forgejo / Gitea are all credible — what's the right wedge, if any? is this a solution that anyone wants?
I'd rather hear it from HN now than after we launch. Three honest questions: - Is this interesting, or am I solving a problem nobody has? - What would make you actually switch? - What am I missing?
Also stuck on the name. Both domains land on the same page, so vote whichever you'd actually use: https://fossilforge.io or https://fossilhub.io (I also have the .ai versions but .io feels more developer-y)