Microsoft has just announced a milestone: the Windows Subsystem for Linux (WSL) is now open-source. At Build 2025, the company confirmed that the WSL codebase has been published on GitHub, allowing anyone to download, build, and modify it. In the official announcement, Microsoft wrote “the code that powers WSL is now available on GitHub … and open sourced to the community”. This marks a major shift in development for WSL: after years of growing the platform internally, Microsoft is fully opening it up so the community can contribute fixes, features, and enhancements directly.

Microsoft used Build 2025 to flip two big switches at once:

• The entire Windows Subsystem for Linux code-base is now MIT-licensed on GitHub — CLI tools, background services and the user-mode pieces that power WSLg are all there for you to clone, hack and ship patches. (blogs.windows.com, theverge.com)
• The same drop bumps the Store package to version 3.0 (nick-named “WSL 3”). Besides the source release, 3.0 promotes last year’s experimental work — mirrored networking, automatic memory/disk reclaim, a Zero-Trust security model and a forthcoming Settings GUI — to stable defaults. (devblogs.microsoft.com, bleepingcomputer.com, neowin.net)

In short, WSL 3 is faster, safer and far easier to manage than the 2019-era WSL 2 that first brought a real Linux kernel to Windows.

The move wasn’t sudden – it caps a long evolution of WSL. Here’s a quick history of WSL’s journey so far:

• WSL 1 (2016) – Introduced with the Windows 10 Anniversary Update, WSL 1 was a translation layer that let Windows natively run Linux ELF binaries. It implemented Linux system calls inside the Windows NT kernel via a “pico” process provider (lxcore.sys). This gave developers basic bash and command-line tool support on Windows, but compatibility and performance were limited by the translation layer.
• WSL 2 (2019) – This was a complete redesign. Microsoft launched WSL 2 with Windows 10 version 2004, replacing the translation layer with a real Linux kernel running inside a lightweight Hyper-V–based VM. The result was far better compatibility (full syscall support) and much-improved performance. In practice, most Linux workloads (compilation, servers, etc.) now run at near-native speed on Windows. Indeed, Microsoft notes that WSL can use fewer resources than a typical VM while still running Windows and Linux tools on the same files. (That is, WSL2 boots quickly and sheds memory when idle, but behaves like running on bare metal for most tasks.)
• WSLg, GPU and Systemd (2020–2022) – As WSL’s community grew, Microsoft added big new features. GPU compute support (for AI/ML) and WSLg (the Windows Subsystem for Linux GUI) allow users to run Linux graphical applications on Windows. systemd support was also introduced. In short, WSL began to feel like a full Linux environment. By late 2022, WSL was removed from the Windows image and distributed via the Microsoft Store as its own “WSL package”, allowing updates independent of Windows releases. (Windows 11 24H2 was the first build to migrate users to this new Store-based WSL.)

Overall, WSL has steadily matured into a very capable Linux layer on Windows – and now it is officially WSL 3, an open-source project.

WSL 3 and Open Source

With WSL 3, the key new feature is transparency: all the main WSL components are on GitHub. As Microsoft put it, “you can download WSL and build it from source, add new fixes and features and participate in WSL’s active development”. The GitHub repository (microsoft/WSL) now contains the Windows-hosted executables (wsl.exe, wslconfig.exe, wslg.exe), the WSL service (wslservice.exe), and the Linux init/daemon binaries that run inside the VM. In other words, almost the entire pipeline – from the Windows launcher to the in-VM daemons – is open-sourced.

Importantly, this enables direct community contributions. As one TechRadar headline noted, “By open-sourcing WSL, Microsoft has opened it up to direct contributions, feature development and bug fixes from the broader community”. Microsoft’s own engineers acknowledged this shift: “WSL could never have been what it is today without its community… we can’t wait to see how WSL will evolve now that the community can make direct code contributions”. In practice, developers can now file GitHub pull requests to improve networking, file sharing, performance, or to add features (just as open-source projects normally work).

Most WSL components are now open-source; only a few Windows-specific drivers remain closed. For example, the WSL1 kernel driver lxcore.sys (which handled syscall translation in WSL 1) and the Plan9 network redirector (P9rdr.sys, p9np.dll) are still proprietary. Since WSL 2’s architecture no longer uses lxcore.sys, these closed pieces affect only the legacy mode. In all other respects, WSL 3 is community-owned.

Inside the WSL architecture, Windows and Linux work in concert. On the Windows side, the WSL service (wslservice.exe) launches the virtual machine and Linux distributions, and tools like wsl.exe or wslconfig.exe invoke commands or configuration. On the Linux side, a minimal init system and helper daemons run to provide WSL features: networking, port forwarding, and the 9P file server for sharing the Windows filesystem into Linux (and vice versa). The diagram above illustrates this design. With WSL 3 open-source, all these parts can be inspected and improved by developers. For example, engineers can now study or tweak how wslservice.exe boots the VM or how the Plan9 server shares files.

Beyond transparency, WSL 3 retains all the performance and compatibility advantages of WSL 2. Because WSL 3 still uses the Linux kernel in a hypervisor, it enjoys “full system call compatibility” with Linux. Microsoft emphasizes that WSL “requires fewer resources (CPU, memory, and storage) than a full virtual machine” – meaning it boots fast and scales memory efficiently. In practice, developers find that most Linux build tools, web servers, databases, and other software run on WSL almost as fast as on native Linux.

Another visible enhancement is GUI and hardware support. WSLg – already open-sourced – provides a Wayland/X server so graphical Linux apps can display on the Windows desktop. For instance, developers can run Linux editors, browsers or visualization tools directly in Windows. GPU acceleration (for CUDA or DirectML, e.g.) is also supported in WSL 2, so ML and HPC workloads can run on the GPU from Linux programs. In fact, both the WSLg package and the custom WSL2 Linux kernel itself were already on GitHub, reflecting Microsoft’s commitment to full-featured integration.

Figure: Linux GUI apps running via WSLg on Windows. In this example a Linux graphical editor (gedit) is open inside Windows 11. Microsoft’s WSLg (shown enabled above) allows X/Wayland Linux GUI support on Windows, and WSL’s custom Linux kernel is also open-source.

What’s New and What’s Next

By open-sourcing WSL 3, Microsoft isn’t just releasing code – it’s inviting innovation. We expect several benefits and use cases for developers:

• Community-driven enhancements. Now anyone can dig into WSL’s code. Developers could, for example, propose optimizations to the networking layer, add support for new hardware (e.g. improved USB passthrough), or tighten security by auditing the code. Long-standing feature requests – perhaps slow to arrive in previous closed development – can now be addressed via GitHub pull requests. In short, WSL can evolve faster and in more directions than if Microsoft tried to tackle everything internally.
• Cross-platform development. Many developers need to target both Windows and Linux (for example, web backends on Linux servers, or cloud services). WSL makes it trivial to build and test Linux applications on a Windows machine. With WSL 3 open-source, Windows becomes an even stronger choice: a developer can run a Linux-based toolchain or container inside WSL, debug it, and iterate – all without leaving Windows. Likewise, Windows-first devs can more easily pick up Linux tooling knowing it’s fully supported.
• DevOps and CI/CD integration. Automated build pipelines often use Linux container workflows. With WSL 3, Windows machines (including build agents) can natively run those same scripts and Docker images. For example, a Windows server could use WSL to run a Linux container for testing, without spinning up a separate VM or switching hosts. Open-source WSL means teams can customize that integration if needed (for instance, tweaking how Docker Desktop uses WSL under the hood).
• System-level and hardware tooling. System programmers often use specialized tools (debuggers, cross-compilers, embedded Linux SDKs) that historically ran only on Linux. WSL 3 removes that barrier: the same tools can now run on Windows with full functionality. And since the WSL kernel is open, kernel hackers can even experiment with alternate Linux kernels or drivers in the WSL VM. GPU-accelerated compute (for AI training, simulations, etc.) is also fully supported via WSL, and open-sourcing may enable better tuning or wider hardware support in the future.
• Enhanced collaboration and transparency. Open-sourcing WSL fosters trust. IT and security teams can audit the WSL code for vulnerabilities or compliance. It also aligns WSL with other open-source devs tools: developers who use (and contribute to) open-source projects can feel more confident using WSL, knowing they can view and change its internals.

Why This Matters

In our view, Microsoft’s move to open-source WSL 3 is a watershed moment for the Windows–Linux development landscape. It recognizes that today’s developers expect openness and interoperability. As Microsoft itself notes, this change “facilitates collaboration among WSL users, enabling them to engage in issue resolution and learn together as a community”. Instead of a closed, proprietary subsystem, WSL 3 becomes a community project.

This has strategic impact. Windows now offers a best-of-both-worlds environment: you get the Windows ecosystem and tooling and a first-class Linux environment, without compromise. For example, a web developer can run Apache or Nginx in WSL while editing code with Visual Studio on Windows, and debug everything seamlessly. In the past, achieving this might have required a Linux VM or dual-boot – both clunkier solutions. Now it’s built-in and crowd-sourced.

We also expect productivity gains. Because the community can contribute, common frustrations (like subtle compatibility quirks or performance bottlenecks) could be fixed more quickly. The modularity of WSL means even novel use cases – say, custom Linux distros for specific devices – can be supported if someone in the community builds them. Windows effectively gains the agility of open-source development.

Finally, there’s a symbolic message: Microsoft doubling down on open source sends a signal of respect toward the Linux developer community. Over the past decade Microsoft has embraced many open-source technologies (joining the Linux Foundation, open-sourcing .NET, acquiring GitHub, etc.). Making WSL itself open source may be the most emblematic move yet. It shows that Microsoft views the success of Windows as linked to the success of Linux – a profound shift from the “Linux is the enemy” era.

In summary, WSL 3: Open-Sourced is more than a version number – it’s a turning point. Windows developers now have unprecedented access to the Linux layer beneath them, and Linux-savvy developers have reason to consider Windows as a friendly host. We anticipate that in the coming months the Windows and Linux communities will co-create new WSL features and optimizations. For developers, this means the Windows Subsystem for Linux will evolve faster and in directions we haven’t even imagined yet, opening a new chapter in cross-platform development.

Key Takeaways:

• WSL has evolved from a syscall-translation layer (WSL1) to a full Linux VM (WSL2) with GPU/GUI support.
• In 2025, Microsoft open-sourced WSL (most of it), hosting the code on GitHub for community contributions.
• Technical highlights include the hybrid architecture (Windows+Linux components), near-native performance, and full support for Linux GUIs (WSLg).
• For developers, open-sourced WSL means easier cross-platform development, faster DevOps pipelines, and the ability to customize system-level tools on Windows.
• This move deepens Windows’ integration with Linux and underscores Microsoft’s commitment to developer productivity and open collaboration.

Run Linux & full-fledged GUI apps on Windows with the brand-new, open-source release

Because WSL is now an app, it updates on its own cadence — no Insider build required — but you must be on a supported OS build first. (blogs.windows.com)

Open PowerShell as Administrator and run:

# Fresh install: pulls the WSL 3 package, kernel and WSLg 
wsl --install -d Ubuntu

Already have WSL? Two lines get you to 3.0:

wsl --update      # downloads WSL 3.x
wsl --shutdown    # restarts the lightweight VM
``` :contentReference[oaicite:3]{index=3}  

---

## 3 — Verify you’re *really* on WSL 3  

```powershell
wsl --version     # shows WSL 3.x in the first line
wsl --list --verbose

If a distro still shows Version 1, convert it:

wsl --set-version <distro> 2   # WSL 3 builds on the 2-series architecture
``` :contentReference[oaicite:4]{index=4}  

---

## 4 — Update your GPU driver  

* **NVIDIA:** install the latest CUDA-enabled Windows driver.  
* **AMD / Intel:** grab the newest WHQL graphics package.  

The host exposes a *virtual* GPU to Linux, so **don’t install a Linux-side driver** — everything 3-D, Wayland and VA-API just works. :contentReference[oaicite:5]{index=5}  

---

## 5 — Install your first Linux GUI apps  

Inside your distro shell:

```bash
sudo apt update
sudo apt install gedit gimp vlc nautilus -y       # examples

WSLg sideloads each app into the Start-menu (and taskbar pin) automatically. Launch from Windows or run gedit & in the terminal. (devblogs.microsoft.com)

1. Blank windows or crashes → make sure you’re on WSL 3 and sudo apt full-upgrade.
2. libGL errors → outdated Windows GPU driver.
3. No audio → look for “PulseAudio (WSLg)” in Sound ► Output; if missing, wsl --shutdown.
4. Weird localhost mapping → remember: localhost from Linux → Windows; use wsl.localhost to reach Linux from Windows.

Microsoft’s engineers have hinted that the only closed pieces left (legacy WSL 1 driver and Plan 9 redirector) may follow suit, and that the Settings GUI plus Dev Home hooks will hit the main channel “later this year.” Meanwhile, the open-source repo is already accepting pull-requests — so if you’ve ever wanted to fix that one WSL quirk, now’s your chance. (blogs.windows.com, theverge.com)

Install the Store package, verify it shows WSL 3.x, and enjoy mirrored networking, memory reclaim, Zero-Trust security, a shiny Settings app (soon) and the freedom to fork the entire subsystem on GitHub.