Show HN: Sturdy – online-first version control focused on collaboration | Hacker News Reader

Show HN: Sturdy – online-first version control focused on collaboration

getsturdy.com

94 pointszegl42 comments

Hey everyone,

My name is Gustav (zegl) and together with Kiril (videlov) we are the founders of Sturdy (YC W21). We are building an online-first version control focused on collaboration. You can think of it as asynchronous pair programming. It still allows parallel work tracks but because Sturdy is centralized and cloud based, it can offer some cool real-time insights.

We felt that collaborating on code today is broken. It is difficult to get started and even after learning all the tools and commands, contributing effectively in a team takes too much effort. This got us sketching and building.

Sturdy is very opinionated around early and continuous feedback. Here are the core principles we have built our VCS around:

* Higher level and more leveraged than existing systems (eg. Git). The actions devs perform are closer to what a human might want. Like “ship this code to production” or “undo the things I did a few moments ago”. In a way this is similar to how high level languages like Python are more expressive than C, at the cost of giving up some control.

* Focused on close collaboration. We are doing away with sharing batches of code (Pull / Merge Requests) in favour of continuous feedback. Developers can see each other’s work-in-progress code in real-time. Trying/running each other’s code is a one-click action and so is making code suggestions or comments.

* Compatible. Despite being a cloud service, developers can still use their local text editor / IDE. We do this with two-way-synced directories on the workstations. Writing and debugging code is local while management and collaboration are done in the webapp. We have also built a Git compatibility layer allowing exporting & importing.

We just finished writing a post telling the story of the mistakes, learnings and vision of our journey https://getsturdy.com/blog/2021-08-18-unbreaking-code-collab.... It turns out that building a new VCS is not just technically difficult but challenging Git also raises a lot of eyebrows (eg. https://news.ycombinator.com/item?id=25121416 ). What do you think? How can we make team VCS better?

You can try out Sturdy today for free, we would love to hear what you think. Moving forward we plan to offer Sturdy as a SaaS with a free tier for smaller teams, and a paid tier for larger organisations and codebases.

We would love to read any feedback you might have in the comments!

This seems like the product of alot of hard work but, ultimately, who needs this? It's not quite fast enough for pair programming.

There are other faster, free, high quality options for pair programming.

The features of one click deploys and rollbacks tie the deployment system to your proprietary closed-source service.

Retraining a team away from PR and Merge Requests would take time for something that doesn't seem to offer much in the way of new benefits.

Do I have to log into a website to create / switch branches? How do checkout code? Do I download a zip from a website and then click a sync button on my IDE? Am I forced to use VSCode for integration or can I use VIM/EMacs?

Hey, thanks for sharing your thoughts! Co-founder of Sturdy here. We are focused on teams who work closely together and iterate quickly. People often want ship small incremental changes to production. In those cases we found there is a significant overhead of creating/reviewing/merging Pull Requests. At its core Sturdy is about allowing early and continuous feedback in asynchronous collaboration.

The equivalent of switching branches and checking out different code all happen in the webapp. On your computer you get a two-way-synced "magic directory" where you code with your existing tools/IDE/editor of choice. This means that if you wish to checkout someone else's work, a click in the webapp would instantly swap the content of your project dir.

Sounds like it would be much nicer if you had a plug-in to the IDEs to make the interaction feel native

> would instantly swap the content of your project dir

How does this work, if the differences between two branches are huge? Say, tens of megabytes. And the Internet connection not that great. If switching back and forth between branches, is there a local cache or does everything (all differences) get downloaded each time?

Anyway to self-host this? I don't see much use for other people on my team seeing my line-by-line edits in real time in their own editor as opposed to just watching on screen share, but I like to work on multiple hosts on my own LAN and it's annoying to have to push to a git server to synchronize, and easy to forget. I tried to just mount all of my repos via NFS, but the performance was atrocious and git didn't seem to like it, and I aborted the effort rather than try to figure out why. Going out to the Internet when you're only trying to synchronize on a LAN is pretty wasteful. Of course, even on teams that want to use this, plenty of them will be on the same LAN if they're working out of an office, and might want a service like this only on their own LAN to avoid wasting ISP bandwidth to synchronize between people in the same literal room.

Honestly, I feel with something like this, it'd be nice if you created some sort of "lib{NAME}" with functionality to synchronize some subset of versioned, diffable files between directories, that may or may not be on the same host. The primary motivation would be to build your own service on top of that library, but then other people could build different services on top of it to suit their own needs. Sort of how there is such a rich variety of alternative package managers for Arch Linux because all of the core pacman functionality is encapsulated in libalpm.

For synchronizing things across multiple hosts I strongly recommend SyncThing. It just works :TM:

If multiple hosts have the file open you run into sync conflicts pretty often, and that would be exacerbated by something within VCS. Don’t get me wrong it’s not a bad piece of software but not in the same spirit of the software in this post.

You're close to having a real killer feature if you manage to make Sturdy scale to working copy sizes in the range of 100GB and 10TB in conjunction with the automatic sync of local directories. Game studios would love you for that. They have a few pain points: game assets and their source files are huge, networks become bottlenecks and most artists barely understand a basic VCS workflow, let alone a distributed one. Making commits and data syncing transparent would be a huge deal.

Consider me interested. I have never gotten quite warm with git and definitely agree about the overhead about project management ticket + branch + PR for small changes.

Git should be challenged. I can’t imagine that’s the best we can do. What will ultimately determine this project’s viability for larger projects is whether it’s really as powerful.

I’m definitely excited for new VCS solutions as I think the current state is a bit less than optimal.

Edit: Uhm, where’s the code? How do I self host?

Thanks for the support!

My favourite take on the attitude the community has towards Git was posted by rossdavidh [1] in the "Git is too hard" thread:

> "Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid."

There must be a better way to do things, and we've made it our mission to find it.

We're not open-source yet. If you're interested in self hosting, reach out to me at gustav@getsturdy.com and we'll make it happen!

1: https://news.ycombinator.com/item?id=25124213

this may work well for teams of 2-5, I simply don't see this working at all for any larger teams or any team with formal development processes.

The whole idea of merges/PRs etc is to be able to formalize this stuff, track it, keep history etc in a way that is open and can be used with multiple tools.

Using some kind of proprietary, or even open source, web backend SaaS completely defeats this.

And the whole 'real time google docs for code' is going to be incredibly intrusive for most experienced devs. People dont make a habit of micro inspecting every line of code someone writes, no one has the time for that. The whole idea is to have good design practices, unit tests, CI/CD etc, good APIs and interfaces.

Sturdy sounds great for small startups who are all basically working on a single shared file and everyone is doing some sort of massive pair programming. That simply doesnt work for other models and is a nightmare. Learning git (or any other vcs) is a tiny tiny part of software development, its not a barrier like its being presented unless you are a junior dev starting out.

Thanks for sharing your perspective. I understand the point of formalizing contributions but wish to challenge the need to do so for every type of contribution. For instance changes that have low impact production (eg. clarifying documentation) are subject to the same process as high impact changes. We are experimenting with an idea where depending on configuration + heuristics (file, author, semantics of change) the formal review is skipped, recommended or enforced. Alternatively, permit deployment to staging environments without sign off.

What we aim to achieve with the real-time design is create value that would not otherwise be possible. For example, making use of CI much more frequently. I have in the past made and pushed throwaway commits just to trigger CI and get feedback sooner.

We have been using Sturdy in it's own development over the past 9 months. I'd say the workflow doesn't quite resemble pair programming. We check each other's work-in-progress occasionally and give code suggestions/comments whenever we can be helpful to one another.

> We have been using Sturdy in it's own development

I'm wondering, if one person has some edits in progress (which won't compile), and another person wants to compile and run the app, then, does s/he need to wait for the first one to be done editing?

Nope! Sturdy never syncs edits from one computer to another directly. Our analogy with Google Docs might be falling apart a bit here.

We're working in separate workspaces (which you could equate to a branch), and are syncing and sharing the workspaces only when the code is in a good state.

Ok, and, a good state -- I'm thinking that means when there are no syntax errors -- I suppose that generally it's not feasible to compile and run all tests.

One way to use Sturdy, that looks the most interesting to me currently, could be to onboard new team members -- maybe fixing some problem in their first contributions, while they see the fixes happen real time and can ask questions

> Sturdy live-streams everyone's code, so that you can give and take instant feedback.

For those who thought pair programming wasn't invasive enough?

I'm sure there are people and teams for whom this will work. But it sounds like a nightmare to me. Especially when learning something new, working through a tough problem, or simply having an off day, the last thing I want is to know my team is looking over my shoulder at everything I am doing.

Thanks for this feedback (Co-founder here)! As somebody who generally codes better without people “looking over my shoulder” and having used our own tool for 9 months I’d say it feels very different from that.

Our goal is to normalize sharing of code that looks draft-y, before any emotions have been invested in the work. We want to change the entire vibe of working together on code. Instead of feeling like submitting homework (Pull Requests), we go for a Figma/Google Docs style of working together. You could sketch on something in a corner (we call them workspaces) and only seek feedback if/when it makes sense.

When coding doesn’t feel like homework, figuring stuff also feels less intimidating IMO. For example yesterday I was making a function more testable by injecting a function as an argument. Gustav spotted that and he knew that there was an interface that could be injected instead. With one operation he got a copy of my code and typed an alternative on his computer. That code shows up as suggestions for me that I could take with one click.

Found what appears to be a bug in the example; if you start typing on a newline that you didn't create yourself the changes won't propagate properly

Thanks, I'll look into it!

I think this is very interesting. I'm skeptical about it because my approach to collaboration is so much wrapped up in the idea of _write code alone, review together_ but, as we've learned elsewhere in the industry, tighter loops (through continuous integration) have many benefits. Specifically, this approach seems much more conducive to enabling developers to create atomic commits... which I'm a big fan of.

That said, I'm curious about 2 things. First, git.live are tackling the same problem but _on top of_ git: do you think that there's going to be a bigger challenge for you because you're changing process _and_ technology, or do you think the fact that it's built from the ground up will make it easier (especially given how painful git can be)? I could see my own team being open to something like git.live (new process), but very skeptical about Sturdy (new technology). I'm curious how you intend to tackle that skepticism from developers.

Secondly, the homepage doesn't mention the fact that you _can_ integrate back into GitHub to support existing CI/CD integrations. That is something very important to me, and I didn't realise it was possible until looking at the help docs for GitHub migration[1]. Can you talk more about your vision for Continuous Integration with Sturdy? I've just noticed that it's mentioned as coming soon in the "Solutions" drop-down.

I'm going to give Sturdy a shot (using the GitHub integration to benefit from existing CI/CD) but a long term switch would be heavily dependent upon your vision for CI/CD! I come from a world where 10+ min test runs are acceptable, and so the slow turnaround of the Pull Request model (from write code to review) is necessary -- I'd love to hear how you think this can be done in (near) realtime.

Thanks,

[1] https://getsturdy.com/features/migrate-from-github

Building on top of existing technologies makes adoption easier in the short run, but would heavily restrict our options for what's possible in the long run, and we're trying to balance short term gains with the long term vision. Building on top of Git means that you have to drag all of Git's legacy with you, with all of its warts and pitfalls. Git is the only tool that I've seen developers regularly have to Google/ask "how to X", compared to tools like your IDE where the workflow is much more discoverable, and self-explanatory.

As you saw, we are compatible with Git, and even support using both Sturdy and GitHub at the same time. Which we're hoping moves us close to only providing a new process for the sceptics, while you incrementally can use more and more of the new technology.

Developers are right to be sceptic, we're tackling this by staying open, both with the development process behind the scenes, and making Sturdy easy to test out and migrate to and away from.

Great that you spotted the GitHub integration, we should really highlight it more! For CI/CD, except for supporting it natively, we're also exploring automatically executing tests and linters at set intervals, or when new changes are detected. So that the test results are as up-to-date as possible, and that every time you come back from a meeting or a short break, that you would have new results available.

1: https://getsturdy.com/blog/2021-08-18-unbreaking-code-collab...

I like the clean design and general straightforwardness of the site. Exciting that you're taking on such an established paradigm.

My questions are about initial audience...

I showed this to a software designer just now (who codes a little bit, maintains a site deployed to vercel) and the response was "this is a coding tool, I don't get it". For me as an experienced developer, I know git really well so it doesn't solve a problem for me.

That said, I totally remember git being frustrating to learn in college!

Who do you go after first, how do you find them, and what's their core use case?

Thanks! (Co-founder here)

Our focus is on software teams who closely collaborate to ship product functionality (eg. do daily 'standups'). We want to make the process of helping one another much better that what the status quo is today. For example, I have found that a code review process rarely creates deeper discussions on design/ideas, something that comes more naturally when pairing. With this said, we also want to make contributing code to be more accessible to people new to the profession.

Small teams that care about iterating quickly and frequently shipping to production are the type of folks we work closely with in developing the product.

Super cool! Any plans for webhooks? We trigger a lot of stuff off of GitHub webhooks (like when a commit occurs) so it would be interesting to hear how Sturdy will tackle this.

Thanks! We're planning to build webhooks in a similar way to the way that GitLab/GitHub are doing it. For the formal events (new change, new review, new workspace created, etc) we'll build something similar to the API of others, to make it easy for tools that are already interfacing with the Hub's to integrate with Sturdy. The real-time aspects of Sturdy will also have webhooks, to make it possible to write your integrations and tooling on events such as new files created, or file edits.

I believe that webhooks and great public APIs are important to have in all dev-tools products. I have created countless scripts and tools to connect many different pieces of my workflow, so I'm excited to see what others will build once we release our public API!

You should definitely use Svix.com for that!

Disclaimer: founder. :)

> We felt that collaborating on code today is broken.

Today is the day that I read “we feel that x today is broken” one too many times and just scrolled past. It has now become startup marketing speak. On reflection, I thought it might be helpful to mention. This has no bearing at all on the quality of the startup or their product, just a note about the wording being over used

Taking Git out of the workflow is scary. That makes any alternative to it exciting. Nice work!

Is there an offline mode? Git's non-centralized nature doesn't come into play for me often, but when it does I really appreciate it, like coding on a plane.

The "checkout" is downloaded in it's entirety, and you can still code away while offline.

What you can't do, at least today, is to jump between different workspaces, or prepare multiple different workspaces to be shared once you're back online.

I was on a 3 hour train ride just last week, with only intermittent connectivity available. Sturdy being online-first did not disrupt me nearly as much as than trying to hunt for documentation for the dependency that I was debugging.

There's a typo on the logged in help page under the "What is Sharing" section.

Home page under suggestions it says "them them"

Thanks, I appreciate it!

My 2 cents: as someone who’s helped many new developers get comfy with our big codebase, I find this interesting. Right now I get to see what they’ve done only after they committed so it’s often not the best time. Being able to watch earlier is a good idea.

Now, I don’t think you can keep all states of the code (or history is going to be completely unreadable), so you still need some idea of a commit so that people can state “I’m done”.

And then you still need the concept of branches, cause otherwise you pick up people’s changes and they break your copy.

So all in all, it should look very much like git.

Then, you’re going to have an extremely hard time getting people off git.

Maybe, and that’s just an idea here. This could be developed on top of git. Where you’re ide live-syncs your changes to a “.live” version of the branch you’re on. Then people interested could subscribe to that live branch, and would get the live syncs in their IDE. And when the actual commit happens, you can then discard all that happened in the “.live” branch.

Probably not the feedback you wanted, though...

Are there any businesses or tech teams that are currently adopting Sturdy as their version control?

Yes, there are a handful! We have some teams using Sturdy and GitHub side-by side at the moment for the projects, and some that are running standalone Sturdy for some newer projects.

And of course, at Sturdy we've been using Sturdy to build Sturdy since day 1.

Good to see that you're dogfooding you're own software.

As a budding git enthusiast, I have a few questions. How are things like merge conflicts handled? Does sturdy support rebasing or some equivalent? Is there an equivalent to hooks?

I sometimes deplug when I want to get in the flow, how well does sturdy perform offline (no internet connection)?

Sturdy handles conflicts in pretty much the same way as Git does ( https://getsturdy.com/features/conflicts ). The history in Sturdy is linear, and we’re doing the equivalent of a rebase behind the scenes when changes are shared from a workspace that’s behind the trunk. I’ve been dreaming about creating contextually aware merging, so that for example adding two methods at the end of a class doesn’t conflict, but we’re not there yet!

There is no hooks, in what use case are you using hooks today? I haven’t been using hooks before, so it would be great if you wanted to share your experience of how you’ve been using them.

Sturdy works fine when offline, and resumes the syncing when the connection is restored. The actions that are driven from the site, such as creating a new workspace, are not available when offline however. A full copy of the code is always fully downloaded to the workstation, so that you always can code away!

> A full copy of the code is always fully downloaded to the workstation, so that you always can code away!

Is this a full copy of just the current code or full history like git? I often use info from old commits or git blame to understand why a piece of code is written a certain way.

Regarding hooks: my team uses hooks to start ci. GitHub bots are built on top of hooks. I think a lot of people would consider it an essential feature.

Just the current code for now.

Yes, we're going to support webhooks and also on integrating directly with CI/CD-providers. Today it's possible to use Sturdy and GitHub side-by-side, with changes on Sturdy being mirrored to GitHub. So you can use GitHub as kind of a proxy, with the added benefit that you don't have to migrate the webhook configurations to use Sturdy.

In my previous reply I though you made a reference to Git Hooks [1], which I interpreted as a different need. My bad!

1: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

Regarding hooks, at my company we use them to ensure that our commit messages contain our ticket items so work is always linked to our project management tool. I've seen hooks used for running code static analysis to meet project guidelines and generate ctags.

Reply on news.ycombinator.com