Microsoft no longer develops PowerShell behind closed doors. While there are perks to the tool's move to open source, users must cope with the consequences of the shift.
Now that PowerShell is no longer just for Windows -- and is an open source project -- what are the long-term implications of these changes?
Microsoft technical fellow Jeffrey Snover developed Windows PowerShell based on the parameters in his "Monad Manifesto." If you compare his document to the various releases of Windows PowerShell, you'll see Microsoft produced a majority of Snover's vision. But, now that this systems administration tool is an open source project, what does this mean for the future of PowerShell?
I've used PowerShell for more than 12 years and arguably have as good an understanding of PowerShell as anyone. I don't know, or understand, where PowerShell is going, so I suspect that many of its users are also confused.
When Microsoft announced that PowerShell would expand to the Linux and macOS platforms, the company said it would continue to support Windows PowerShell, but would not develop new features for the product. Let's look at some of the recent changes to PowerShell and where the challenges lie.
Using different PowerShell versions
While it's not directly related to PowerShell Core being open source, one benefit is the ability to install different PowerShell versions side by side. I currently have Windows PowerShell v5.1, PowerShell Core v6.0.1 and PowerShell Core v6.1 preview 2 installed on the same machine. I can test code across all three versions using the appropriate console or Visual Studio Code.
One benefit of the open source move is Windows PowerShell v5.1, PowerShell Core v6.0.1 and PowerShell Core v6.1 preview 2 can run on the same machine.
How admins benefit from open source PowerShell
The good points of the recent changes to PowerShell include access to the open source project, a faster release cadence and community input.
Another point in favor of PowerShell's move is that you can see the code. If you can read C#, you can use that skill to track down and report on bugs you encounter. If you have a fix for the problem, then you can submit it.
Studying the code can give you insight into how PowerShell works. What it won't explain is why PowerShell works the way it does. Previously, Microsoft MVPs and very few other people had access to Windows PowerShell code, but with the PowerShell Core code now available to more people, it can only make it a better product in the long run.
Facts about PowerShell
The PowerShell Core project resides in a GitHub repository. Initially referred to as PowerShell Core because it used .NET Core rather than the full .NET framework, the team now calls it PowerShell.
The term Windows PowerShell is used for the version installed on Windows operating systems, which can be downloaded to upgrade an earlier version.
The PowerShell team expects to deliver a new release approximately every six months. The team released PowerShell v6.0 in January 2018. At the time of this article's publication, version 6.1 is in its third preview release, with the final version expected soon. If the team maintains this release cadence, you can expect v6.2 in late 2018 or early 2019.
A faster release cadence implies quicker resolution of bugs and new features on a more regular basis. The downside to a faster release cadence is that you'll have to keep upgrading your PowerShell instances to get the bug fixes and new features.
Of the Microsoft product teams, the Windows PowerShell team is one of the most accessible. They've been very active in the PowerShell community since the PowerShell v1 beta releases by engaging with users and incorporating their feedback. The scope of that dialog has expanded; anyone can report bug fixes or request new features.
The downside is the expectation that the originator of the request is expected to implement the changes. If you follow the project, you'll see there are just a handful of community members who are heavily active.
Shortcomings of the PowerShell Core project
This leads us to the disadvantages now that PowerShell is an open-source project. In my view, the problems are:
it's an open source project;
there's no overarching vision for the project;
the user community lacks an understanding of what's happening with PowerShell; and
gaps in the functionality.
PowerShell's inventor gives a status update on the automation tool
These points aren't necessarily problems, but they are issues that could impact the PowerShell project in the long term.
Changing this vital automation and change management tool to an open source project has profound implications for the future of PowerShell. The PowerShell Core committee is the primary caretaker of PowerShell. This board has the final say on which proposals for new features will proceed.
At this point in time, the committee members are PowerShell team members. A number of them, including the original language design team, have worked on PowerShell from the start. If that level of knowledge is diluted, it could have an adverse effect on PowerShell.
The PowerShell project page supplies a number of short- to medium-term goals, but I haven't seen a long-term plan that lays out the future of PowerShell. So far, the effort appears concentrated on porting the PowerShell engine to other platforms. If the only goal is to move PowerShell to a cross-platform administration tool, then more effort should go into bringing the current Windows PowerShell functionality to the other platforms.
Giving the PowerShell community a way to participate in the development of PowerShell is both a strength and a weakness. Some of the proposals show many users don't understand how PowerShell works.
Giving the PowerShell community a way to participate in the development of PowerShell is both a strength and a weakness. Some of the proposals show many users don't understand how PowerShell works. There are requests to make PowerShell more like Bash or other shells.
Other proposals seek to change how PowerShell works, which could break existing functionality. The PowerShell committee has done a good job of managing the more controversial proposals, but clearing up long-term goals for the project would reduce requests that don't fit into the future of PowerShell.
The project is also addressing gaps in functionality. Many of the current Windows PowerShell v5.1 modules will work in PowerShell Core. At the PowerShell + DevOps Global Summit 2018, one demonstration showed how to use implicit remoting to access Windows PowerShell v5.1 modules on the local machine through PowerShell Core v6. While not ideal, this method works until the module authors convert them to run in PowerShell Core.
One gap that needs work is the functionality on Linux and macOS systems. PowerShell Core is missing the cmdlets needed to perform standard administrative tasks, such as working with network adapters, storage, printer management, local accounts and groups.
Availability of the ConvertFrom-String cmdlet would be a huge boost by giving admins the ability to use native Linux commands then turn the output into objects for further processing in PowerShell. Unfortunately, ConvertFrom-String uses code that cannot be open sourced, so it's not an option currently. Until this functionality gap gets closed, Linux and macOS will be second-class citizens in the PowerShell world.
