PERSONAL_STORY / WHY_SYKES
Sykes-VCS began after I left corporate project steering in automotive software. I wanted to go deeper into technology again, return to the systems programming roots I enjoyed in school, and use a very hard problem, replacing Git and eventually GitHub, as the learning project that would force me to become better without optimizing for time to market.
FOUNDER_PATH
The personal shift behind Sykes-VCS is from managing large software programs to owning the hard technical details again. Automotive project work taught scale, constraints, and responsibility. Apps taught what it means to ship for real users. Sykes-VCS is the project that brings that back to fundamentals: data, storage, synchronization, performance, correctness, and code written by hand.
Before Sykes-VCS I worked in large automotive software programs at Porsche and CARIAD, the VW Group software company, across infotainment and ADAS/AD. I managed large projects and restructuring work, but over time I wanted to leave project steering and corporate politics behind and go deeper into technology again.
Alongside my company work I published iOS apps that reached more than half a million users over time and created a meaningful side income. After quitting my corporate job I focused on apps for a while, but eventually realized that it was not challenging enough for the kind of engineer I wanted to become.
When I was in school I really enjoyed programming in C. After years of higher-level product and project work, I wanted to go back to the roots: memory, data structures, files, synchronization, performance, correctness, and the discipline of understanding what the machine is doing.
Around that time GitHub was having serious uptime problems and unreliable feature behavior. At the same time, Git itself has long-standing workflow issues and missing functionality for live collaboration, provenance, and modern agent-assisted development. That became the challenge: build a replacement for Git, and from there a replacement for GitHub.
Sykes-VCS began in Zig, but the active project has since moved to C and is now written in C. TigerBeetle, its design philosophy, and TigerStyle remain important engineering influences even though Sykes no longer shares its implementation language.
Casey Muratori's approach to performance-aware programming is another major influence. I am part of the Computer Enhance course, enjoy it a lot, and try to apply what I learn there while building Sykes: understand the hardware, avoid accidental complexity, and make performance a design concern from the beginning.
Sykes is my Siberian husky companion. Because he is a husky, we spend a lot of time outside. I use that time to think deeply about how to build the version control system, how the data model should work, and what the product should become. The name came naturally because Sykes is part of the time and space where the project is formed.
Sykes-VCS is completely hand-written so the important decisions stay owned, understood, and accountable. This is not a statement about AI capabilities. It is a choice about how I want to operate: write my own code, make my own decisions, think deeply, learn, and craft a highly performant system.
WHY_THE_NAME
The name is not branding added after the fact. Sykes is my Siberian husky companion, and husky life means being outside a lot. Walking time became thinking time; desk time became the place where those ideas were tested against code, notes, and the hard constraints of a real version-control system.
BUILD_RULES
The project only works if the way it is built matches the reason it exists: learn the hard parts directly, keep the implementation hand-written for accountability, use AI as pressure rather than authorship, and make performance and correctness part of every decision.
Sykes-VCS exists to build real systems-engineering ability, so the difficult parts stay inside the learning loop and remain personally accountable.
Implementation, architecture, documentation, and product decisions have to remain personally understood, intentionally written, and owned.
AI is useful for research, comparison, and challenging assumptions, but the hand-written boundary is about accountability and learning, not about dismissing AI.
Every design should stay performance-aware: understand the data, memory, storage, synchronization, and failure modes before adding abstraction.
BUILD_PHILOSOPHY
Sykes-VCS is the challenge I chose because it sits at the intersection of databases, distributed systems, collaboration, storage, compression, performance, and product design. It is difficult enough to be worth doing and personal enough that I want every important part of it to be understood, owned, and written by hand, even if that means quality over speed.
