I’ll give this a shot tomorrow with some friends and see how it goes!

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

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.

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!

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

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.

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.

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/

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.

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?

Startup Unlimited calls Up to 20 people in a call Unlimited rooms

$20 per team member / per month

https://gitduck.com/terms

  2. Communications
  
  By creating an Account on our Service, you agree to subscribe to newsletters, marketing or promotional materials and other information we may send.
  
  ...
  
  
  11. Analytics
  
  We may use third party services (including Amplitude, Segment, Crisp and Google, and their respective affiliates) that collect, monitor and analyze this Log Data to provide analytics and other data to help us increase our Service’s functionality and to help us advertise our products and services. These third party service providers may use cookies, pixel tags, web beacons or other storage technology to collect and store Log Data or information from elsewhere on the internet. They have their own privacy policies addressing how they use Log Data and we do not have access to, nor control over, third parties’ use of cookies or other tracking technologies.

GDPR was never about killing Big Tech, it's about protecting your data.

Is the point of this for the non vscode crowd? Trying to understand what is the justification of paying for something like this.

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.

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

A couple of thoughts:

The screen share cannot be fullscreened(?), which makes it hard to see fine details.

The pair-programming code sharing didn't work VSCode to Pycharm (Or my coworker didn't get the plugin configured correctly in Pycharm).

Overall though, GitDuck seems like a great tool.

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.

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.

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.

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

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

As a word of warning, the home page does feature a vector image of something that looks quite phallic.

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

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