Visual Studio Code Open Source: What Code - OSS Actually Gives You
Source code for Visual Studio Code (Code - OSS), the MIT-licensed editor that combines a simple code editor with debugging, navigation, and a rich extensibility model.
At a glance
- What is it?
- The microsoft/vscode repository is the MIT-licensed core of Visual Studio Code, but the shipped product adds proprietary bits. This review separates the open source base from the Microsoft distribution and tells you what to expect when you build it yourself.
- Who is it for?
- Adopt the microsoft/vscode repository if you need a customizable, MIT-licensed editor base and you are willing to build and maintain your own distribution. Do not adopt it if you expect the exact Visual Studio Code product with Microsoft branding, telemetry, and proprietary components; those come only from the separate product license.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Split Between Code - OSS and the Product
The repository calls itself Code - OSS, and that name matters. Microsoft develops Visual Studio Code in this repository with the community, but the Visual Studio Code product you download from the website is a distribution of this source code with Microsoft-specific customizations. Those customizations are released under a traditional Microsoft product license, not the MIT license that covers the repository. So the open source project and the commercial product are not the same thing. The README says this plainly: Visual Studio Code is a distribution of the Code - OSS repository with Microsoft-specific customizations. If you clone microsoft/vscode, you get the base editor, not the branded product. That distinction is the first thing to understand, because it affects every decision about licensing, updates, and feature availability.
What the Repository Actually Contains
The repository is written in TypeScript, and it includes the editor core plus a set of built-in extensions in the extensions folder. Those built-ins include grammars and snippets for many languages. Extensions that provide rich language support, such as inline suggestions and Go to Definition, carry the suffix language-features. For example, the json extension provides coloring for JSON, while the json-language-features extension provides the richer support. That separation is a design pattern worth noticing. It means the core editor stays lean, and language intelligence is layered on top as extensions. The README also points to related projects that live in separate repositories, such as the node debug adapter and the mono debug adapter. So the repository is not a monolith. It is the center of a larger ecosystem, and some components you might expect to find here are actually maintained elsewhere.
How the Editor Works: The Core Loop
The README describes the product's purpose as combining the simplicity of a code editor with what developers need for the core edit-build-debug cycle. That is the mechanism in one sentence. The editor provides comprehensive code editing, navigation, and understanding support, along with lightweight debugging and a rich extensibility model. The extensibility model is the key architectural piece. Because language features are delivered through extensions, the core editor does not need to know the specifics of every language. Instead, extensions register capabilities, and the editor exposes them through a consistent interface. That design is what allows the same editor to handle JSON, TypeScript, Python, or any other language, as long as an extension exists. The trade-off is that the core editor alone is not a full IDE. You need extensions for serious language work, and the quality of that work depends on the extension, not the editor.
Getting It Running: Build Requirements and Commands
The README does not give a full build command list, but it does document the hardware floor. To run a full build, you need at least 4 cores and 6 GB of RAM, with 8 GB recommended. That is a real constraint. A typical laptop with 4 GB of RAM will struggle or fail. The repository includes a development container for Dev Containers and GitHub Codespaces. For Dev Containers, the recommended path is the Dev Containers: Clone Repository in Container Volume... command, which creates a Docker volume for better disk I/O on macOS and Windows. For Codespaces, you install the GitHub Codespaces extension and use the Codespaces: Create New Codespace command. The README also links to the How to Contribute wiki page for the actual build steps, which means the commands are not in the README itself. If you want to build from source, you will need to follow that wiki, not just the README.
The Development Container Is the Onboarding Path
The development container is not an optional nicety. It is the documented way to get a consistent build environment. The README points to a .devcontainer/README.md for more information, and it gives a direct link that triggers a clone into a container volume. That link assumes you already have VS Code and Docker installed. If you do not, the container path will not work. The container approach solves a real problem: building VS Code from source on a clean machine is heavy, and the container isolates the toolchain. But it also adds a dependency on Docker or Codespaces. If you are in an environment where Docker is not allowed, you are on your own for setting up the build. The README does not describe a native build path in detail, so the container is the supported route.
Licensing and the Forking Question
The repository is under the MIT license, and the README states that explicitly. That means you can take the code, modify it, and distribute your own version under the same license. That is a genuine advantage for teams that want to fork the editor. But the Visual Studio Code product itself is under a separate Microsoft product license, and it includes customizations that are not in the repository. So if you build from source, you do not get the Microsoft branding, and you likely do not get the telemetry or the proprietary components that ship in the product. The README does not list those customizations in detail, so you cannot know exactly what is missing without comparing the product to a source build. That uncertainty is a cost. You have to decide whether the MIT base is enough for your use case, or whether you need the product's extras, which come with a different license.
Where the Documentation Goes Thin
The README is short and mostly points elsewhere. It links to the wiki for the roadmap, iteration plans, and contribution guidelines. It links to the How to Contribute page for build steps. It links to a Related Projects page for the full list of components. That is a reasonable structure for a project this size, but it means the README alone does not tell you how to build, how to debug, or what the coding guidelines are. You must visit the wiki. For an engineer evaluating adoption, that is a hurdle. You cannot assess the build process from the repository material alone. The README also does not mention testing, performance, or known limitations. Those topics are presumably covered in the wiki or issues, but the README does not cover them. If you are deciding whether to fork this repository, you will need to dig into the wiki and the issue tracker before you can make a confident call.
Alternatives and the Real Difference
The obvious alternative is to use the Visual Studio Code product itself, without building from source. The difference is not just branding. The product is a distribution with Microsoft-specific customizations under a different license. The open source repository is the base, and the product is a derivative. If you just want an editor, download the product. If you want to modify the editor, you need the repository. Another alternative is to use a different editor entirely, such as Vim or Emacs, which have their own extensibility models and are also open source. But those are not forks of VS Code. They are separate codebases with different architectures. The real comparison is between using the repository as a base and using the product as a black box. The repository gives you control, the product gives you convenience. The README makes that trade-off clear, even if it does not spell it out.
Editorial conclusion
Adopt the microsoft/vscode repository if you need a customizable, MIT-licensed editor base and you are willing to build and maintain your own distribution. Do not adopt it if you expect the exact Visual Studio Code product with Microsoft branding, telemetry, and proprietary components; those come only from the separate product license. Before you start, verify your build environment meets the documented 4-core and 6 GB RAM minimum, and check the wiki's How to Contribute page for the current build steps, since the README points there for details. The repository is the right choice for teams that want to fork the editor, not for teams that just want to install an editor.
Community notes