The Changelog: Software Development, Open Source - The Story of Visual Studio Code (Interview)

Episode Date: December 5, 2017

We're back in NYC at Microsoft Connect(); talking about the backstory of Visual Studio Code with Julia Liuson (Corporate Vice President of Visual Studio), Chris Dias (Principal Program Manager of Visual Studio and .NET), and PJ Meyer (Product Manager). We talk about the beginnings of the Visual Studio product line, how Microsoft missed the internet, how the community is judging Microsoft and looking at them with a very old lense, how Visual Studio Code evolved from lessons learned with their cloud based editor called Monaco, how they had to radically change to reach developers beyond Windows, and how this open source project is thriving.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Auth0. Auth0 makes authentication easy. We love building things that are fun and let's face it, authentication is not always fun or easy to build.

It can be a pain, it can take hours to implement, and sometimes even days. And even after you have it all in place, you have to keep it up to date, keep it secure, and Auth0 makes it super easy and fast to implement real-world authentication and authorization architectures into your apps and APIs. You can allow users to log in however you want, regular username and password, Facebook, Twitter, enterprise ID providers like AD or Office 365, or let them log in without passwords,

just like we do on changelog.com. To get started, grab the SDK for your platform of choice. Add a few lines of code to your project. This can be a mobile app, a website, or even an API. They all need authentication. Sign up for Auth0 and get the free plan or try the enterprise plan for free for 21 days at auth0.io slash the changelog. That's A-U-T-H, the number zero, dot I-O slash the changelog. No credit card required.

Once again, auth0.io slash the changelog, no credit card required. Once again, ozero.io slash the changelog. And by DigitalOcean who just launched Spaces, a beautifully simple object storage service designed for developers who want a simple way to store and serve a vast amount of data, such as hosting web assets, storing user-generated content such as images and large media files, archiving backups in the cloud, and storing logs. Just like you use S3, Spaces has an ecosystem of S3-compatible tools and libraries that can be used to manage your space, and it's available independent of DigitalOcean servers. You don't need to use anything else but just Spaces if you want.

And to make it easy to try for both new and existing digital ocean customers, you can get started today with a free two month trial of spaces by going to do.co slash changelog. And for new customers only, you'll also receive a $10 credit to use for digital ocean droplets or other services. Once again, do.co slashchangelog.

You're listening to the Changelog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of Changelog. On today's jared and i are at microsoft connect in new york city talking about the backstory of visual studio with julia lucen chris dyess and pj meyer in part one of the show we talk with julia lucen corporate vice president of visual studio and 26 year veteran of microsoft about the beginnings of the visual studio product line how microsoft missed the internet and how the community is judging them and looking at today's Microsoft with a very old lens. In part two of the show, we talk with Chris Dias,

Principal Program Manager of Visual Studio and.NET, and PJ Meyer, Product Manager, about how Visual Studio Code evolved from lessons learned with their cloud-based editor called Monaco, how they had to radically change to reach developers beyond Windows, and how this open source project is thriving. What is it that you would like to talk about? What's important to you? We talk to developers, we talk to the open source community.

Great. And that's my kind of people. Okay. Because we are one of those very fluent in GitHub and open source people. Yeah. And I would love to talk about it. And the reason is, for example, like, I still feel people are judging us and looking at us with very old lens.

Okay. And I was telling someone, like, I can remember it was three years ago at this very conference in this very studio where we announced we open sourced and made.NET open sourced across platforms. Three years ago, yeah. We did a show on that. Ah. We did.

Great. And we were excited too. Yes. And our audience was like, wait, what? Exactly. But we've been those people that have felt the way you're talking about, but see the new Microsoft. Great.

And I would love for you guys to help me get that word out because I feel like there's still so many people even... It got better this year, but even two years ago, they're like, what? You mean.NET is open source? It's like, what? .NET is cross platform? It's completely, what? Garnet is cross-platform? It's like completely news to them. So I'm trying to figure out

where all of the places these people are hiding and how can we get the message out as broadly as possible. Well, a lot of those people are listening to our podcast, so I think that's a good thing. An interesting place

that I think we could start because according to Wikipedia, which congratulations, you have a Wikipedia page. Is that you? an interesting place that I think we could start because you know according to Wikipedia which congratulations you have a Wikipedia page is that you? it is you I don't know

I haven't even looked did you not know you have a Wikipedia page? someone mentioned to me but never looked okay well you know I looked

I found were you born in Shanghai in 1970? yes I figured it was you because a lot of the information lined up live reveal it even looks accurate somebody from julia's family wrote this about her maybe it's pretty cool right that's that's good yeah yeah it was good for me because i've given many talks and stuff you know and usually do a little intro about my background

before so someone probably captured it, and it's all accurate. Okay, great. Well, that's great. So this will be accurate then because you graduated in 1991 with a bachelor's degree in electrical and computer engineering from Washington, and you started working at Microsoft very soon after. Right away, yeah. So you've been with the company for like 26 years?

25 years. 25 years. And so we've just been tracking this change from the outside, like 26 years, 25 years, 25 years. And so we've just been tracking this change, you know, from the outside, like we said, maybe three or four years, we've seen the opening up of Microsoft, but you've seen it through many different phases. So maybe let's start with you telling us a little bit of your history with the company. And then you can tell us this, this change that you've seen from the inside and your perspective on it and how it all came we'd love to so as you mentioned like i know i joined microsoft in february of 92 as a developer working on microsoft access nice that was before we shipped the first version of microsoft access

and i learned about databases in college from microsoft access was the first little database i learned about it is definitely the desktop database tool of the rage. And even now, I think there's still a set of loyal users of the product. I'm sure there are. And I want to start working on this other tool. I like to call it the worst-named Microsoft product ever. It's Visual InterDev. Visual InterDev.

Okay. Do you remember that product? No. But I agree it's not a very good name. What the product did was it was our first web development tool. We shipped it in like 96, 97. And against ISP, not to be confused with ASP.net, which we shipped much later. We were being called Visual Basic for the web.

That was our first attempt of having a web development tool in the late 90s. I think we shipped the first version in late 96 or early 97 or something. That's when the internet came out. Basically. So 95 was actually when Bill Gates actually had the internet tidal wave memo inside Microsoft. So a lot of different teams started to spun up, started looking like, hey, what should we do about the internet? We didn't miss the internet, I would think, in my opinion. You did miss it?

From a business model perspective, we totally missed it. We didn't create Amazon. We didn't create Facebook. We didn't create Google. All of these really internet business models, even though they all started their business from the Microsoft IE browser, if you may. Right, Internet Explorer.

I mean, for a lot of people, for a lot of people, that was the internet. Yeah, I think we were the enablers. Yeah, I think we enabled people to build these true internet companies, but we didn't really build them. Were you involved in IE? I was preferably involved with IE

because the rendering engine, the HTML rendering engine was also what we used in Visual InterDef to help you design HTML. So we worked, we collaborated with the IE team on those pieces, on those components. Back then the mission statement wasn't like a PC on every desk running Microsoft software or something like that? I think it was, what was the thing? It was a Windows, I think it's a Windows, like it's a PC on every single desktop.

I think that was it, a PC on every single desktop. And the inferred part was running Windows. Running Microsoft software, yeah, exactly. I think that was inferred. And so PC, by saying PC, you're assuming Microsoft. Right, I guess. Definitely implied. In a post-only Microsoft world, it's not, that would make, you're assuming Microsoft. Right. I guess. Definitely implied. In a post-only Microsoft world, it's not. That would make PC makes more sense.

Things change over time. But the mission statement back at that time was that PCs, I mean, it was all Windows. It was all Windows. 98%. But the thing, you know, you asked me what changed, you know, like I have seen. It is very important to realize that in a lot of the Microsoft internal engineering and everything practices was very much aimed at that day and error. If you think about even in the 97, let's just say 97 kind of timeframe, 97 also happened

to be when we first had the first Visual Studio product, when we take Visual Basic, Visual C++, Visual Intercept, Visual J++, when we take Visual Basic, Visual C++, Visual Intercept, Visual J++, made that into Visual Studio, right? That's why it's called Visual Studio back then. Okay, because you were just putting all those together. Right, and then that was, so we launched Visual Studio like 20 years ago, and this year is also the 20-year birthday

for Visual Studio. And have you been on Visual Studio the entire time? The entire time. And then if I think about what delivering software looks like back then, and if you think about back in 97, 98, where would you go buy something like Visual Studio or Microsoft Office? You'd go to Egghead. Remember those places?

Or Best Buy. Or Best Buy. I don't even remember. Was there Best Buy? In 97? I don't know. I feel like there was. Barely.

And you'd go buy a physical box. Right. Right. That's why we called it box software. Right. And what was the... If you think about engineering structure for Microsoft, we have a development team, which I was on, and then we had a test team.

Then we had a program management team. And the test team plays a very important role back then because their job is to prevent what we call recall class bugs. And what is a recall class bug? It's that the bug is so bad, the physical boxes has to come back to Microsoft, which has been shipped all over the world, has to come back to Microsoft and get rebuilt. That is a recall class bug. That's back when software quality mattered. Well, I think that we have different ways to think about it, but that actually happened to us before.

You can imagine the cost. Oh, man. Whose head rolls when that happens? Does the head roll? I don't know if the physical head rolls, but I will say that the... Hopefully a metaphorical head rolls.

The test manager of the product feels very responsible if that happens. The bug stops there. Because that is where the bug stops. Wow. And software development was so antiquated then in comparison to today's world. Right. Would you agree? Well, because the infrastructure wasn't there.

So you optimize for different things. So at that time, if you had any questions or problems with your software, you will call Microsoft. There's no internet, right? 97, 98. And you will call our product support people on the phone, try to go describe your problem. And it will be like, oh, we're trying to go help you sort it out, et cetera.

But even if I figure out a little issue that I had, I don't really have a way as Microsoft to give you a patch. Right. There's just no such mechanism allowed or, you know, it was really enabled. The only way to get them something would be to mail that to them. Well, even this mail, like, you know, like you have like the installer doesn't support a patch. Right. Right.

The software doesn't know how to patch. Like you need to have someone in your IT to patch it for you. It's super complicated. Very terrible and so think about like the reason i think about that day and age is because that particular set of development practices was working well for us in that day and age and you know it lasted for the next really 10-15 years it kind of worked that way and then you know like it just didn't work because it's kind of like the land phone to the cell phone transition you know it's like these big huge like the internet transition says like that is no longer how you should ship software right and

your your customers expectation changed and the velocity changed because back then it took us three years to ship software and that was okay. That was already fast enough. They were named by years. They were named by years. And people like to hold on to old software. Where you tell them it's not secure, don't run it, it's terrible. And you have to charge for updates, sometimes large amounts for the update because it's such an expensive process. It's an expensive process.

You have the entire development team, the business model back then was to sell you to the latest version, etc. So now you kind of look back to say, wow, that was great for Microsoft back in 1997. And the entire business and process engineering practices was designed for that day and age. Again, that kind of infrastructure. But fast forward, for us the transformation really started after we shipped Visual Studio 2012 which is five years ago and that version of Visual Studio is also interesting because that was the version where we did not get to decide our own shipping schedule. Our schedule was tied with Windows 8. So it's gonna ship no

matter what. It was a major release because we had to do so much work to support Windows 8 development paradigm. That was, you know, a lot of challenges for our team to tackle. And after we come from shipping VS 2012, you take a look, we're looking ahead, and there's a couple of things become very clear. We can no longer ship in three-year product cycles. We're not going to survive if we ship three years because the technology is changing so fast and so quickly.

So we really started, we made a top-down decision that we're going to have quarterly updates and that's going to have new capabilities and new features. This is in 2012, this decision? Yeah. So our first quarterly update was VS 2012 update one. And it was a very traumatic thing for the team because the entire engineering process was not set up to go do this. And I want to give you a metaphor.

Imagine like in the old days, people buy encyclopedias, right? They're beautifully bounded, A to Z. You buy a whole thing, you stuff your whole bookshelf. And what we're trying to do is like, don't buy the whole set. I just want to go insert a chapter in this one book. Or I want to go rip a few pages out. I want to go cross a word out and replace with a different word. What we wanted to do is incremental

updates to the whole Enchiridion Encyclopedia versus the whole big Encyclopedia. But our machinery only knows how to produce this whole big thing once every three years. That's what the factory, if you may, how our operationalization was designed

for. So it was a major transformation that we have to go through. And that transformation happened to every single major Microsoft product line to say, wow, how we really take that huge box software mentality and think about every piece of software we ship in Microsoft as a service, which you make incremental updates quickly. And you really observe and respond to customer feedback quickly and that's the you know that's really the pursuit that we have been on interesting so that that transition seems to correlate with what we opened with which is the opening up of the software as well because you

could have continued you could have changed all your machinery but still shipped proprietary binaries that's right but you didn't do. You changed the machinery of the way you build the software to be incremental. But you also, it seemed like one by one or sometimes five by five, these different individual products or like.NET Core and then more of.NET and so on and so forth, you just opened up the software itself. So speak to that decision and how it played out. Yeah, and that is another great question because you're exactly right. Changing the software process doesn't necessarily change the deliverable. And the core strategic pivot we made is that Visual Studio was really

for a long time, and that's the old meme we're talking about. People think about it as a product that only runs on Windows and only supports Microsoft platforms. That was true for many years. And the strategic pivot we actually decide on is that we want to, and it's very much tied with the new Microsoft mission when Satya becomes CEO, right? We want to empower every person, every organization to achieve more. And how that come down to us in the developer division space

is that we want to really empower every developer and every development team to achieve more. And if we're only helping people running on Windows and targeting Microsoft platform, that's very far from every developer and every development team. And that's when we started pivot to the, I think that was the first slide Scott showed.

And we've been showing that slide for the last three, four years, which is our any developer, any app, any platform. And that was a core strategic pivot we have made. And everything really ties with that strategic pivot in terms of, well, how do we engage with all the developers out there? And what are the meaningful engagement looks like? And this is where we start, you know, start doing iOS Android development, helping with the mobile side, and we look at what people really need in the cloud space, in the mobile space,

and we take Node.NET, made it open source and cross-platform, and it's become a fantastic way for customers to share code between their Unity gaming to their cloud backend to their website to their mobile apps. It's just really the best programming language that can share common business logic. And today, Miguel showed you how you can take the core business logic written in C-sharp and then embed that into your iOS and Android app. So that capability of us looking, understanding developers' needs and open sourcing our core

framework capability, and really allow this breadth of scenario that opened up. That has been super powerful for us. And then with that, not to mention, we also started to develop Visual Studio Code. That was exactly what we were going to lead to next, because you have this now bifurcation of Visual Studio, where you have the established 20-year-old project that millions of people are using, but then brand new, open, different, I mean, Greenfield, new editor, right? Yeah, so first of all, when we start to do that

is that we realize that there are different types of developers. When I start talking to a lot of developers, there are a lot of different needs. And I always ask people, do you use Microsoft Word? Usually I get a nod. Do you use OneNote? I also get a nod. Do you use Notepad? I again get a nod,

because personally I use O3. And I'm not really confused about when I'm going to use which one. And you can say they're all for editing words, but I use them, and a lot of people use them for different scenarios. The power of the IDE is that there's a whole set of... It's particularly powerful when you have very complex multi-step processes that will just simplify and automate it for you.

That is actually one of the biggest powers of the IDE. Think about, for example, what we demoed on stage in terms of mobile development. You're developing a bunch of code, we're compiling it, and then we're actually patching that into the device or emulator and setting up the debugger with it. We demoed very similar scenarios for Docker's development against our Azure AKS, Azure Kubernetes service, and from Visual Studio IDE. It's like a simple, almost F5 gesture, and all of that workflow is tightened for you. But, I mean, a lot of developers love that.

But there are also developers, for some scenario, they're like, I don't want to use your workflow. I want to go construct my own workflow. So I just want the code editor to go do a thing for me and I can go assemble my own workflow for me. That also happens. And so we're like, you know what? In that case, Visual Studio Code is great for you. You define and you decide what your workflow is. It's not going to pack these things up for you. So you have the full freedom to go do and write whatever code you want to go write.

And it provides a slight IntelliSense to help you, it has the slight capability of debugging to help you. So it's not going to decide your workflow for you. So we see those two things as fundamental differences in how developers approach certain scenarios. And so we think it's very valuable that we provide both of those to enable those scenarios. And so we think it's very valuable that we provide both of those to enable those scenarios. Well Visual Studio Code has been on fire lately. Everybody talks about it and is trying it and switching it.

It had a bad name, or not so much a name generally, but it seems like it's among the open source crowd. More and more people talk about it, and not just talk about it but also use it and be like, this is the best for this this or this is the best for that. And it's scenarios where they have workflows or it's scenarios where they don't really have workflows. And it's kind of a good fit for many. One thing that I always wonder with decisions like this

coming out of a large corporation like Microsoft where it's this new direction we're going to continue with Visual Studio we're also going to have Visual Studio Code. I wonder how that idea percolated and then who championed it and how it became,

as vice president of the Visual Studio section of Microsoft, surely you know, how did that idea come out? Did you think of it one day? Was it somebody on your team? Or like, hey, let's do VS Code alongside Visual Studio and run these things in parallel. Well, the decision, like most things in Microsoft, wasn't no one person's idea.

It's actually a lot of people have been discussing scenarios like this for a while. If you look at the code heritage of VS Code, a lot of that was actually in our monocle, was the online development environment, which Eric Gamma, who is our technical fellow, who is overseeing the project. Our initial thing was really when we look at it to say, hey, do we need to have a fully in the browser experiences? And that's actually where Eric's team was in the very beginning started working through on that.

And our learning is that we actually have the monocle editor embedded in a number of different scenarios. And what we learned is that developers really wanted a local, on their Mac or PC, on their own desktop kind of scenario, which is really not surprising because we have a lot of, Microsoft has 65,000 developers. That's kind of coding every day. And I remember we had this conversation. I remember Anders was there and eric was there and

you know a bunch of other people and we're like why don't we just make a local editor and we can it's an experiment we can see how the community you know thinks about it whether it's going to catch on or not and we have between eric gamma who obviously was one of the key folks behind eclipse back in ibm and um all of the vs folks we haveclipse back in IBM and all of the VS folks we have. We have many, many, many decades of experience building IDEs. So we know what are the key workflows and things like that, what are the thoughts. So we positioned it to be what we call a lightweight,

code-optimized editor. That was the key positioning. And we're like, that is the area we're really going to focus on, and we're going to have a very flexible extension system, and the way we design extension is going to be such that it can never interfere with the main editor experience, which is a core lesson that we have learned from both Eclipse and Visual Studio. I cannot necessarily say the same thing about the Visual Studio extension system or the

Eclipse extension system. We have taken these lessons that we have collectively learned and applied it to the design of VS Code. And we initially were like, hey, let's try it out to see if it's actually something that's going to resonate with the market and to see if there's actually a developer need. And what we learned was, yes, there is one. And not to mention that it's always great when our strategy

of really serving all the developers came married very well with identifying good pain points and actually deliver a good solution. When those things come together, it's been super powerful. That's got to be exciting. It is very exciting.

And I think that as much as it's great for developers, one of the key things we're really hoping to show developers is that Microsoft is different. I mean, we can do marketing event all day long, but there's power in people using an open-source, cross-platform Microsoft code editor, code visual studio, code every day. And I think it's one of those things we are hoping is to,

it will help developers worldwide see us in new light. Can you speak to that change? Maybe since it's out there now, more and more people are using it. How has the feedback loop, so to speak, of you putting it out there, having this hypothesis that this will happen and it does begin to happen? Well, I think that the thing is that the first thing I will say that the hypothesis is like, well, really the reaction is that we always, I will say that, you know, as Microsoft people, we think we have pretty good tech, but I think that, you know, we made in the

past, we're more closed. Now when we come out and open, what we really didn't know is whether the community will welcome us, will actually truly embrace. That was the question in our mind. There's really not that much question that we'll have great tech, that will actually be a good product. And once we put it on GitHub, we were just amazed by how many contributors, they're telling their logging issues, they're working with us out there in the community.

And Visual Studio Code, in GitHub's latest ranking, we are number one in terms of contributors. We are double, almost double, the next project, which is Facebook's React Native in terms of contributors. That's just totally amazing. And there's lots and lots of active discussions going on in VS Code GitHub repos. And it completely changed the way of how our team works.

Because before we actually are engaging with the community, like when the team was working internally before the launch, we work on a monthly sprint schedule for that particular team. And once we started to open source on GitHub, the community feedback come in, and the team realized they need to go spend up to 30%, 40% of their time interacting with community

on GitHub, triaging issues, respond to requests, and address any concerns. You have to be active on the community in order to have that kind of level interaction. One of the phrase I increasingly say is that we're not only customer obsessed, which we are now, we're also community obsessed. Because we really view the community as extension of our team. And that is true for Visual Studio Code,

and that is also true for.NET project we have, or TypeScript, all of these main GitHub repos that we actually drive. So do you see the analogy of Microsoft Word, it would be your IDE, and then your notepad would be your VS Code, and they serve different niches, different contexts, right? Do you see that as lasting 5, 10 years down the road, them running parallel, or do you see VS Code as eventually becoming

the one true editor as it usurps its established product? I think that one of the things we have learned in the last five years as well is that we used to do five-year planning. We no longer do that because the tech world changes so fast. Five years ago, can you imagine we're here talking about these things

and talking about Kubernetes and containers? It's a different world. It's a different world. That's the best non-answer I've gotten in a long time. That's a very good non-answer. Because you're right. The answer is we don't know. We don't plan five, ten years out.

We really don't anymore. And if we do, then that plan is irrelevant. It's irrelevant by the time the five years hits. Because who knows what's going to happen next year. It's just a bad guess. Or a good guess. It could be good. You know what?

If I'm going to bet on it, anything I guess right now, it's going to be wrong. Right. It's just going to be wrong. I mean, like, you know, again, you know, like, if you go back, think back in 2012, can you imagine the world, not just about what happened to Microsoft, but can you imagine all the technology advances

that we're seeing today? What's going on with AI? What's going on with machine learning? What's going on with containers? You just talk about technical advances. I was like, no, I absolutely could not. So whatever I guess will be wrong. That much I know.

If I look five years up. So I think that the most I personally think the best way for us to really keep you know keep going forward is to have a very tight engagement loop constantly hear our customers feedback right understand in the new world what are the new pain points our customers are experiencing and continue to provide value to our customers like that's continue to provide value to our customers like that's really quickly right that's actually the way to kind of keep moving forward with the industry we're creating new technologies other companies creating new technology the entire

industry is moving up very fast and we just have to go keep going you know with that flow this episode is brought to you by our friends at TopTal, the best place to work as a freelancer or hire the top 3% of freelance talent for developers, designers, and finance experts. In this segment, I'm talking with Jeff Mazur. My name is Jeff Mazur, and I'm a TopTal finance expert. And Jeff has a pretty awesome background for a freelancer. So I asked Jeff to share what differentiates TopTile as a global talent network and the process he had to go through to ensure he could be trusted as a finance expert for TopTao. The differentiator I see between TopTao and some of the organizations that are comparable or try to offer a similar type of service is that the people who are part of TopTao have really gone through pretty extensive screens. So in my case, for example,

I probably spent 20 hours of preparation and conversation and interviewing to make sure that I was the right fit for TopTal. So what I offer and what other TopTal finance experts, you'd come across thousands of people. I mean, given the frothiness of the market and the level of interest in the market, you know, everyone's a finance expert right now in ICOs. But in the case of TopTel, what they've really done is that they winnowed that huge group out to come up with people who really are experts in the field. So if you're looking to freelance or you're looking to gain access to a network of top industry experts in development, design, or finance, head to TopTal.com and tell them Adam from the Change Law sent you. That's T-O-P-T-A-L.com. And for those out there wanting a more personal introduction, email me, Adam at ChangeLaw.com. And for those out there wanting a more personal introduction, email me, adam at changelog.com.

And by GoCD. GoCD is an open source continuous delivery server built by ThoughtWorks. It provides continuous delivery out of the box with its built-in pipelines, advanced traceability, and value stream visualization. With GoCD, you can easily model, orchestrate, and visualize complex workflows from end to end.

It supports modern infrastructure with Elastic On-Demand Agents and cloud deployments. And their plug-in ecosystem ensures GoCD will work well in your unique environment. To learn more about GoCD, visit gocd.org. It's open source and free to use. And there's also professional support and enterprise add-ons available from ThoughtWorks. Once again, go cd.org slash changelog. You've been there from the beginning. I have been there.

Take us to the beginning. Before VS Code was VS Code. There's a previous name? There's a previous, well, it's called Visual Studio Online Monaco. Windows Online Monaco. No, Visual Studio Online, in quotes, Monaco. Okay. So what this, well, so I'll take you back to the very beginning. It started out with an experiment to see if we could

build an HTML and JavaScript-based code editor that could be hosted in the browser. I think Chrome had just been. What year is this? Six years ago, so 2000. 2001. So I think Chrome at that time just came out with the notion of web workers, so being able to run processes, which then enabled us to be able to do things

like have IntelliSense and errors and things like that. So Eric Gamma had basically started on that project. That was his first project at Microsoft. And built that up. We needed some way to dog food the editor. The correct term is champagne the editor. Champagne, is that what it is now? Yeah, you don't to dog food the editor so the correct term is champagne the editor champagne is that what it is yeah you don't say dog food anymore think how weird it is our own dog food really how about this we drink our own champagne it implies good stuff no matter

what just think about it maybe try it on for size i'm gonna have to work it through a couple times but i like it so we champagned um the editor by building a little bit of a workbench around the editor that we could then develop the editor with. So it was like a little bit explorer and editor and source code control I think we built in there. But it really was done as a little node server that ran locally on the machine. So you HTTP whatever and you get this little workbench up, full access to all your files for the editor.

And we build the editor and champagne the editor at the same time. And so we built out this editor, which actually was pretty popular across Microsoft. Like if you go to OneDrive and you look at source code, that's that's the editor. Azure, any place you go in there and look at source code, that's the Monaco editor. It's the same editor that's in VS Code itself. If you go to Edge and browser, and even maybe IE, I don't know, the F12 tools, in Windows and look at source code, that's the Monaco editor.

It's a bunch of other places. So that got pretty popular. And as we did it, we built more and more of this workbench around the editors. We had this locally hosted development environment, which since it was running on Node and it was an HTML and JavaScript thing, it could easily be moved up to the cloud. So we kind of looked at what's the next step

from a code editor, like, well, we want to develop a fuller web-based app. And Azure websites and all that stuff are starting to come online. And so what we decided to do is say, hey, can we host this workbench in Azure so that you could do live editing of your websites straight in the portal? And so we said, yeah, let's do that. We kind of brought that up online, which was fairly easy because of the whole architecture. And we branded that or named that Visual Studio Online, quotes, Monaco.

So that's where it originated from. And then 2001. No, 11. By 2011 is when we started the editor. And probably it was 2013. Oh, yeah. 2001. No, it wasn't around 2001.

The space honestly. Yeah, yeah. So probably 2012 or 2013 when we did Visual Studio Online. And that was an interesting project. The thing that was difficult about it was that it didn't really enable a bunch of developers to do anything because you had, there were so many things that you had to do before you got there, right? Like, you had to have a subscription you had there were so many things that you had to do before you got there right like had to have a subscription had to have a website had to have this that you know pull out the magic whatever and then

you could use this online hosted tool but it was pretty cool like everybody you know there's a big wave of online hosted tooling that was going on around that time like cloud nine I can't remember all the... Ace? Ace was the editor that Cloud9 used. Cloud9 may have used Ace. There was two of them, Codemirror and Ace. Those were the two editors. And then Monaco was the third one.

Okay. I didn't recall that time period. Those things were never that sticky from a user's perspective. No. In the browser, you mean? Yeah. Browser-based tools were never... sticky from a user's perspective. No. In the browser, you mean? Yeah. Browser-based tools were never.

It was a big sell. It was like, you know, push, underpowered notebook, whatever, ID in the cloud. And Office had a suite of tools that actually work in the browser fairly well. There's a lot of things you could do and see a natural progression. You've got a desktop application, which would have been Visual Studio, and then you've got browser-based tools. But you're right. The challenge with those is that it was a bunch of challenges. The biggest one that we saw was that it was great. You've got your development tool in the browser,

but all your other tools are on your machine. And so there's no connection between the code that you're working on in the browser and, oh, I need to run this other tool at the same time. How do you bridge that gap? So it was an all-in scenario. You had to either go all-in on the cloud. Exactly.

And people aren't all-in on the cloud for building tools. Developer tools. There's latency. Network interruptions. Yeah. Requires an interconnection. Yeah, you can't work offline. Can't go under tunnels and stuff like that.

Work your New York City. There are cool aspects to it, right? Like the idea where you could go and just spin up an environment instantly and not have to provision anything on your machine. That's a cool aspect. It's great for educational means. I used to teach web development, and it's like we just spin up in a browser, and there's no prereqs.

It doesn't matter what operating system you're on. But when it came time for me to actually write a browser and there's no prereqs. It doesn't matter what operating system you're on. Yeah. But when it came time for me to actually write code, I'm not going to use that. Yeah, from an educational scenario where you've got this box that you're working in, it works great. So then what we decided to do, you know, it was kind of popular. But we decided, well, let's try to do, what we saw was we're actually getting a lot of people that were coming from non Windows machines using it like There's an audience out there that we could go and talk to that we today with the suite of tools Which was Visual Studio at the time we had nothing that we could go and say hey you Cool guy using a Mac sitting at Starbucks working on your web app

If I'm from Microsoft, I can't talk to you. I have nothing like I have to say Close your close your Mac. Right. Get rid of your operating system. Get rid of your tools. It's two worlds. Yeah. And be like, all right, go away.

At that point, you're like, I'm just drinking my coffee, man. Yeah, yeah. Get out. Get out of my face. So we decided to pivot and see if we could do a local client-based tool. Again, since we had this node infrastructure everything we moved it over to what was it called before it was electron there was electron before that was called atom shell but then there was the the before atom shell there was another um

tool that let you host node apps on the desktop so yeah so that was kind of the genesis of the whole thing um but then once we had that tool, we could say, all right, actually we have something to talk to people about. And we decided that we couldn't just come up with yet another code editor. Like, okay, there's Sublime, there's Notepad++, there's Atom, all these bunch of code editors out there. We have to do something different. So what we decided to do is we called it

redefining what the code editor should be in the modern world for a modern developer. And that was really about great editing experiences out of the box and great debugging experiences out of the box. So Visual Studio has always sort of had this strong debugging lineage, right? It's like, hey, what's the best debugger? A lot of people say Visual Studio. So what we want to do is kind of take the best of that, the best of the editing, bring that to the code editor space, and basically create our own place where we could say, you know what, we've got a tool that you can use.

It's going to be a better editing experience. You're going to get debugging. But it fits in with the rest of the stuff you're doing. You don't have to drop everything and come over to our stuff. Try it out. If it works for you, great. If it doesn't, try again in six months when we you know bridge and release features yeah yeah and uh so that was kind of the genesis of it and

and really that's that's that's the way it progressed right we had people kick the tires from it right away um and they used it for a short amount of time said hey it's missing xyz abc and it's not open source uh maybe we'll check in with you again in the future and so we just cranked away at it right with this whole good backlog of things to do and um and we still do it today right it's every month very public roadmap and all that stuff we're just constantly churning out you know required feature after required features so that people can actually just pick it up and use it so So, yeah, I mean, and then it's been fairly successful. What would be the tent pole features for somebody who's,

so as we said, like our audience and people in our community are very interested in it, people are trying it. It's won over a lot of people. We both downloaded it. We both used it. I'm still stuck on Sublime for reasons that I would love to talk to you, maybe offline or maybe with it online. Yeah, you can talk to me online. I'm happy to. Very impressed for reasons that I would love to talk to you maybe offline or maybe I'll do it online. Yeah, you can talk to me online. I'm happy to.

Very impressed. Everybody's very impressed. What are the selling points to, say, a Vim user or an Atom user? I know these are all very different users, but maybe, PJ, this is a good place for you to hop in. One aspect that seems like is there's batteries included to it in terms of the setup experience. But what do you guys consider when you're like, okay, here's what VS Code has going for it right out of the box today. What are its advantages that would compel somebody to switch or even just try it?

Yeah, well, I mean, like Chris said, really strong editing and debugging experiences. Out-of-the-box support for Node, JavaScript, TypeScript, that primarily is a function of that's the language that VS Code itself is written in, but expanding it to other languages like Python, like Java's recent one, Go. We've spoken with Rami in the past.

But that debugging experience that a lot of Visual Studio users have known and are somewhat used to, but we've been able to bring that to this VS Code package that can be delivered on any operating system. I think also a big component of it is, honestly, the openness and transparency of the VS Code team with the community. So I think a number of people that have been converts from other tools have been because they've been able to interact with members of the VS Code team on GitHub through issues or pull requests or even over Twitter. I think that's something that the team prides themselves on quite a bit is how open and how engaged they are

with the community of not just developers that use VS Code, but developers that use other tools. Yeah, I'll echo. To me, it's editing and debugging. So, like I say, you're a JavaScript guy, and you're using Sublime. You probably have a bunch of packages that you've figured out that you kind of like and recommend it from other people. It may or may not provide you with sort of a completion experience for plain old JavaScript. Yeah. So you open up in VS Code, right? You've got a folder, open it up, express application, come in, type in, you know, app.

You'll get statement completion, IntelliSense, overloads, all sorts of stuff about the express object without having to do anything. What'll happen is, since we use TypeScript as the language server for JavaScript, it does a whole bunch of work for us in analyzing the JavaScript, but it also goes and actually downloads TypeScript definition files, which basically people write TypeScript files which define or almost type the shape of regular old JavaScript libraries.

That's the coolest thing I learned today is that, to be clear, you don't have to be writing TypeScript yourself. You're writing your regular JavaScript, but in the background, what do you say, it's the language server? So I guess, yeah, you want to explain what that is? The language server? Go ahead. So basically what happens is, you know,

you've got your presentation of the source code, right? And we use TextMate grammar to syntax colorize, right? It's kind of standard across all editors. But when you want to do IntelliSense or object browsing, you kind of need a language server which will effectively offer up an AST and send that back over to VS Code. And so there's a whole spectrum of support for languages and extensions for VS Code, and the ones that are the best, like JavaScript or TypeScript or Python or Go, There's a whole spectrum of support for languages and extensions for VS Code.

And the ones that are the best, like JavaScript or TypeScript or Python or Go, all have this language server that runs basically in another process. It's usually written in the language that it's running in, which is cool, right? Because if you're going to do Python, you probably have a Python machine. But it's smart enough to give you all that semantic information about your source file. So for JavaScript, we use the TypeScript compiler. We just spin that thing up because it basically runs as JavaScript. Right. And it's smart enough, gives you all completions,

all this, everything that you need. There is warnings, but as far as you're concerned, from as a JavaScript guy, who cares? It's just there. Seamless to you. Yeah, it just gives you. But it gives you all the benefits of using it. I mean, not all the benefits of using it.

I mean, not all the benefits of writing in TypeScript. You get a good amount. A good amount of free... Yeah, and more and more come online every month with TypeScript. But I think there's two components there, which is, one is bringing the TypeScript to writing JavaScript and VS Code is what gives you the ability to write var x equals some string. Then when you call in x dot, you get string completions, not just every completion that it could possibly be because it's JavaScript and you're not sure. Right, it's all that. But where some of the TypeScript definitions come in is understanding of Node, understanding of Angular.

So we can sort of go in the next step in, you know, why we say IntelliSense necessarily instead of autocomplete. Yeah, there's thousands of TypeScript definition files for all the popular Node packages or JavaScript packages that are out there. The other thing I wanted to note on this point was, I just forgot what it was. It was coming to me, sorry. Also, let's focus in on the debugging aspects. So when I think about IDEs and text editors, I think of like... Oh, wait, can I go back to what I remembered?

No, I'm just kidding, go ahead. All right, so the other thing about TypeScript and JavaScript, like, it is, you can do sort of like a single file, you know, var x equals some string and go x and give you like, oh, I recognize that's a string, right, parse, you can do that. But with TypeScript, it works actually cross file. All the files and folders in your workspace,

you can sort of say, here's the universe of things. So then I get completions against things that are in other files. As long as they're in the same project or folder. Yeah, and you can even go so far as put a JSON file in the folder to say, here's what my workspace looks like. Here's what my project looks like. Include these files.

Exclude these files. This is how I want the compiler to run against and configure it quite a bit. But by default, it just happens. So, sorry. That's all right. If I didn't jump in there, I would have lost my mind. Very good. No problem.

What was I talking about? Debugging. Debugging. I look at text editors and IDEs very differently because I don't expect debugging from a text editor. They usually have limited debugging. Some of them have, you know, like I'm used to a command line debugger. I'm more of a,

what I call a puts debugger or I don't, you know, trace debugger, which is the person who's putting the print statements in. Um, so I'm, you know, not a good developer. We find out there's lots of us who just,

you know, yeah, we had this conversation logs. Yeah. I can't remember. We had this conversation. Firefox, not Firefox,

but a Mozilla debugger. Yeah. The debugger inside the Firefox. That's right. Um, projects.ger inside the Firefox DevTools project. So that being said, I watch other people do some debugging, and I see the value. I see the stuff that you demoed today, and that's what I'd like you to go into.

Give us the real juicy, because for me it has to be a killer feature for me to be like, all right, I'm going to start using this and the debugger in my life where I'm ingrained to just throw some console logs and see what happens. Talk to us about the debugger inside VS Code and some of the stuff you show with the live shared debugging, like this craziness

that I think people would be interested to try, even if they're not debugger people. Yeah, so I should say console.log is just fine. Everybody does it, right? Oh yeah. But I think the biggest thing for me when debugging, right, so once you press F5 the debugger spins up, the biggest thing for me is that it's easy to set a breakpoint.

I don't have to plow through oodles of console.log output to figure out where it is that something is happening. Okay, this is the general area, hit a breakpoint, and then I get an immediate window that comes up, or REPL, and I can come in and evaluate expressions right there. So I can start to understand what x is, what y is, and figure out where they are.

Inspecting values is just that much faster. You don't have to litter your code with console.logs. You don't have to take it out. You don't have to deal with all the output that happens. But still, at times, console.log is still a very useful thing, so I'm not saying that it completely replaces it. And, of course, you get call stack. You get watch windows and all sorts of goodness.

I think all of those extra things. So I should preface it with I do just trace statements, but I'll often use kind of what I call weak debuggers, like a pry tool. Like in Ruby there's a gem called pry. It's a stop the world type of a thing, and it gives you the REPL. But it doesn't provide the call stack. And you can dig in for those things, but you're not seeing frames here and you don't have a list of locals.

There's just less Chrome around it. What we try to do is strike this balance between the power of the debugger and what we present in the UI. So it's not... It's overwhelming. Yeah, so it's not overwhelming. We try to not be overwhelming in VS Code.

We actually try to make it so that people that write debuggers can actually contribute things back to the explorer on the left-hand side. So for a particular language, if there's something that's really useful for that language, they can contribute it. But everybody is not then bombarded with that UI. So we try to make it pluggable for the debuggers. The shared debugging stuff we showed today was actually really cool because, I mean the scenario was really like, hey, can you come over here and look at this?

Help me debug this thing. And basically you sit there and you build step, step, step, step. But if you're in another room, another place, be able to let you do it. So this really struck me. I know it's worth it. This is not screen sharing.

It is not screen sharing. It's sharing of the debug session and the data and the breakpoints and the instruction pointer, call stack, everything. And the whole workspace. So it's not just one file.

It's not just what's active in your window right now. It's the whole workspace that you currently have. Collaborative on the same session or what do you call it? Yes, collaborative on the same editing and debug session, which is really cool. And it really struck me, right? Like there's always this time when you have a feature that comes online

and you're like, okay, I get it, right? Or like, oh, I can no longer live without that. And quite honestly, two weeks ago, we were preparing these demos, right? And there was another, like the team that does the live share was getting their part done and we were bringing the two things together for the demo. And I was running into a problem with the Docker extension that I demoed today, and it was pretty deep in the bowels of VS Code where the exception was getting thrown.

And I was sort of in a panic, and I'm like, hey, can somebody help me debug this? And so one of the guys, half the team's in Switzerland, one of the guys said, hey, I'll stay on the phone call with you and we'll of the guys half the teams in switzerland one of the guys said hey i'll stay on the phone call with you and we'll debug the process we'll debug it after we finish this other meeting i'm like cool so i screen share with him and he's like okay put a break point here he's like oh wait no you close the file open that file back up again yeah okay all right no put okay step step step over step nope step into that one all right let's restart

like it's just this whole like him guiding me on what to do right plus the latency over the sea and the latency and it was just a huge pain and then as we started to build up the scenario and stuff and i'm like i just kept thinking if only alex and i had this two weeks ago it would have been a game changer and That was, to me, the moment where I went, oh my god, I get it. I kind of feel like shared editing is a little bit

of a... How often are you two going to write the same code together in the same file? There's a lot of people that practice pair programming. In that case, I think it makes a lot of sense. I agree. In many many cases it seems like a like a good marketing thing to say it's live collaborative editing and it's like we've all done that with docs but you know is the real value

there with code i think if pair programmers probably it is but with lots but for the debugging was the thing that really got and it totally sold totally sold you. Yeah, right then and there. I was like, okay, got it. This is it. And so, I mean, that's the thing that was really cool, I think, about the Live Share thing is the fact that it's the workspace and literally there is no node on that other machine. And as part of this demo,

we actually went through this whole process where we were debugging the web app running in a Docker container on my machine. Because you can basically attach to a running Docker container, set breakpoints, and debug the code that's in there. And so we were sharing... It's like next level stuff. Yeah. Because the other guy, the other person on their site, all they need is the editor.

They're connecting to your session, so they don't have dependency. They don't need any of that stuff. So we were actually... Or VS Code. Like, it's not even necessarily... They don't need to have VS Code. They can have... I mean, Amanda had Visual Studio 2017,

so Chris is going from VS Code on a Mac to Visual Studio on a PC. So what does that session data look like on the wire? Is it some sort of... It has to be a normalized format that at least those tools can use. Is it a thing that, you know, you could publish a spec and people could plug it in.

So I could be using sublime and you could be using VS code. And because we both, you know, whoever wrote the sublime side of it wrote to that format, they could get the session data. I mean, is that a potential thing or. I think it's definitely a potential thing.

I don't know if it's in the roadmap or where it is in the roadmap, but if you think about it, it makes sense. It's kind of like we talked a little bit about language servers earlier. We actually have this thing, protocol. It's called the Language Server Protocol that we made open source and public and everything, which basically means that any editor or IDE can use the language server and plug into the environment. So you can use Sublime with TypeScript and get a pretty rich editing experience because it goes to the language server protocol.

So you can imagine that in this model that there's a protocol that's running over the wire so one editor can connect to another editor or IDE or whatever it is. Right. And that can be something that's open sourced and all editors take advantage of and it's basically a plug-in for each editor. But I don't think we're far enough down the road yet to say, okay, here we've got this protocol.

Everybody go build. You just demoed the feature for the first time. It was the first time. Yeah. So it's brand new stuff. But the model makes sense, right? And it is definitely, it's a protocol. It's funny to see sort of the big circle of life,

and we were talking about this earlier, about recycling names. Like a lot of stuff in VS Code, standard in, standard out, right? Yeah. Piping, and it works really well. Yeah. So you can do the same thing with these as well.

Nothing new under the sun. Just new names. That's right. Let's talk about the roadmap a little bit. We've seen what you've been up to. First of all, are there any major features that are just clearly still lacking that someone says, well, I can't switch because of feature X, and you guys are all like, yeah, we know that's coming.

Are there any of those? And if not, what else is... Well, the biggest one that we just shipped literally last week was multi-root workspace support. So up until now, if you want to open up two folders at the same time, you have two instances of VS Code. And what we now support is the ability to have multiple top-level folders open at the same time.

Language servers work against them, extensions work against them properly. We've been working on that for six months, probably. There's a lot, a lot of work. It's been in Insiders for a few months now. Yeah, so the Insiders has had it for a while. And really in the last milestone, we kind of held off releasing it in stable because we wanted to do a push to make sure that the top extensions that are out there were all multi-root aware. There's sort of this very root API that had an assumption about the fact that there was one workspace and just wanted everybody to use that. So we had to make sure that people were supporting the fact that you could have multiple routes like

the old singleton design principle problem yeah there's only ever going to be one of these yeah and then six months later you're like it'd be great if there was two of those or n of those right so that has clearly been the biggest one that people have been asking us for. There's a long tail of things that people are looking for. The other thing we just released was the ability to have the horizontal pane that's at the bottom of the debugger, debug console, terminal, everything, put that to be vertical in the space. If you had a widescreen monitor, you can have your console on the right, code in the middle, explorers on the left.

And I think that's kind of, you see a lot of feature requests from people stemming about wanting to have more control over the editors, the layout of the editors inside the environment. So I want to be able to split horizontally or vertically at the same time. So those are things that we'll start to, now that we're sort of out of the multi-route workspace push, which was a lot of people across the team. In the short term, like really for the upcoming month, month and a half left in the calendar year, it's really just a push on performance and bug fixing and not a whole slew of new features. We publish our roadmap on GitHub in our Wiki.

And so you can go up there and there's just a whole slew of things I have to think off the top of my head what's in there. Well, if it's published, we don't even talk about it. Click the link. Click the link in the show notes. No, but that's one of the things that we try to do is every six to twelve months

we put together a you know 12 to 18 month roadmap we publish that on the wiki and then for each milestone we go through a whole planning process we publish that we make it real um and we turn from draft into like this is the plan and then at the end of each milestone, we publish our end game, like schedule and process and testing and all that stuff. So everything is completely out there in the open. And a lot of these elements, I don't think the roadmap, but like the iteration plans and things like that, not only are they visible and readable, but you can comment on them and react to them. So it's good because you get real-time feedback just as we post the plan. What's the larger motivation of this project?

You mentioned earlier, and I think we kind of talked a bit about with Julia, about any app or any developer, any... What's the mission? Please remind us of Microsoft's mission. For VS Code? Just Microsoft's mission in general Code? just Microsoft's mission in general

to like any developer any app any platform there you go so given that what's the motivation for VS Code you mentioned

back to the original scenario Jared's in Starbucks he's cool he's on a Mac and you have nothing to offer him you know right

you're mostly cool and he's using an editor right so he's using an editor and you have nothing to offer him so what's the motivation what is the you know

the mission statement I guess behind VS Code like why why this editor why are you guys doing this what's the larger picture well I think the larger picture is like

the world is no longer a place where you can say we've got this thing this great thing come to us and use it and you'll be happy right people are like,

no, I've got all these other tools and things that I'm using. And I kind of mentioned this before, like we didn't have anything for this whole class of developers, not on Windows, not using IDEs, very sort of modern webby node oriented developers,avascripts all that we had nothing to talk to you about there was no way to have that conversation you were a developer we were never going to be able to attract at all and so the motivation for vs code was to break down that barrier and say actually you know what we do have something that you could use and then we give that to you and if you like it cool right maybe there's some other stuff from us that you'll use at And then we give that to you. And if you like it, cool. Maybe there's some other stuff from us that you'll use at some point in the future. And if you don't like it, at least

we had a conversation and maybe in six months, you'll hear about it from your buddy. Oh yeah, I know. Yeah, I heard about it. Let me go look at it again. And maybe at that point, there's enough stuff for you to sort of come on board. But the days where you could say, here's our developer ecosystem, come to our ecosystem, drop everything else you're doing, that's over, right? And Microsoft can't survive in that model. So we really had to sort of turn around

and say, well, we've got tools for everybody. We've got great tools. Like we have a history of having awesome tools. And by virtue of using our tools, perhaps you will also use these other things that we have. Such as? That's great.

Azure. Azure. Azure. Yeah. Yeah. Is it to attract essentially things to the brand name of Microsoft that they are no longer side-eyed, as you've used the term before? Like people are...

I guess there's... You're kind of getting this level of respect back that may have not been there from every developer out there. I think, I mean, so you could say, if you looked at it and just said, oh, the goal is to get people to do Azure. I think that's not the entire story because that can't be your only goal. Your other goal has to be, I believe, to be an excellent player in the developer ecosystem. And then that requires you to do things like be open source, be transparent.

You're a valid person in the ecosystem. Because if not, developers don't like you. And so you can't have one without the other. I think you can't just say, all right, we're on the ecosystem, but we're closed, we don't do anything, and we're closed. We don't do anything. And then we want you to use Azure.

No, you have to be a viable member of that ecosystem in order to be even considered. So we have to do both of those things. And I think our mission for the past couple of years seriously has been

the first part. Go break down all those old barriers that Microsoft put up for all these developers out there that just aren't on our stuff. Just go make people happy. That literally was Scott's directive

when we first did this. He just said, all I want you to do, don't worry about anything else. Just go get your first X thousand people, make them happy developers. That's empowering. That's an interesting mission.

It's funny to me because when we talk about open source and motivations and stuff like that, it's not money. There's other reasons people do open source, but a lot of them boils down, whether it's a big company like Microsoft or Adam Sikowiak. We just want people to like us. It boils down to, be my friend. You guys like us? Yeah. I mean, think about it.

I do cool open source. People value it. They benefit from it, and they'll like me. I mean, it's very kind of a base motivation, but we all kind of share it, even though we have our other reasons as well. Just interesting. You've got to be a good citizen. Yeah. That's the've got to be a good citizen. Yeah. That's the truth. Nobody likes a bad citizen.

Well, you have a bright spot on you if you're not. A bright spot like a shadow. Either or. Pick your metaphor, but the point I'm saying is you stand out. If you're not a good citizen, you stand out. I think you're almost ignored.

It's easy to recognize that. At the point where a large majority, I don't know if it was a vast majority, just irrelevant. It doesn't matter. It doesn't speak my language. So it had to break that down. So that has been our mission. How's that going? Is that happening?

I think so. So you said that Scott gave you that mission go make people happy, go make developers happy. What was your, you know, how did you track that?

How do you even measure that? How have you measured that? There's a bunch of ways we look at it. Let's see. Downloads probably is an impactor, right? Downloads is

a bit of a vanity metric because you can download it all you want, but if you don't use it, it doesn't really matter. Okay. So we look at usage, engaged usage of it. Do you have analytics on usage? We do. Is that an opt-out sort of thing?

Yeah. What's that? Like you opt out of that during download? I forget that question often. If you're checking analytics, essentially of usage. Yes, you can opt out of that? You often get that question often if you're tracking analytics, essentially, of usage. Yes, you can opt out of it. Okay.

Definitely. So we look at that. We watch Twitter quite a bit because you get a very sort of instant pulse as to what's going on. We look at NPS scores, a standardized score. I guess Facebook came up with that. I don't know a whole bunch about the history of it, but it's basically your ratio to promoters versus detractors

based on a quick survey. The net promoter score. Yeah, the net promoter score. How likely are you to delete? It turns out it's a... Yeah, there's a lot of people that do that, but it turns out to be very effective. I think it's effective because it's a single question, through ten. Yeah, you just click it. You're done. Yeah

And a lot of the lead it a lot of the middle are actually thrown out It's really it's only the people at six months in the low end. I'm sorry about it's the haters and the lovers Yeah, because those are the ones that actually have the impact on other people. That's right. Multiplicative effect. Yep. And we look at that. Issues, sentiment that come in through issues. What else are we looking at? In our blog post that we published for this event, for Connect, we shared that in November,

monthly active users, so people who used the tool once that month, 2.6 million, I think, was the number. Yep. So that's a pretty decent number. That's a good number. That's like during the month of November. Yeah. How many people were on the team? So there were about 25.

I could go through all the names and I could count them all. I think it was like 10 in Zurich and 12-ish. I really throw the hard balls at him. There you go. 25-ish? So the problem is this, right? If I get the number wrong, because there are so few people on the team, I'm really cutting one person off, right?

Someone's got to know exactly. It was 300. Okay, yeah, it's 302. It doesn't really matter, But there's like 22. Everyone's going to be like, Chris forgot about me. Yeah, yeah, yeah. Wait, and then he says 11. And it's like, no, there's one person less.

It's roughly that. I'll take roughly. And I'm also thinking about the Slack channel that we have because there's extra people in the Slack channel, which are not on the core team. Well, the reason why I asked that was I wanted to measure that next to the community contributors and just see how much it's been embraced from a contribution perspective. Because a good community member of the open source, even though it's a product, and so there's product roadmap and vision, like you said, the roadmap's published and commentable. Are there other people outside of Microsoft that are contributing? Have you gotten that going?

And then how does that play back into the editor? Yeah, I can't remember the numbers off the top of my head. Maybe you know them, but we are one of the top projects on GitHub. Every year, GitHub releases sort of like a report that, you know, it's kind of like their State of the Union, I guess, where they share a couple of metrics. And one of the metrics was open source projects ranked by contributors. VS Code was number one. We had the most contributors of any repo on GitHub. Wow.

The link is also in the blog post they posted. I don't remember the URL off the top of my head. Send us that. And there was a couple other ones on there and there was also a number of contributions and things like that. But yeah, I think in short, the question, how much does the community contribute to the growth and improvements in VS Code? It's a lot. If you look at the release notes every milestone,

we actually list out all the people that did pull requests that we were able to pull in in that milestone. It's in the 10s and 20s every month. What do you think you've done that has enabled that? What are you doing well that other projects that aim to have your mission can learn from you? How many? 429 on the VS Code repo.

There may be other repos as well. Yeah, the report lists a different number. I don't know exactly how they calculate the difference. It's still a good number. There was one which was of all Microsoft projects, we were number one. And then there was another one which was all of GitHub. I think we were the number one Microsoft project. I'm not sure if we're the number one overall.

That would make more sense. There's over 5,000 forks, which is a good number. You have 94 open pull requests, 5,000 plus open issues, very active. 2,259 closed pull requests. So there's a good metric there. 94 open may sound like a lot open but when you have you know 2200 closed you're making your way through them so yeah anyways back to adam's question so what was the question again sorry what have you done to enable this kind of contribution uh let's see i

think it's a bunch of things it's not just one um i think things that we've done right are the transparency in our planning. Putting that out there, let people comment on it, seeing what the roadmap is, I think has been very useful in that. I was just talking to another guy earlier, PJ and I, where the fact that we sort of recognize folks that are actually contributing to the project has been a huge motivator for people. It's almost like GitHub commits where you're like, hey, it's my resume. People take this huge pride in being recognized the fact that they contributed to the project. And we're excited about it. And we say, hey, thank you.

And then people are like, hey, my pull request got in. So there's a lot of that that goes on. I think there's also, we've been, right from the get-go, we kind of published, like, here's sort of the guidelines about how to contribute to the product and what we're trying to do and all that stuff. I think when people ask us questions, we're honest, right? Like, hey, you know, why are you doing this? Or why isn't this open source or that open source or license or questions like that? We're like, this is what we did, and here's why. And people appreciate that honesty.

When we screw up, we admit it. We go out and say, yep. We had an orange icon. People didn't like the orange icon. Yeah, there was controversy around the icon recently. A little bit. A little bit. But the point is, they changed it.

Yeah, we respond. You're open. You're transparent. They changed it. Yeah. Yeah, we respond. You're open. You're transparent. You respond. You care. Yeah. Right. You're quick to change when change is required.

Yeah. And it's not a free-for-all, though, right? It's not just like a rudderless project. It's like this is what we're doing and this is where we're going. Right. We'll take feedback and everything in it. What's one, in less than a minute, what's one call to action for those listening? What's a good first step?

Download it, play with it, check out issues. What's a good call to action for those out there listening? Go download the Insiders builds. Get those Insiders builds. They're great. Tell us about that because our community is very much, we're enthusiasts, we're hackers. And so is this for a nightly build, right?

It is our nightly build. I was saying this morning is the exact same build that we use to build VS Code. Insiders build. Insiders build comes out every night Zurich time. Where do you go for that? On the download page is a big green button to download VS Code there's an arrow next to it if you click on the arrow it'll show you both stable and insiders. And so it'll update every morning. Basically, you just kind of get into this rhythm of, okay, I'm just going to update,

and it takes a couple seconds, and boom, you're ready to go. Brand new features every morning. Brand new bugs sometimes every morning. Brand new bugs. Brand new bug fixes, too. Oh, yeah. But if you think about it, since we're using it to go build VS Code, any big blockers we usually hit,

and we're not afraid to go pull the trigger and re-release an insider's bill that people are blocked by it. So I would A, I would go and do that. B, you can go look at how to contribute which is in the wiki. I would look at the iteration plans. I know you want to and then I would go do a query for I think it needs help or help wanted In the repo where you can see places where you can start to kick the tires the cool thing about it It's really easy to sort of use vs code to build vs code and we have full instructions on how to do that so you can run vs code you can Develop it at the same time you can hit a breakpoint and debug it from vs code

That's a cool easy way to get started there. Very cool. And learn about TypeScript too because it's mostly written in TypeScript. Change your life. Change your life. All right.

Thank you so much for your time today, guys. Yeah, no problem. Thanks. Thank you. All right, that's it for this

episode of the Change Log. Thank you for tuning in. And if you enjoyed the show, you know what to do. Share with a friend, rate us on Apple Podcasts, go on Overcast, go on Twitter, tell everyone you know. And special thanks to our sponsors, Auth0, DigitalOcean, TopTow, and GoCD.

Also, thanks to Fastly, our bandwidth partner. Head to Fastly.com to learn more. We host everything we do on Linode cloud servers. Head to linode.com slash changelog. Check them out. Support the show. This show is hosted by myself, Adam Stachowiak, and Jared Santo. Editing is done by Jonathan Youngblood.

And our awesome music is produced by Breakmaster Cylinder. You can find more episodes just like this at changelog.com or by going to Apple Podcasts or Overcast or Google Play and subscribing. Thanks for listening. We'll see you next week. Thank you.