<title>Fork, Don't Build: How We Modified Gitea, Pi, and Godot Instead of Starting from Scratch — Tinqs Blog</title>
<metaname="description"content="Everyone is building new AI developer tools. We forked three battle-tested open-source projects — Gitea, Pi, and Godot — and modified them from the inside. Combined changes: less than 0.5% of upstream code.">
"description":"Everyone is building new AI developer tools. We forked three battle-tested open-source projects — Gitea, Pi, and Godot — and modified them from the inside. Combined changes: less than 0.5% of upstream code."
<h1class="post__title">Fork, Don't Build: How We Modified Gitea, Pi, and Godot Instead of Starting from Scratch</h1>
<pclass="post__lead">The AI developer tools space is full of people building new things. New agents, new IDEs, new platforms, new wrappers. Meanwhile, the tools that actually run the world — git servers, game engines, CI runners — sit there unchanged, waiting for someone to open them up and let AI agents in.</p>
<p>We forked three of them. Gitea for git hosting. Pi for coding agents. Godot for the game engine. Combined changes: less than 0.5% of upstream code. Here's why, how, and what we learned.</p>
<h2>The 0.5% Rule</h2>
<p>We're four people. We can't build a git platform, a coding agent, or a game engine from scratch. Nobody can — not in a timeframe measured in months.</p>
<p>But we can take something that already works — something with years of battle-testing and thousands of contributors — and change the last half-percent that makes it ours. The pattern:</p>
<p>1. Find open-source tool that does 95% of what you need</p>
<p>4. Stay close to upstream so their fixes are your fixes</p>
<p>Across three forks, we've never touched more than 0.5% of upstream code. If your fork hits 1%, you're doing too much — either the upstream tool is wrong for the job, or you're not trusting it enough.</p>
<h2>Fork 1: Gitea → Tinqs Studio</h2>
<p>Gitea is a self-hosted git server. Single Go binary, MIT license, 45k GitHub stars. We used GitHub for two years. It was fine for docs. For the game repo — 12GB in LFS, growing weekly — it was untenable. LFS bandwidth limits, slow clones, $5/50GB pricing. And nobody on the team could <strong>see</strong> what changed. A PR modifying a <code>.glb</code> file showed a binary diff. No preview. The artist pushed, the developer approved blindly, and three days later someone noticed the normals were inverted.</p>
<p>We forked Gitea and built <ahref="https://tinqs.com"style="color: var(–c-accent-l);">Tinqs Studio</a>. Our changes:</p>
<p><strong>3D asset preview.</strong> Click a <code>.glb</code>, <code>.gltf</code>, or <code>.fbx</code> file in a PR and rotate the model in your browser. 22 formats supported via O3DV. This alone transformed our review process — the artist pushes, the lead inspects, nobody downloads anything.</p>
<p><strong>HTML file preview.</strong> Sandboxed iframe rendering. Our internal docs and game design pages look like websites, not raw source.</p>
<p><strong>Agent API.</strong> Six REST endpoints that let AI agents submit tasks, push code, check CI status, and open PRs. Agents are first-class users of the git platform, not bolt-on tools.</p>
<p><strong>LFS-first workflows.</strong> Auto-tracking on repo creation. Game file extensions (<code>.fbx</code>, <code>.glb</code>, <code>.png</code>, <code>.wav</code>) tracked by default. Storage dashboard per repo. Clone times went from 45 minutes to 3 minutes.</p>
<p><strong>OAuth2 SSO.</strong> One login for git, the game tools, and the team dashboard.</p>
<p>Total lines changed: about 2,000 out of Gitea's 500,000. We modify templates, add Go modules, tweak CSS. We <strong>never</strong> touch the database schema — upstream owns that, and we ride their migrations.</p>
<p>The alternative was building a git platform from scratch. Multi-year project, multi-million dollar budget. Or using GitHub/GitLab and accepting their limitations. Neither gives you the ability to embed agents directly into the platform.</p>
<h2>Fork 2: Pi → Agent Runtime with Game Tools</h2>
<p><ahref="https://pi.dev"style="color: var(–c-accent-l);">Pi</a> is an open-source coding agent by Mario Zechner. MIT license, TypeScript, minimal by design — four core tools (read, write, edit, bash) and an extension system. 51k stars.</p>
<p>We forked it and added four extensions, each a single TypeScript file:</p>
<p>The core Pi code is untouched — 900 lines of extensions added to a 15,000-line codebase. Agents get Gitea-native tools without a fork of the entire agent ecosystem.</p>
<p>The alternative: building our own agent from scratch — tool-calling logic, context management, streaming, retry handling, conversation threading. Months of work to reinvent what Pi already does.</p>
<h2>Fork 3: Godot → Agent-Aware Game Engine</h2>
<p><ahref="https://godotengine.org"style="color: var(–c-accent-l);">Godot</a> is the open-source game engine powering our survival colony sim. We forked 4.6.2 and added nine C++ modules that give agents direct access to the running game:</p>
<p>These compile into the engine binary. A vanilla Godot user never sees them. An agent connects over HTTP, takes a screenshot, reads the scene tree, executes a console command — all without touching the editor UI.</p>
<p>2,000 lines added to a 2-million-line engine. The alternative: building our own engine, or worse, writing a renderer instead of making a game.</p>
<h2>Why forking beats building</h2>
<p><strong>You inherit decades of work, for free.</strong> Gitea has handled millions of git pushes. Godot renders millions of frames. Pi has processed millions of LLM tokens. That battle-testing is yours when you fork. When you build from scratch, year one is spent rediscovering bugs fixed upstream in 2019.</p>
<p><strong>You get free maintenance.</strong> Every upstream release brings security patches, performance improvements, and new features — written by hundreds of contributors you don't pay. Your job is to rebase, resolve conflicts, and test. An afternoon, not a quarter.</p>
<p><strong>You stay focused.</strong> Building a git server means worrying about pack-file format, SSH key management, webhook delivery. Forking means you only think about the 0.5% that matters to you. The other 99.5% is someone else's problem.</p>
<p><strong>Agents work better on real platforms.</strong> An agent pushing to a real Gitea instance — with real CI, real code review, real permissions — produces work humans can actually review and ship. An agent pushing to a toy demo platform produces demos.</p>
<h2>What we're not building</h2>
<p>We're not building a new IDE (Cursor and Claude Code exist). Not a new LLM (DeepSeek and Claude exist). Not a new cloud platform (AWS exists).</p>
<p>We're building the layer that connects them. The git server that speaks agent. The coding agent that speaks Gitea. The game engine that speaks HTTP. Each fork is a bridge between an existing tool and the agentic future — not a replacement for either.</p>
<p>The age of agents doesn't need more agents. It needs better platforms. Platforms that already exist as open-source projects. They just need someone to fork them and add the wiring.</p>
<p><em><ahref="https://tinqs.com"style="color: var(–c-accent-l);">Tinqs Studio</a> is our Gitea fork, open for game teams. <ahref="https://arikigame.com"style="color: var(–c-accent-l);">Ariki</a> is the game we're building with every tool described here.</em></p>
