Ask HN: Hosted Fossil for small teams – interesting, or wrong call?

7 points by ragelink 64 days ago | 4 comments

I've been working on a hosted Fossil SCM service for a few months and I genuinely don't know if it's a good idea. The "We need a federation of forges" thread on the front page today made me think it's worth posting.

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)

TeriyakiBomb 61 days ago |

I've been experimenting with Fossil too recently. I think the biggest sell for Fossil is absolutely that small team angle and the sheer amount of context Fossil allows around what has happened in a repo historically. From that perspective, fossil is straight up superior. That plus autosync as a default. The quirks are something I haven't found too annoying, the learning curve isn't awful.

The AI angle is the wrong one IMO. And it'll turn people off. I'd just drop it entirely. I came across the fossilrepo...repo and immediately became wary as it felt very much like a semi vibe coded project. I'm not a hater, but it's not just me that's wary and keeps LLMs at arms reach, especially on non-toy projects like this aims to be. You have to as it's extremely hard to sift "Developer sensibly making use of LLMs" from pure spaghetti without interrogating a repo.

FWIW I think there should be a "GitHub for Fossil" but it's not a selling point and it should not be a commercially driven thing

jdw64 64 days ago |

I think this will probably fail if it is positioned as a GitHub replacement.

As you said, Fossil may provide a more unified context for AI. But GitHub’s biggest advantage is that it effectively functions as a developer portfolio.

Federation is not really a buying reason for most developers. The core question is exposure. Git itself is distributed, so why did everything centralize around GitHub? The same thing happened with npm. Centralization is, in practice, something users often want.

So I think the real opportunity is not simply “GitHub should be replaced.” It is to target moments when there is already public pressure or momentum for teams to leave GitHub, and then focus on larger projects or teams that might actually move.

I suppose this is a kind of herd effect. Honestly, my main concern is whether the large teams capable of moving others will actually overcome GitHub’s inertia.

The idea is good, but I do not believe that the better technical solution necessarily wins. Also, from what I have observed, many open-source teams are actually hostile to the idea of AI context, so advertising the AI angle too strongly might even hurt adoption.

I think the killer feature matters more. If this is simply “hosted Fossil,” then the question becomes: what concrete problem does it solve?

At least from my perspective, your target audience and your proposed killer feature, AI-friendly context, do not seem fully aligned.

ragelink 64 days ago | |

Thanks for the thoughtful feedback, looks like I have some more thinking about how to frame this.

luiskarlos 64 days ago |

This is a nice improvement over GitHub, especially in the context of agents. Having code, issues, history, documentation, and discussion in a more self-contained and structured project format seems like it could make it much easier for agents to understand and work with the full context of a project.