Project Overview

PowerShell’s journey from a Windows-only administrative shell to a cross-platform automation framework represents one of the more significant pivots in Microsoft’s developer tooling strategy. When the team open-sourced PowerShell Core and rebuilt it on .NET Core (now .NET), they made a bet that the object-oriented pipeline model — where commands pass structured .NET objects rather than plain text — would resonate beyond its traditional Windows sysadmin base. With over 53,000 stars on GitHub, the project has clearly found traction, but the transition hasn’t been without friction. The codebase retains architectural decisions from its Windows PowerShell heritage, which occasionally surfaces as tension between backward compatibility and the desire for clean cross-platform abstractions. The decision to maintain Windows PowerShell 5.1 as a separate, closed-source product while evolving PowerShell 7+ in the open creates an interesting dynamic: new features and improvements flow into the open-source branch exclusively, meaning the Windows-only legacy version is effectively in maintenance mode while the cross-platform fork accelerates[1].

What It’s For

PowerShell fills a specific niche that traditional Unix shells don’t address well: working with structured data formats and APIs natively. Where a Bash pipeline passes strings that require parsing with awk, sed, or jq, PowerShell’s object pipeline means you can pipe the output of Get-Process directly into Where-Object CPU -gt 50 without text manipulation. This becomes particularly valuable for DevOps scenarios involving REST APIs, JSON configuration files, and cloud resource management — tasks that often require multiple tools in a Bash environment. That said, PowerShell’s syntax can feel verbose compared to Bash for simple file operations, and the learning curve for understanding when objects are being passed versus strings is non-trivial. It’s best suited for teams already invested in the Microsoft ecosystem or for automation tasks that involve significant data transformation. The cross-platform support means Linux and macOS teams can standardize on PowerShell without forcing Windows-centric workflows, though the shell’s Windows roots still show in some cmdlet naming conventions and parameter styles.

How to Use It

The core workflow revolves around the pipeline operator (|), which passes .NET objects between cmdlets rather than text strings. A typical pattern involves retrieving data with a Get-* cmdlet, filtering with Where-Object, selecting properties with Select-Object, and outputting in a structured format. The shift to .NET Core means modules from the PowerShell Gallery can be installed across platforms, though not all Windows-specific modules are compatible. One notable design choice is the separation between the pwsh executable (PowerShell 7+) and the legacy powershell.exe (Windows PowerShell 5.1), which can coexist on the same system — useful for testing migration compatibility but occasionally confusing for newcomers who expect a single binary.

Clones the repository to access source code, contribution guides, and build scripts

git clone https://github.com/PowerShell/PowerShell.git

Filters running processes by CPU usage and selects specific properties — the object pipeline avoids text parsing entirely

Get-Process | Where-Object CPU -gt 50 | Select-Object Name, CPU

Recent Updates

Latest Release: v7.7.0-preview.1 (2026)

Preview release continuing the .NET evolution with new cmdlets and cross-platform improvements

The release cadence shows active development with multiple point releases (7.4.15, 7.5.6, 7.6.0, 7.6.1) in quick succession, indicating a healthy maintenance cycle. The project’s trajectory suggests continued investment in .NET alignment rather than major architectural changes, which is pragmatic given the existing user base’s need for stability.

Sources & Attributions

[1] PowerShell 7+ is the only branch receiving new features; Windows PowerShell 5.1 is in maintenance mode — PowerShell/PowerShell README