The Free Paths

Decentralization, Radicle, alternatives and the future of Git

The limits of the centralized world

Throughout your journey, you have used platforms like GitHub, GitLab, Bitbucket. These forges are powerful, but they have a fundamental flaw: they are centralized.

The single point of failure

When GitHub goes down - and it happens - millions of developers worldwide find themselves blocked. No more push, no more pull, no more CI/CD. Work stops.

This is called a Single Point of Failure. The entire infrastructure depends on a single place. If that place goes down, everything goes down.

Corporate control

GitHub has belonged to Microsoft since 2018. GitLab is a publicly traded company. These platforms can:

• Change their terms of service overnight
• Raise prices or remove free features
• Delete repositories for political, legal or commercial reasons
• Restrict access to certain countries (economic sanctions)

Vendor lock-in

You use GitHub Actions? GitHub Pages? GitHub Packages? The more platform-specific services you use, the more you are locked in. Migration becomes increasingly difficult.

The irony of Git - a distributed tool used in a centralized way

Here is something fascinating: Git was designed to be distributed. Linus Torvalds created it in 2005 precisely to avoid depending on a central server (after the breakup with BitKeeper).

In Git, every clone is a complete repository. Every developer has the entire history. In theory, there is no "main server" - just peers synchronizing their copies.

And yet, what did we do? We re-centralized the entire system around GitHub. The origin became the single source of truth. Pull Requests exist only on the platform. Issues, wikis, CI - everything is on a central server.

What Git allows:              What we do in practice:

  Alice <-> Bob                  Alice -> GitHub <- Bob
    |         |                            |
  Carol <-> Dave                        Carol
                                           |
  (peer-to-peer)                         Dave

                                 (centralized star)

It's like having a car capable of flying, but only using it to park.

Radicle - peer-to-peer collaboration

Radicle is a code collaboration protocol that works peer-to-peer. No central server, no account to create, no company controlling the infrastructure.

How it works

Radicle is built on Git. It's not a replacement for Git, it's a collaboration layer that uses Git as its foundation:

• No central server: repositories are shared directly between peers
• Cryptographic identity: no username/password. You are identified by a cryptographic key (like SSH, but for your identity)
• Patches instead of Pull Requests: contributions are made through "patches" that are proposed, discussed and merged peer to peer
• Seeds: nodes that stay online to improve availability (like "seeds" that keep data accessible)

Basic commands

# Initialize a Radicle project in an existing Git repo
rad init

# Publish your repo to the network
rad push

# Retrieve a project from the network
rad clone rad:<project-identifier>

# Synchronize with peers
rad sync

# Propose a patch (equivalent of a Pull Request)
rad patch create

# List pending patches
rad patch list

What changes compared to GitHub

The current state of Radicle

Let's be honest: Radicle is still young. The community is small but passionate. The interface is not as polished as GitHub. Some features are still missing.

But the idea is powerful. And like every movement that starts small - Linux, Git itself, the Web - sometimes a determined community is all it takes to change the world.

Other alternative paths

Radicle is not the only alternative. Other projects explore different philosophies:

Forgejo / Gitea - Lightweight self-hosting

Forgejo (community fork of Gitea) is a forge you can host yourself on a simple server. Interface similar to GitHub, lightweight, fast, and entirely under your control.

• Philosophy: "your code, your server, your rules"
• Advantage: compatible with GitHub workflows (including Actions via Forgejo Actions)
• Ideal for: teams that want GitHub's comfort without the dependence

SourceHut - Radical minimalism

SourceHut (sr.ht) is a minimalist forge created by Drew DeVault. No mandatory JavaScript, email-based workflow (patches by email, like the Linux kernel).

• Philosophy: "the Web should be simple"
• Advantage: fast, accessible, privacy-respecting
• Ideal for: developers who prefer the command line and email

Fossil - The integrated alternative

Fossil is not based on Git - it's a completely different version control system, created by Richard Hipp (the creator of SQLite). It natively includes a wiki, a ticket system, and a forum.

• Philosophy: "one tool for everything"
• Advantage: a single binary, everything is integrated, no external services needed
• Ideal for: small projects that want a complete and self-contained tool

Software Heritage - The universal archive

Software Heritage is a project by the INRIA foundation that archives all of humanity's public source code. Its goal is not collaboration but preservation - ensuring that code never disappears.

The future of version control

The world of version control doesn't stop where we are. Here are the trends shaping the future:

Artificial intelligence in development

AI tools are already transforming the way we write and review code:

• Code assistants (Copilot, Claude, etc.): real-time code generation and suggestions
• Automated review: AIs that analyze Pull Requests and suggest improvements
• Conflict resolution: AI could one day help resolve complex merge conflicts
• Test generation: automatically creating tests from code

Ever-larger repositories

Git is evolving to handle increasingly massive projects:

• Git LFS (Large File Storage): store large files outside the repository
• Partial clone: clone a repository without downloading the entire history
• Sparse checkout: retrieve only the folders you need
• git maintenance: automatic optimization tasks to keep large repos performant

# Partial clone - only download objects when needed
git clone --filter=blob:none <url>

# Sparse checkout - retrieve only certain folders
git sparse-checkout init
git sparse-checkout set src/ docs/

# Automatic maintenance
git maintenance start

The Monorepo vs Polyrepo debate

A great debate stirs the development world:

• Monorepo: all the company's code in a single giant repository (Google, Meta, Microsoft do this)
• Polyrepo: one repository per project/service (the majority of companies)

Each approach has its strengths. The monorepo simplifies code sharing and cross-cutting refactors. The polyrepo offers independence and simplicity.

GitOps - Infrastructure driven by Git

GitOps is a philosophy where all infrastructure is described in files versioned with Git. Modifying infrastructure means making a commit. Deploying means merging.

• The Git repository becomes the source of truth for infrastructure
• Deployments are automatic and auditable
• Rollbacks are as simple as a git revert

Retrospective - Your complete journey

Take a moment to measure how far you've come. You arrived at this Citadel not knowing what a commit was. Look where you are now.

Arc 1 - The Versioner's Foundations

You learned the basics of Git - the foundations upon which everything rests:

• git init, git add, git commit - create and record history
• git status, git log, git diff - observe and understand history
• git clone - retrieve another's history
• The .gitignore file - know what should not be archived

Arc 2 - The Collaborator's Paths

You learned to work with others:

• git branch, git switch, git merge - create and merge branches
• git rebase - rewrite history cleanly
• git remote, git push, git pull - synchronize with the world
• Pull Requests and code review - collaborate with rigor

Arc 3 - The Advanced Arts

You mastered advanced techniques:

• git stash - set aside work in progress
• git bisect - track down a bug through history
• git blame - find the author of each line
• git cherry-pick - pick a specific commit
• git tag - mark important versions
• Git hooks - automate checks

Arc 4 - The Automated Forges

You discovered automation:

• Continuous Integration (CI) - automatically test on every push
• Continuous Deployment (CD) - automatically deploy to production
• GitHub Actions - write automation workflows
• The other forges - GitLab CI, Bitbucket Pipelines, Jenkins

Arc 5 - Beyond the Guilds

And now, you have seen beyond:

• The limits of centralization
• The irony of Git used in a centralized way
• Radicle and peer-to-peer collaboration
• Alternatives and the future of version control

Final exercise - My journey

Step 1 - Create the repository

mkdir my-journey
cd my-journey
git init -b main

Step 2 - Write your reflection

Create a my-journey.txt file and write your personal reflection. There is no imposed format. Here are some ideas to inspire you:

• What surprised you the most about Git?
• Which command or concept did you find the most difficult?
• How do you plan to use Git in your future projects?
• What do you take away from this adventure?

This is your text. Write what you want, in your own words.

Step 3 - Commit with a meaningful message

git add my-journey.txt
git commit -m "My journey as a Master Versioner"

Choose a commit message that has meaning for you. This is your first commit as a Master Versioner - it deserves a beautiful message.

Step 4 - Tag your version

git tag -a v1.0.0 -m "My first version as a Master Versioner"

This tag marks the beginning of your new chapter. Version v1.0.0 - stable, complete, ready.

Step 5 - Run the verification

Bash (Linux / macOS / Git Bash on Windows):

bash verifier.sh

PowerShell (Windows):

.\verifier.ps1

The final ceremony

Concept summary