Launch HN: GitDuck (YC S20) – Zoom for developers with real-time code sharing
It all started by accident, Dragos and I were working on something else, a screen recording tool and we started to use it internally to record short videos of our code. At first it was just for quick code reviews and to debug, but soon we realized how helpful it was to have a video explanation of the code. Kind of rubber duck debugging with video. ;)
After talking to almost 300 developers and learning that other people were facing similar collaboration issues we decided to focus 100% on building this tool. We are the first users and we use GitDuck internally for quick assistance, pair programming, code reviews or just discussing ideas.
It has the features you would expect in a video call tool — like audio, video chat and screen sharing, but the UX and the integrations were built exclusively for developers. You can easily share your code and do pair programming. We are building integrations for all the IDEs. This enables you to collaborate without screen sharing (so it's faster and and consumes less bandwidth), directly from your IDE and independently of the IDE that other people are using.
Whenever you join a GitDuck meeting, your IDE extension wakes up and allows you to share your code with the other meeting participants (or join the already shared code from other meeting participant). When your peers join your code, they can see and edit your files in real-time, similar to the Google Docs experience. At any given point you can also go to your peers position so you can see in which file and line they are.
Check a 1 min demo (https://gitduck.com/watch/5f1808919552aefe64ce0751)
GitDuck currently has integrations to VS Code and VSCodium. In the next few days we are going to release the integrations to all JetBrains IDEs. Vim, Sublime and others coming after that.
One important aspect to mention is security. We are the first users of the service so we focus a lot on building something that we would trust to use ourselves. All the files shared from your IDE are always shared via peer-to-peer and are end-to-end encrypted. No piece of code never touches our servers, so we never have access to your code.
All calls are encrypted and p2p (if 4 or less participants). If 5 or more people join we switch to a cloud infrastructure in order to maintain the quality, but the media are always encrypted and we never have access to your calls. You can read more about it here (https://gitduck.com/security) and we are always open for your suggestions to improve.
We would love to hear your thoughts and feedback. What are your ideas about tools like this?
Thank you!
112 comments
[ 3.3 ms ] story [ 131 ms ] thread'In addition, you may not use any of the Marks as a syllable in a new word or as part of a portmanteau (e.g., "Gitalicious", "Gitpedia") used as a mark for a third-party product or service without Conservancy's written permission.'
I do like the “duck” part of it though!
So GitHub is essentially outside the scope of the trademark policy, due to the history. We also decided to explicitly grandfather some major projects that were using similar portmanteaus, but which had generally been good citizens of the Git ecosystem (building on Git in a useful way, not breaking compatibility). Those include GitLab, JGit, libgit2, and some others. The reasoning was generally that it would be a big pain for those projects, which have established their own brands, to have to switch names. It's hard to hold them responsible for picking a name that violated a policy that didn't yet exist.
- https://github.com/go-gitea/gitea/issues/4175
- https://github.com/go-gitea/gitea/issues/1516
In the latter, someone mentioned that a few of these projects were grandfathered in/have written permission from the Software Freedom Conservancy and so may use a portmanteau as the name.
Gitea: I don't know.
The naming and references to 'Zoom' are odd. Instead of "Zoom for developers" maybe explain exactly what that means? Is is screen sharing and group meetings?
When you compare yourself to zoom I immediately set the bar that the usability/performance/security/etc. must at least be to their level.
It has the features you would expect in a video call tool — like audio, video chat and screen sharing, but the UX and the integrations were built exclusively for developers. You can easily share your code and do pair programming. We are building integrations for all the IDEs. This enables you to collaborate without screen sharing (so it's faster and and consumes less bandwidth), directly from your IDE and independently of the IDE that other people are using.
By Zoom we mean a video chat tool, but built for developers. I think it's hard to have a tool for every type of work and I can think some use cases that Zoom is great (like in big conferences) and others that is really bad (for debugging for example).
We are just focused on having a great experience for developers, so no big conferences or webinar features.
As a word of warning, the home page does feature a vector image of something that looks quite phallic.
To me "Zoom for x" implies video calling as a primary feature.
But yeah, the point is that you can video chat and we are adding other integrations for developers. Pair programming is one, terminal and server sharing is coming.
Adding a third party dependency for code-sharing seems like a non-starter for large enterprise companies which already have a hard enough time with the first party offering.
[1]: https://visualstudio.microsoft.com/services/live-share/
I don't believe they have IDE integration, but like others have said, Tuple + Live Share would be a competitor to GitDuck. Glad to see more attempts at the space though!
Fortunately the Screenhero founder has been freed from Slack, and has rebuilt it! (with promises that it will not suffer the same fate)
https://screen.so
Are there enterprises where they use Mac as default over Windows / Linux?
The browser version of live code did work, but no. I'm not doing that.
I used to use zoom for pair programming. It got banned because, as you said, Large Enterprise Company. Microsoft lobbied them with "trust us: the company behind skype knows how to write secure software. force uninstall zoom on all your employee computers if you know what's good for you". Microsoft corporate sales are wizards.
Since zoom bombing was a thing and we couldn't be trusted to set our own passwords, I also tried using Microsoft Teams to pair program. It was absolutely unusable (e.g. if you type the keyyyyyyyssssss willlll stickkkkk).
GitDuck is probably lovely. It's a shame neither of us can use it.
For VS Code Live Share I kept finding myself opening up Zoom and then in parallel trying to get Live Share running, which also feels somewhat finicky at times. The GitDuck experience felt a lot more complete by integrating at a different level. It also felt like it could eventually be a more suitable experience for things we often do in interviews like try to do coding interviews by combining tools like CoderPad & Zoom - though CoderPad has the nice side effect of preservice links to the interviews themselves.
You can be working in parallel in different files or just following around. It really depends on what you are trying to achieve.
One cool thing to try with GD is mob programming. :)
Tracking changes is coming soon! This is super needed.
We are going to add soon better tools to manage (and share) the local server. So you as a guest can edit, save and see how this is impacts the local server of the host.
I’ll give this a shot tomorrow with some friends and see how it goes!
It's the Dropbox Show HN from 2007 before Show HN was a thing. Someone made a comment with the same feel as this one.
The "joke" is that of course a developer can replicate the early version of most products, but that doesn't mean the product will fail (see Dropbox).
below that bandwidth, the latency is getting into the annoyingly high territory. and of course I'm taking about using it in approved quality mode.
it nicely handles HiDPI resolutions too, but unfortunately the built-in macOS vnc viewer can only scale down the screen, not up.
another issue is that zerotier doesn't work in China, but that's more of a social than technical issue unfortunately...
what I found is that Tuple.app makes a more useful compromise between latency and image quality. on low bandwidth your image might look like a balls of random pixels on first glance, but on a second look you can surprisingly still read it. meanwhile latency remains below 0.5s, so you can keep thinking together with your pairing partner.
screen.so over low bandwidth keeps the image quality significantly higher than just-above-unreadable, but then you are experiencing jittery 1-6 second screen update frequency.
In addition to latency and legibility, I also value trust (so non-open-source clients are negatively treated), and CPU efficiency (WebRTC screen-sharing fails on this).
Thus, I cannot use Tuple.app (macOS only) and screen.so (which, on the surface, appears to be using Electron, and thus WebRTC).
I find myself also sharing consoles too, I'd like to see this extended to terminal sessions, perhaps the session could be rendered in other people's editors? Kind of like a live asciinema.
I'd love to try this at work, unfortunately streaming Corp's code through an unapproved 3rd party service is a no-go. This would've been really useful in college. Hope this catches on!
Connections are P2P btw, no code touches our servers. But yeah, I understand this is not enough to get approval.
However I feel like your market may be more geared towards interviewing/learning, I don't see how in my work environment that we'll ever need this.
Your concerns are totally understandable and we’re more than happy to discuss how to get GitDuck approved on your Corp.
Security is one of our top priorities! [1] As Thiago said, code is shared on a P2P e2e encrypted way (code never visits our server) and we can always discuss on-prem options (100% hosted in your infra) so no data at all leaves your network and you can control all inbound/outbound traffic.
Feel free reach out if you have any other question or concern!
[1] https://gitduck.com/security
But honestly I feel like this maybe more useful in tutoring/interviews vs. working. My team of about 10 people is stretched over 1000s of files in about 100 packages and we also have planning to make sure we're not stepping on someone else's toes.
Zoom is just a reference like Google Meet, but they have a longer name.
We're trying to build something like this for sales team. Could you shed some light on the video tech you have used?
Daily was pretty easy to set up. If you have a React app, by following this guide [1] you can have a simple video chat quite quickly (in a matter of few hours).
Happy to answer if you have more specific questions.
[1] https://www.daily.co/blog/building-a-custom-video-chat-app-w...
To be able to share your code with people not using VSC. We are also optimizing a lot the video quality and we are going to add more integrations soon to the video chat. As we are focused only on developers we can do a lot of things that Slack video can't.
Here are a few conclusions:
Having multiple, independent mouse cursors in one screen is and extremely useful feature.
Consistent low-latency is much more important than temporary low-quality video.
To conserve bandwidth, we hardly ever use the video-call capabilities; low-latency, crisp and wide-frequency-band audio is more than enough.
The screen sharing codec should be optimized for text, with sharp edges. I don't want to see glow or other jpeg artifacts around my letters...
Any of the mentioned programs can provide audio and video call capabilities; that's not a differentiating factor. I wouldn't mind using a separate program for just that, since it's a negligible initial inconvenience, when we are having pairing sessions for hours on end.
Instead of wasting your money on re-implementing such features in your own software, just blog about what existing solution would recommend for audio/video/chat. It's MUCH CHEAPER, than giving in to the NIH syndrome...
I would rather like to see you focus on more important aspects of developer collaboration, for example terminal and "network" sharing. After all we are writing that code not so we can talk about it, but to run it! For example, since we are programming in Clojure, we must see the same REPL window(s) too, not just the source code. We are constantly running the code we just wrote (and its tests) in those REPLs. Currently, the least painful way to do this is sharing the whole screen :(
I haven't given up on other solutions, like Emacs in tmux or in a headless xvnc server with small resolution, 8bit colors only and tiny fonts. Viewers would just magnify it to full-screen. Characters would look pixelated, but still sharp, if the magnification factor is integer. It's a pity that open-source vnc solutions are a lot slower and macOS' built-in one and they don't support server-side resizing to the viewer's window size and things like that...
(I'm not associated with GitDuck.)
Launching and getting feedback from people outside of your immediate network as soon as possible is really useful. Not launching until your app is 'perfect' and 'feature complete' means you'll burn all your runway before getting a single customer and fail. I know that one from experience. It's far better to launch something that's useful to 20% of your market and then iterate to capture the other 80% than the other way round.
Btw you can signup and select Webstorm and will tell you as soon as we have it.
Startup Unlimited calls Up to 20 people in a call Unlimited rooms
$20 per team member / per month