It's really built for the use cases that we face when developing software. It has direct integrations to your IDE and terminal, so you can share your code and collaborate with people (without having to combine a lot of different tools for the job).

It also works cross-IDE, so you can be using VSCode and your colleague IntelliJ and that's fine.

I use it for help/teach my students, mentoring and for code reviews/Technical Interviews.

It's been very useful for me.

The previous version of our extension for VSCode was open source, but some months ago we rebuilt GitDuck and this new version is not. We have been thinking how do it (and if we should do it), but no decision yet.

Personally, not being able to view the source of an tool designed to remotely execute shell commands is a deal breaker for me.

I like what you've built, it solves a problem in a neat way - Would love to see this going the free and open source route.

I'd argue that most developers are not on VSCode, although it's the most popular IDE.

The advantage is that you can have the video chat with pair programming that works with any IDE + the other integrations that we are building.

You can use it for free! The premium features are there if you are part of a big team or need more advanced things.

We discussed a lot about this and we were very close to have Webstorm today. We decided to launch anyway because we already previously postponed it and we didn't want to be finding excuses to not launch.

Btw you can signup and select Webstorm and will tell you as soon as we have it.

> was why would I use this when slack video and live share has been fine

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.

We were trying to do Clojure pair programming in IntelliJ+Cursive and vim-iced over Tuple.app/Screen.so/Zoom/macOS-VNC-over-ZeroTier during the past few weeks.

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...

It's because of the rubber duck methodology and in the early days we thought it would be cool to have a command `git duck` that starts a video to explain a commit.

Haha that's such a fun story!

I'll be blunt here, but I really do mean this in the spirit of constructive criticism: I hate the name. It's not related to Git in any meaningful way (why not "VimDuck" or "ZshDuck"?), and at first glance I'd assumed it had something to do with Cyberduck. Also, it doesn't exactly roll off the tongue: "hey, wanna hop on a Zoom?" flows better than "hey, wanna GitDuck?" Finally, the name pretty much limits it to only developers. Zoom was in a great place to capitalize on schools that were moving to remote classes, but "Zoom" doesn't really carry any semantic baggage. It would be awkward to explain to my boss why I wanted our company to your product for a business meeting, even if it's the perfect tool for it ("what's a git? What's it have to do with ducks?").

It's a video chat tool with direct integrations to the IDE and other dev tools.

Zoom is just a reference like Google Meet, but they have a longer name.

Terminal sharing is super important and we will work on it soon. This is one of the things that we need the most when we use GD internally.

Connections are P2P btw, no code touches our servers. But yeah, I understand this is not enough to get approval.

As someone who's most used editor by far is vim (can't escape IDE when writing java), I'm happy that you're doing this.

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.

Let me know how it goes!

Tried it out for a couple hours today! A quick experience report:

  - Collaborative editing was very solid, even with one of us using vim extensions and the other one not. (This has caused me some pain in Screen.so in particular.)
  - The leader/follower model was slightly unintuitive at times. I vaguely recall Floobits allowing either participant to e.g. create new files, but in GitDuck the leader has to share them to the workspace for them to become editable. (I might also be misremembering this from the Floobits days, but it was slightly confusing.)
  - Similar to ^ - when I was not leading, I couldn't summon the leader into a file I was editing, so I had to tell him when I was switching files. IIRC Floobits let you take yourself in/out of follow mode, even as the leader, so you would be automatically summoned when the other person switched files.
  - Looking forward to terminal support - glad that's on your roadmap :)
  - Our team is 50/50 between vim and VSCode right now, so we're looking forward to vim8/neovim support to really feel the power compared to Screen.so and Tuple.

Overall, had a surprisingly smooth experience for Day 2. Congrats on the launch and looking forward to future updates!