Sturdy is HereSign ups for Sturdy are now open!

Making a new version control system is definitely not for the faint-hearted! It has taken us a lot of work to lay the foundation for the code collaboration platform that we are building.

Now that you can try out Sturdy for yourself, I would like to take this opportunity to also share some more on the vision we are working towards.

Okay, why make a new version control when everybody uses Git?

Git is great at versioning, so it is no surprise it has become so popular with open source projects. However, it turns out that in software teams, managing code changes, and collaborating with other developers are conflated.

Like many other coders, Gustav and I have also used Git at our past jobs — making software products in team settings, trying to help one another.

The thing is, Git was made specifically for the needs and workflow of the Linux kernel hackers, who are working in a hierarchical, distributed, and slower paced environment. This workflow fits open source just fine but we have seen how different the workflow at work happens to be.

At a software company your code usually has a single source of truth. You collaborate closely with the rest of your team to solve problems for users, which often means you wish to have quick turnarounds in getting fixes and shipping code.

Observations we have made working as developers in a team setting

It is preferable to ship small and incremental changes as frequently as you can. This means that with a tighter feedback loop, preferably with CI/CD, the risk of having a breaking change is greatly reduced, and peer review becomes much easier. However, the overhead of doing this with Git is enormous, and often prompts team members to remind each other to “not write more than X lines of code” per change.

Giving meaningful feedback on code is hard. Many teams are doing peer review as part of their development process, but how many bugs do we really catch and prevent with this process, vs. the hidden cost of waiting for review? Bugs still reach production after all, even if the change was declared "LGTM" by a team member. Unfortunately, Pull Requests often make it easy to focus on nitpicking and difficult to casually discuss the design.

Fetching and running someone else's work-in-progress code takes effort. This is especially if you are in the middle of something else. Giving code suggestions asynchronously is even harder.

You want to know what your team-members are up to. It is natural for engineers to want to help their team with knowledge that they have. In a dynamic work setting people also want to prevent collision of work, as well as keep track of progress. Sometimes teams would actively encourage each other to have a cadence of “pushing” code to their branch regularly, and before the end of day.

Git is actually hard. A huge chunk of the questions on Stack Overflow are “How do I X in git”. It's a powerful tool, but it comes with a steep learning curve that you have to overcome very early in your career. However, an engineer may rather focus on their specific business problem, instead of having to think about about low-level VCS operations (even if they are fully proficient in it).

Three out of the top 4 Stack Overflow questions are 'How do I X in Git?'
Three out of the top 4 Stack Overflow questions are "How do I X in Git?"

Our vision for the future of team code collaboration

We believe that developer tools should empower teams to experiment, share, and discuss software ideas as well as ultimately ship their work with as little friction as possible. In a nutshell, this means working at a higher abstraction level than Git and prior VCS systems.

Greater abstraction means a more leveraged development environment — getting more done with less effort. This is similar to how high level programming languages, such as Python, are more expressive and powerful than for example C, at the cost of giving up some control.

Making our code versioning and collaboration tools smoother, means that engineers get to focus on the business problems they are solving instead of googling how to undo something.

Sturdy is cloud first

We have designed Sturdy as a cloud first platform because it just fits the way software teams work — together. The online nature of Sturdy means you don't have to spend any effort synchronizing code.

With awareness of changes from the entire team in real-time, Sturdy can provide a lot of actionable insights as well enabling easy one click actions aiding the development process. This falls in the category of workflow augmentation and includes anything from "click to undo", to more frequent CI feedback, as well as notifying of potential conflicting work.

What is even more exciting is enabling developers to help each other, discuss and try out each other's code with little to no effort. Consider for a moment teamwork with Google Docs compared to manually emailing and merging files. Sturdy enables this level of collaboration while still using your local text editor, and without forcing you to use multi-cursor collaboration.

Jumping between Workspaces in Sturdy
Jumping between Workspaces in Sturdy

Just The Beginning

There are have big plans for Sturdy and we are just getting started!

If you have any questions, check out our documentation — we are continuously adding new articles to it.

I hope you enjoy Sturdy and would love to hear what you think — join our Discord community or message me on Twitter @krlvi.
— Kiril

Ready to dive in?Start for free today.

Get started with Sturdy for free! Migrate from Git and GitHub to Sturdy in just a few seconds.

Sign up for free
Sturdy app screenshot