Microsoft Open-Sources WSL Years After Its Debut

For years, Windows Subsystem for Linux (WSL) has closed the gap between Windows and Linux ecosystems. It’s used by developers, engineers, and system administrators who need the flexibility and power of Linux tools but primarily work in a Windows environment. However, on May 19, 2025, Microsoft made the critical and long-awaited decision to open-source WSL.

If you’re a security-conscious administrator taking advantage of WSL, this is a big moment for you! Open-sourcing WSL introduces transparency and community involvement, but it also creates challenges. It raises questions about security, system interactions, and the future direction of WSL. As someone responsible for maintaining secure and reliable environments, you’ll want to carefully consider what this shift means for your workflows and overall security posture. Let’s explore the history that brought us here, why this decision was made, and what you should watch out for as WSL evolves.

How WSL Got Here: A Quick Recap

WSL started as a bold experiment back in 2016 when Microsoft introduced it as part of the Windows 10 Anniversary Update. It seemed almost surreal at the time: a compatibility layer that could run Linux binaries on Windows without the need for a full-fledged virtual machine or dual-boot setup. Developers embraced it, but WSL1 had its quirks. It didn’t provide a true Linux kernel; instead, it translated system calls, which meant plenty of incompatibilities.

Then came WSL2 in 2019, and everything changed. Microsoft replaced the compatibility layer with an actual Linux kernel running in a lightweight virtual machine. This version brought almost full compatibility with standard Linux tools and workflows. For developers and admins, it was a game-changer. WSL2 wasn’t a perfect Linux environment, but it got close enough that it became indispensable in mixed-OS setups. Over time, WSL has been refined to integrate more deeply into the Windows operating system while also being manageable as a standalone package.

The evolution didn’t stop there. By 2021, Microsoft decoupled WSL updates from the Windows release cycle, allowing updates to be delivered independently via the Microsoft Store. This decoupling meant quicker feature rollouts and more flexibility for users. Now, with its open-sourcing, WSL is entering yet another phase, further aligning itself with the open-source Linux ecosystem it originally sought to emulate.

Why Open-Source WSL Now?

The timing of Microsoft’s decision to open-source WSL raises interesting questions. After all, WSL isn’t a brand-new technology—it’s been around for years. Open-sourcing could have happened earlier but didn’t. So, why now?

One factor is the community. WSL has always been built alongside valuable feedback from its user base, which includes both developers and sysadmins. Many of the features introduced over the years—like GPU compute support or better file system integrations—were driven by user requests. Microsoft might be signaling that it’s ready to take this community involvement to the next level by inviting direct contributions to the code.

Transparency likely played a role as well. With more enterprises demanding accountability in the software they use, offering visibility into WSL’s source code is a way to strengthen its position as a trusted tool in professional environments. At the same time, open-sourcing allows Microsoft to outsource some of the labor-intensive elements of software development and maintenance to the open-source community while reserving control over critical proprietary components. Notably, while much of WSL is now open source, parts of it—especially Windows-side drivers like lxcore.sys for WSL1 or file-sharing components like 9rdr.sys—remain closed.

Finally, there’s a philosophical shift at play. Over the last decade, Microsoft has increasingly leaned into open-source initiatives. From making the .NET platform open source to releasing its Linux-based operating system (CBL-Mariner) for cloud workloads, the company is clearly embracing the open-source model as a strategic advantage. WSL’s open-sourcing fits neatly into that context.

The Security Puzzle: New Opportunities, New Risks

For administrators, this open-sourcing announcement is both exciting and concerning. On one hand, transparency is always a good thing regarding security. Being able to audit code—or, at the very least, knowing security researchers and other contributors can audit it—makes identifying and fixing vulnerabilities easier. If Microsoft slipped up somewhere in WSL’s implementation, the odds of it being uncovered just increased dramatically.

But there’s a catch: not all of WSL is open source. Critical pieces, particularly on the Windows side, remain proprietary. For example, the drivers and components that handle file system redirection, allowing Windows and Linux to access each other’s files seamlessly, are not part of the open-source codebase. These areas are essential to how WSL operates, yet they remain beyond our scrutiny. This is worth remembering if you depend on WSL in high-security environments. Not everything you’re running is visible under the hood!

The other challenge of open-sourcing WSL is managing supply chain risks. If your organization decides to build WSL from its source or integrate community-driven updates, you must be vigilant about what code you’re pulling in. Malicious code could, in theory, find its way into an open-source ecosystem through unvetted contributions. This is a problem seen before in other open-source software, and WSL is not immune.

Dependencies also play a key role here. WSL is a Linux subsystem, not a standalone Linux distribution. It interacts deeply with Windows, meaning vulnerabilities in either operating system could cause problems for the other. Admins will need to stay on top of patch management for both their Windows environments and the embedded Linux instances running under WSL.

Navigating the Admin Workflow in a New Era

Beyond security, let’s discuss how this shift could change your day-to-day administrative workflows. Open-sourcing has immediate and long-term implications for using, securing, and managing WSL in your environments.

First, there’s the matter of control. By open-sourcing WSL, Microsoft gives administrators the option to customize the subsystem. If you discover that your team needs a specific feature or fix, and the official WSL release doesn’t include it, there’s now a clear path for adding it yourself or collaborating with the community to get it done. This flexibility will be a game-changer for teams that rely on WSL for niche or performance-specific workflows.

At the same time, it’s not entirely clear how Microsoft plans to govern this project. Open source doesn’t mean “hands-off.” Whoever controls the project’s direction—be it Microsoft, a steering committee, or the broader community—will ultimately dictate how it evolves. Administrators should keep a close eye on Microsoft announcements to understand who’s calling the shots as WSL unfolds as an open-source project.

Of course, there’s the challenge of pacing. With open-source contributions, updates, and new features might come faster, but that also means more frequent changes to review, test, and deploy. This could create friction if your organization has strict patching and update policies. If you rely on WSL in production environments, rolling out changes without testing them thoroughly could lead to disruptions.

What Should Admins Keep in Mind About This Transition?

As you assess this latest development, keep preparation at the forefront. Make auditing an absolute priority. Even if WSL seems secure now, its continued development could dramatically impact the risks you face. Your organization should devise a strategy to evaluate any updates as they come through and assess their impact on security and workflow before diving in headfirst.

Watch how Microsoft manages the project and community participation levels. Any time things move away from aligning with your organization, address it promptly.

Finally, training should be a top priority. Teams deploying or managing WSL should require their staff to become familiar with new features or capabilities as they're introduced. Keeping staff current ensures you can reap maximum benefits while mitigating risks.

The Road Ahead for WSL and Its Users

Microsoft’s decision to open-source WSL is bold, opening up opportunities for transparency, community contributions, and innovation. But it also places new responsibilities on those who rely on it. Security-conscious admins must balance the excitement of new possibilities with the practical realities of managing an evolving, open-source tool in complex, mixed OS environments.

As WSL grows in popularity, questions about its governance, proprietary components, and long-term impact will remain. For now, though, one thing is clear: the open-sourcing of WSL marks both an opportunity and a challenge. It’s up to administrators like you to decide how to make the most of it!