I did not start OpenVCS because I had some grand plan to reinvent version control. I started it because I was annoyed.

Linux has been my main desktop for a while now, and one thing that has always felt oddly under-served is Git tooling. Obviously there are Git clients on Linux. Some are decent, some are old, and some are perfectly fine if your workflow happens to match what they were built for. But I never found one that properly clicked with me. I wanted something that felt modern, fast, maintained, and actually comfortable to use as a daily desktop application.

The closest thing to what I wanted was the unofficial Linux fork of GitHub Desktop. For a long time, that was probably the most comparable option. The problem is that it has not had a proper update in over a year, and the issue list gives the impression of a project that people are still relying on, but that is no longer moving forward in a meaningful way. That is not meant as an attack on the project, because maintaining desktop software across Linux distributions is hard, but it did make me realise I did not want to depend on it long-term.

So I kept coming back to the same question: why is there still not a really good desktop Git client for Linux?

Eventually, that question turned into a more dangerous thought. Maybe I should just build one.

That became OpenVCS.

What is OpenVCS?

OpenVCS is a desktop version control client focused on speed, clarity, and customisation. The original motivation was simple: I wanted a better Git client on Linux. But once I started thinking about the architecture properly, I did not want to build something that was permanently locked to Git.

That is where the plugin-first design came from. The core application provides the desktop shell, base UI, framework, and plugin runtime. Actual version control support is provided by plugins. The first major plugin is openvcs.git, because Git support needs to be solid before anything else matters, but the application itself is not supposed to be Git-only at the architectural level.

That distinction is important to me. I am not trying to pretend Git does not matter. Git is clearly the most important starting point. I just do not want the entire application to be designed in a way that makes every future workflow bend around Git forever.

The short version is that OpenVCS is intended to be a desktop client for every VCS, starting with Git.

Why not just make a Git client?

That probably would have been easier, at least in the short term. I could have built everything around Git commands, Git terminology, Git assumptions, and Git-specific UI. Honestly, for the first release, that is still where most of the practical work is. Git has to work well before anything else is useful.

But the more I thought about it, the more limiting that felt.

Most desktop version control clients are tied very closely to one backend and one idea of how the app should work. That is fine until you want to do something slightly different. Maybe you want a different workflow. Maybe you want to add a theme. Maybe you want to expose a custom operation. Maybe you want a UI extension for a specific team workflow. Maybe, eventually, you want another VCS entirely.

I did not want OpenVCS to become a pile of special cases. I wanted the application to have a proper core framework and then let plugins provide the specific behaviour.

So in OpenVCS, VCS integrations are plugins. Themes are plugins. UI changes are plugins. Additional workflows and features can be plugins too. A plugin does not need to fit into one narrow category either. It can provide a VCS integration, modify the UI, add a theme, or combine multiple capabilities.

That might sound over-engineered for an early Git client, and maybe it is. But I would rather build the foundation properly now than hit the limits immediately later.

The gap I kept seeing

The more I looked around, the more I realised the problem was not just that I wanted a better Git client on Linux. It was that most desktop Git clients seem to make a trade-off somewhere.

Some are polished, but closed source. Some are open source, but fairly fixed in what they can do. Some support themes, but not plugins. Some have extension points, but are still fundamentally built around one VCS. Some support more than Git, but do not really feel like an extensible desktop platform.

That combination is what interested me.

I wanted OpenVCS to be free and open source, plugin-first, themeable, capable of supporting multiple version control backends, and still usable as a normal desktop Git client from day one.

I am not claiming that no other tool supports any of those things. Plenty of tools support one or two of them. The interesting part to me is trying to bring them together in one application without treating extensibility as an afterthought.

A normal Git client can be useful. A plugin-first desktop VCS client can become something much more interesting.

The VS Code idea

The easiest way I have found to explain the long-term idea is that I want OpenVCS to feel less like a fixed Git GUI and more like the VS Code of version control clients.

Not because I want OpenVCS to become a code editor. I do not. The point is the platform model.

VS Code is useful as an editor out of the box, but its real strength is that it became an extensible platform. Themes, language support, debuggers, formatters, linters, source control integrations, remote development tools, and workflow-specific extensions can all build on top of the same core application.

That is the kind of direction I want for OpenVCS.

A normal user should be able to install it and use it as a Git client without caring about any of the architecture underneath. They should be able to clone a repo, open a repo, stage changes, commit, branch, merge, fetch, pull, push, and get on with their work.

But for people who want more, the app should be able to grow through plugins, themes, VCS backends, UI extensions, and workflow-specific tools.

That is the part that makes OpenVCS more interesting to me than just building another Git GUI.

Linux first

Linux support is not an afterthought for OpenVCS. It is the main reason the project exists.

I do not want a Linux build that feels like it was thrown together because someone asked for it. I want the Linux version to be one of the primary targets. That means caring about packaging, desktop integration, startup behaviour, file handling, system Git, and the general experience of using it as a normal desktop app.

At the moment, the main Linux distribution target is AppImage. It is not perfect, but it is practical. You download it, make it executable, and run it. There is also experimental Flatpak packaging, but that has rough edges, especially because the current Git plugin relies on system Git. Sandboxing and Git integration are not a solved problem there yet, so I would still consider Flatpak test-only for now.

Windows builds exist too, and I do want them to keep improving, but Linux is where the project started and where the motivation is strongest.

The tech stack

OpenVCS is built with Rust, Tauri, TypeScript, and Vite.

Rust handles the native side of the app: filesystem access, process execution, core services, plugin loading, and the parts where reliability and performance matter. The frontend is TypeScript and Vite, running inside the Tauri shell. Plugins communicate through a JSON-RPC style runtime, which keeps the core application separate from plugin behaviour.

I picked this stack because I wanted something lighter than a traditional Electron app while still being realistic for building a modern desktop UI. Tauri gives the app a native desktop shell, Rust gives the backend a strong foundation, and the frontend stack keeps the UI practical to build and iterate on.

The goal is not to make the smallest possible app for the sake of it. The goal is to make something that feels responsive, maintainable, and not wasteful.

Current status

OpenVCS is still early, but it is not just an idea or a mock-up.

The core Git workflow already exists through the built-in openvcs.git plugin. At the moment, OpenVCS can clone repositories, open existing repositories, reopen the last repository on launch, show working tree status, inspect file and commit diffs, discard changes, stage files, partially stage changes, create partial commits, and commit from the index.

Branch workflows are also already in place. OpenVCS can list local and remote branches, create branches, check them out, rename them, delete them, and configure upstream tracking. There is also merge support, including conflict inspection, ours/theirs checkout, saving merged results, launching an external merge tool, aborting a merge, and continuing once conflicts are resolved.

Stash and remote workflows exist too. OpenVCS can list stashes, push stashes, apply them, pop them, drop them, inspect stash contents, configure remote URLs, fetch individual remotes, fetch all remotes, pull with fast-forward-only behaviour, and push changes. Git LFS support is also present, including fetch, pull, prune, track, untrack, and tracked-path inspection.

There are a few quality-of-life features that matter to me as well, such as SSH host-key trust helpers, SSH agent key visibility, local SSH key discovery, a dedicated VCS output log, runtime app log tooling, update checks, light and dark themes, and plugin-provided themes.

That said, I still consider the project early because the architecture, plugin APIs, packaging, UI, and workflow polish are continuing to evolve. The foundation is there, and a lot of Git functionality already works, but I do not want to pretend everything is finished or stable yet.

The current focus is on making the existing Git workflow feel good, improving packaging reliability, hardening plugin loading, refining the UI, and making the app comfortable enough to use daily.

The full feature list is maintained in the repository rather than duplicated here, because it will change as the project evolves.

What I want OpenVCS to become

The immediate goal is simple: make OpenVCS a good Git client on Linux.

That alone would already solve the original problem I had. If OpenVCS becomes a Git client that I actually enjoy using every day, then the project has already justified itself.

The longer-term goal is bigger than that. I want to see whether a desktop VCS client can be built as a flexible framework instead of a fixed single-backend application. I want to explore what happens when VCS support, themes, UI changes, and workflows are all treated as extensions rather than hardcoded assumptions.

That could eventually mean support for other VCS backends. It could mean better plugin and theme discovery. It could mean team-specific workflows. It could mean a plugin store one day. I do not want to promise all of that too early, because right now the Git workflow still needs to come first, but the architecture is being shaped with that direction in mind.

Why open source?

OpenVCS is open source because it would feel wrong for this kind of tool not to be.

Version control sits close to the heart of how developers work. If I am building a tool that manages repositories, runs VCS commands, loads plugins, and becomes part of someone’s development workflow, then the code should be inspectable. People should be able to see what it is doing, contribute to it, fork it, package it, criticise it, and improve it.

The project is licensed under GPL-3.0, and development is happening publicly.

Closing thoughts

I do not know exactly how far OpenVCS will go yet. Right now, it is still early, and there is a lot to build. But the reason I started it still feels valid every time I look at the current state of Git clients on Linux.

I wanted a modern desktop Git client that felt good to use on Linux. Then I wanted it to have an architecture that would not trap it as only that forever.

That is OpenVCS.

You can follow the project here:

• Website: https://openvcs.app
• GitHub organisation: https://github.com/Open-VCS
• Main repository: https://github.com/Open-VCS/OpenVCS