PM on the Visual Studio Live Share team here. Thanks for posting! We're really excited to hear folks thoughts about this experience, how it can help improve their existing team collaboration workflows, and how we can continue to improve/learn. So please sign up and/or let us know what you think :)
We've heard pretty loud and clear that developers want better collaboration tools, without needing to switch editors, without needing to continuously negotiate control (i.e. look at the exact same thing), and without sacrificing the context/fidelity they would normally get while developing locally (e.g. full auto-completion/navigation, debugging). We think Visual Studio Live Share helps teams get there, and as it evolves, can hopefully become a powerful tool for teams to collaborate, not only more efficiently, but more naturally.
Additionally, we’ve found that successful collaboration needs to include more than just the project’s source files, and real-time edits, which is why we’re excited to also support collaborative debugging (even between Visual Studio and Visual Studio Code!). We’re only just getting started, and look forward to great developer feedback from the community.
Important question: if I have configured my editor with the one true way (VIM), and the remote has some dumb evil way setup (not VIM), are we able to be separately good and evil?
Absolutely! Live Share allows developers to quickly/easily collaborate with each other, while continuing to use their pre-configured editor, which includes themes, key maps, extensions, etc. This way, everyone can feel completely at home while working together.
Surely they're not incurring much costs with this feature if they're just using Microsoft servers for the initial WebRTC handshake? That's what Atom's recently announced Teletype feature does at least: https://blog.atom.io/2017/11/15/code-together-in-real-time-w...
Great question! The project would be built on the machine of the developer who initiated the Live Share session. That developer is effectively the "owner" of the session, and all developers who join the session are connecting their editor/IDE to theirs, and remoting certain editing/building/debugging operations. This allows the participants to fully collaborate, investigate/explore the project independently, but without incurring additional environment/setup requirements simply to get started.
We want the act of providing feedback/advice/etc. to each other to be as lightweight/frictionless as possible. Ideally, it would be so easy to collaborate, that it becomes harder for teams _not_ to do it :)
Wow, this is awesome. While the use case outlined here is great I could probably use this as a remote editor. That is, I can have my dev environment running in the 'cloud' and still expect responsiveness from my editor!
Remote development is definitely an adjacent use case that we believe could be really compelling. Thanks so much for providing the +1 on the scenario, and stay tuned (i.e. sign up :)) for future updates!
All the existing ways I know to do this (shared filesystem NFS/smb/sshfuse, or shared screen PCoIP/VNC/RDP, or remote file editors like BBEdit, TextMate+rmate, etc) are all terrible to use in practice.
Question: What data will be sent to the Microsoft servers? Lots of companies have very strict policies, most of them dont want their source code in any way at third parties.
I read a comment by another PM on Reddit who said that everything is fully encrypted, but is sent to a remote server to negotiate the connection with the other user. They also said that they don't collect any private information/code.
Are you gonna have any sort of extensibility apis. Would love to build something like coderpad, which saves/plays history of edits.
I hope this is just a another open source vscode plugin so other developers can contribute. I don’t trust Microsoft enough to build a closed collaboration system. We all know how abusive they were with good ol’ MSN messenger.
It would have been even better to include at least some idea of the expected release time or availability of the preview. It's hard to believe there is so much detail on the feature set, a big website to promote this and nobody at Microsoft has any certainty when this might be out.
This seems super helpful when swarming compared to squeezing everyone on the team into one office. Will collaborators all be required to be running admin level accounts? That might be a problem in shops (mine!) where admin access is rarely granted to devs.
Awesome! Thanks for this feedback. Swarming is definitely a scenario we'd love to see Live Share help improve. And no, collaborators wouldn't need to be running admin level in order to participate in a sharing session. We want to make sure collaboration is as accessible/frictionless as possible for everyone :)
Is it relaying the data over Microsoft (or Azure/Skype/etc) server? Or is it a point-to-point / peer-to-peer connection?
And if it relays the shared data over Microsoft server, what data beside currently opened source code files and keyboard + mouse inputs is transfered? Will it also transfer more source code files (e.g. whole VS project)?
Yes, the data goes over an Azure relay, but we are investigating using a peer-to-peer communication for sharing as well.
We don't transfer all keyboard and mouse inputs. Instead, we communicate the data behind each collaboration activity (e.g. opening and editing source files, initiating debug sessions, stepping through code, etc.). We only transfer what is needed during the collaboration session.
Please, please make a headless mode for this! My ideal use case would be to run this on a development VM and be able to connect to it with my VS Code and debug live on the VM. This would be a much better experience than rsync-ing your changes on every run.
Yes please, that would be awesome! I have a workstation that I rdp into from all over the world in order to do development in VS and the experience is terrible when I am on the other side of the world because of high latencies and low bandwidth link. Being able to connect to the workstation's VS directly and edit files + start debugging sessions remotely, that would be fantastic!
Am I the only one who finds it ironic that the development teams behind the top two open source editors introduce support for collaborative editing on the dame day, apparently unaware that they were both working on the same thing, and there being no evidence of collaboration between the two?
Atom’s new Teletype protocol is open, so at minimum a Teletype-compatible plugin could be developed for VSCode.
Note - the Teletype plugin initiates the connection via GitHub’s servers, but then the rest of the communication is entirely peer-to-peer via WebRTC. (I hope LiveShare uses a similar approach...?)
While Atom's Teletype works today. VSC Live Share is still unreleased "vamporware" (a term coined by MSFT). The ripping of Atom, rebranding it as VSC and doing a press release for such vital new feature is I guess pure coincidence, and not a typical tactic they are known for, right?
Edit:
> That's just patently false.
Curious, how can it be patently false when "Visual Studio Code is based on technology from Github’s Atom editor".
> Curious, how can it be patently false when "Visual Studio Code is based on technology from Github’s Atom editor".
That would be electron. Electron was originally made for Atom and is now being used as a framework for many other desktop apps. All the guts and internals of VSCode are completely different than Atom's.
Regarding Teletype vs LiveShare, your statements aren’t fair based on what I’ve read. It appears the teams have been working in isolation. Also the MS team’s deadline was planned to coincide with the MS Connect conference. (Maybe Atom’s announcement was planned to coincide with QConSF?)
The demo showed this as an alternative to screen sharing, but I could also see this feature being really useful for pair programming and providing in-person help. Even when I'm standing next to someone, it's nice for me to be able to poke around in their code on my own laptop, especially if I can type in examples of things I have in mind if I make a suggestion.
My own opinion, but it's not pair programming if everyone doesn't have their own keyboard and mouse. When I've practice pair programming, either I screen share with screen/tmux where anyone can take over and type or if at the same computer have multiple keyboards and mouse. Both programmers must be active. With only 1 input we end up in a passive/active scenario, which is fine for mentoring.
Thanks for this feedback! We believe that Live Share's ability for developer's to work together in real-time, while choosing to "follow" each other, or temporarily/periodically investigate something independently (e.g. "Let me check out whether this helper function could work here"), will enable it to apply naturally to many collaboration scenarios (e.g. pairing, seeking help/advice, swarming, consulting, mentoring, etc.), without needing to impose any specific opinion on team workflow and/or the practices they've found to be efficient/successful for them.
We authenticate when people try to use the link. We are exploring ideas on how to enable fine-grain permissions for sharing.
The link is an association between team members who are in a live share session. The workspace (i.e. source files) is not stored in the cloud. During a live share session, the communication is facilitated by an Azure Relay in the cloud. We are also looking at the ability to have peer-to-peer communication if you are on the same network.
Pretty cool, but I wonder what the implications are for code privacy given that this runs through Microsoft's servers. Will they also be collecting data on the code being shared? Especially given the Kite debacle, think it's important to be clear up front.
Hey there! Another PM on Visual Studio Live Share here. Security is absolutely something we are designing for. Microsoft will not be collecting data on the code. The code is not stored or uploaded in the cloud in any way. Rather, it is just a connection that is established between you and the teammate you are sharing with.
That FAQ seems fairly vague - what I'm looking for is simply how connections are established - can I simply point the thing at another copy of VSCode running in my LAN? Or do I have to involve Microsoft servers on the internet for session setup? Is the connection directly between us or via an MS server? What encryption is performed and where? Can a Microsoft employee or someone who compromises them theorically gain access to my code simply by accessing my coworkers account and connecting to my session?
PM from MS here. Authentication and authorization is managed by a cloud service but your code is not persisted in the cloud. The service optimizes for the most high perf connection possible via an encrypted channel with the cloud being one option. We intend to allow customers to lock down their invite links as well as they so choose.
First off, pretty cool stuff. MS is definitely killing it on the editor front lately.
Going to throw in another +1 here for being able to self-host the connection resolution. Without that I don't think I'll ever be able to make use of this.
I realize it's a large ask but if you're serious about driving adoption of VSCode, MSVC and other MS tech I think that would be a huge boon to a lot of your users.
Seems pretty easy to verify where the traffic is going with Wireshark once it comes out. Given how easy it would be for anyone to check that (especially in a product targeted at developers, who are likely to know how to use network diagnostic tools), it seems rather pointless to lie about where the traffic goes.
Nice work! This looks really awesome, and is another great example of the passion around better collaboration tools for developers. Thanks for sharing this.
With Live Share, we're also looking to extend the collaboration experience beyond real-time editing, and into collaborative debugging, and more, as we continue to learn from the ecosystem what is needed to continue improving team cohesion, regardless of the app scenario/issue at hand.
That's great to hear! We definitely believe that collaborative debugging is a critical component of being able to demonstrate/reproduce issues, as well as validate changes made during a collaborative/pairing session. We look forward to seeing how folks end up using it :)
Is there any plan on adding built in FTP capabilities?, I would love to get rid of my current IDE and use VSC but is a hassle changing the code there and uploading using some FTP client
Screen sharing is such a drag using Skype. Everything goes slow as poop even on the fastest of MacBooks. Yet for a lot of purposes doing a screen share is super valuable. I imagine Live Share is much leaner much alike watching somebody changing a Google Doc in front of your nose.
PM at Microsoft here. Live Share not only allows you to collaborate in real time in a lower latency snappier environment but also enables you to seamlessly transition from watching to participating, editing, stepping, and inspecting. The difference is you can collaborate but still operate independently which is not possible with something like a screen share. Screen sharing is great when you want to show your entire desktop or show visuals. Live Share lets you add another tool into your tool chest to better enable concurrent collaboration.
I can see it being extremely useful for group projects in university settings...
Pair programming is okay with two people looking at one screen, but once you have more than two people, it really is just a drag. Of course, you can use git and contribute separately. But looking at the same version of the code seems tremendously useful.
This is absolutely fantastic because until you see it, you don't even realise how much you actually need it.
I desperately need something like this especially when I'm working with junior devs. I'm usually pretty busy so I often ask them to get the debugger to break at just the point where they are having an issue before I walk over to their desks and take over.
How well do these tools generally handle poor latency?
I often work remotely over 3G/4G. Voice is fine, as is simple screen sharing of stuff like Trello boards in a meeting. I tried Slack's screen collaboration and it was hardly usable though.
Since we are only sharing what is necessary for the collaboration, this is significantly lighter-weight compared to screen sharing. Addressing latency is absolutely a core principle of our design.
This looks really cool and I am looking forward to it, but I spent a little too much time reading about it before realizing it won't be available[1] until sometime in the middle of next year (with a private beta starting sometime in Q1 of 2018).
Code reviews are definitely a scenario we believe can benefit from Live Share, regardless which version control workflow your team is using (e.g. PRs, trunk-based development). In addition to being able to quickly seek help, we want Live Share to enable easily seeking and _providing_ feedback/advice, in a way that makes code reviews something that happen frequently and more naturally bi-directional (e.g. "Hey I have a suggestion about your PR, can I show your something in a quick share session?").
PM at Microsoft. Beyond co-editing, Live Share enables co-debugging which allows you to track down problems that only happen on one machine in a low latency environment and enable concurrent investigation of different variables or stack points against the same running app. We've got more features in mind to enable end-to-end development. It also follows a model that actually does not require sync'ing at all which gets you up and running fast and improves security.
My team does this every day using other tools to share code we're writing in VS Code against Azure, this just makes so much more sense! Can't wait to try it!
This is pretty exciting. I've seen a number of failed attempts years ago to do this sort of thing with the Eclipse IDE. As someone who does a lot of pair programming (XP), this looks like a compelling way to support occasional remote work for XP developers. I could easily see a team with a good cadence & feature set to work on opting for "remote Fridays", "remote Wednesdays" or the like with tooling like this. Looking forward to trying it out!
I prefer to just do screen sharing with an audio conversation going to maximize the learning and flexibility. Since I also like Sococo, I prefer to just stick to that, since that is one of the features it provides. I will now explain why.
I disagree with what was said in the video about how there are many reasons you don't want to share your entire screen. With a little care, it is actually reverse, there are many things you are missing out on if you are not sharing your entire screen. I will explain this more in a moment. I also disagree that both people being able to edit the code is a good thing. I will explain more about that in a moment. Admittedly there are situations where you actually want to control the other person's computer, but you can't have both the benefits of being able to control their computer and the benefits of not being able to, so I prefer to not be able to.
On screen sharing. The reason I prefer to share my entire screen is basically this is more flexible. There inevitably ends up being other windows and programs that have some relevant information I want to show them. It might be a web browser or something else. Prior to sharing my screen I reduce the number of monitors I'm using to 2, and I increase my font size for my editor and browser.
On computer control. I recently read an article about strong style pairing. It really resonated with me because it reminded me of something I either read or heard, can't remember which, about the current recommended way of doing mob programming. I think the main benefit is it maximizes learning. The concept is the same for both types of collaborative programming, but for some reason I never considered that it could also work with pair programming as well. Basically, you have your driver and your mapper. The driver is the one with their hands at the keyboard and mouse. The mapper is the one who tells them what to do. The mapper explains what to do at the highest level of abstraction that they both understand, and they increase the level of detail as necessary if the driver does not understand them. The driver is supposed to trust their mapper. This takes a lot of discipline to work this way, but if you are just doing screen sharing, you really don't have a choice, which makes it easier to force yourself to stick to this.
Here are the advantages of strong style pairing. It allows the mapper to keep their head on the bigger picture, while simultaneously still being the one who is really in control. Traditionally the driver would be in control, and this would free up the mapper to think on a higher level. But then it is easy for the mapper to get distracted, and there is always this nagging feeling it is not really worth having two people at the same computer. In this way, the driver is like a human interface the mapper can use to control the computer. It is as if they can talk to the computer and tell it what to do! By not having to focus on actually making the edits, they are able to plan ahead and keep more of the plan in their head. This allows them to always be ready to give the driver the next instruction as soon as the driver executes their previous one. Since the mapper is in control, they need to know how to do what they want to do. Therefore the editor and language that the driver will use, is the one the mapper wants to use. This is great because the driver can quickly pick up new editors, IDEs, and languages fairly quickly, just by driving with an expert mapper for a few days. For the same reason this makes strong style pairing work great when you want to pair experts with people at a lower skill level, which might be more frustrating otherwise. In that case, the expert is normally the driver. If the driver really has an idea they want to try out, you would switch roles for a time rather than the driver taking control.
PM at Microsoft. Thanks for the feedback - we're thinking hard about ways to ensure that the changes that land in your code is only that which you expect. Are there specific features that you'd need before you'd be comfortable using something like this?
Strong second. I love visual studio, and visual studio code, but this particular feature would be extremely irritating. I'd also worry that it would promote awful development models like Pivotal's pair programming take on agile, which has always struck me as creepy and totalitarian.
We've heard pretty loud and clear that developers want better collaboration tools, without needing to switch editors, without needing to continuously negotiate control (i.e. look at the exact same thing), and without sacrificing the context/fidelity they would normally get while developing locally (e.g. full auto-completion/navigation, debugging). We think Visual Studio Live Share helps teams get there, and as it evolves, can hopefully become a powerful tool for teams to collaborate, not only more efficiently, but more naturally.
Additionally, we’ve found that successful collaboration needs to include more than just the project’s source files, and real-time edits, which is why we’re excited to also support collaborative debugging (even between Visual Studio and Visual Studio Code!). We’re only just getting started, and look forward to great developer feedback from the community.