PowerShell Became Open Source and Cross-Platform in 2016
Microsoft's August 2016 announcement put PowerShell on GitHub and introduced it on Linux and macOS, changing its scope well beyond Windows administration.
On August 18, 2016, Microsoft announced that PowerShell was becoming an open-source project and made early alpha packages available for Linux and macOS. The source appeared on GitHub under the MIT license, turning a Windows-centered automation environment into a cross-platform project developed in public.
The object pipeline was already the defining difference
PowerShell pipelines pass .NET objects between commands rather than requiring every command to flatten its output into lines of text. A later stage can address properties such as process names, identifiers, or memory values without reparsing columns intended for a human display.
Cross-platform support extended that model to Linux and macOS, but it did not make every Windows-specific cmdlet portable. The engine, language, and broad module ecosystem can run across systems; modules that depend on Windows-only services or APIs still remain platform-specific.
Open development changed the feedback loop
Hosting the code, issues, and pull requests publicly made it possible for users outside Microsoft to inspect implementation choices, report platform-specific behavior, and contribute fixes. The move also accompanied a shift from the Windows-only product lineage toward the separately installable project now called PowerShell 7.
Windows PowerShell 5.1 did not simply disappear. It remains a Windows component built on the older .NET Framework and is still required by some legacy modules. PowerShell 7 is the actively developed cross-platform edition, installed side by side under the pwsh executable.
Why the announcement was historically significant
Microsoft had already begun releasing major developer technologies as open source, but PowerShell was an especially visible systems-administration tool. Bringing it to Unix-like systems acknowledged that contemporary infrastructure spans operating systems and that one automation language can be useful across those boundaries without pretending the underlying platforms are identical.
The runtime swap that actually made cross-platform possible
Windows PowerShell’s original engine is built directly on the .NET Framework, a Windows-only runtime — no amount of source-code openness alone would have made that combination run on Linux or macOS. What actually enabled cross-platform support was pairing PowerShell with .NET Core instead, Microsoft’s separately developed, genuinely cross-platform .NET runtime; this new combination shipped under the name PowerShell Core, reaching general availability as version 6.0 in early 2018 following the 2016 open-source announcement. The distinction still matters today: PowerShell 7 (the current cross-platform line) runs on .NET, while Windows PowerShell 5.1 remains a separate, Windows-only, .NET Framework-based component still bundled with Windows itself.
Why this specific technical dependency chain matters for anyone scripting across both
Because Windows PowerShell 5.1 and modern cross-platform PowerShell 7 run on genuinely different underlying runtimes, not every module or script written for one is guaranteed to behave identically on the other, even though the scripting language itself looks nearly the same on the surface. A module wrapping a Windows-only COM object or relying on a .NET Framework-specific API can fail or behave differently under PowerShell 7’s .NET-based runtime — worth checking explicitly, especially for any automation originally written years ago for classic Windows PowerShell, before assuming it will simply work unmodified once moved over to run under the newer, genuinely cross-platform engine on a different, non-Windows operating system entirely, rather than the original, native Windows environment the script or module was first written, tested, and actually verified against. Related: How to Build a Cross-Shell Dotfiles Repository · Command Substitution vs Process Substitution
Sources: