Why I think PowerShell modules may lead to chaos!

So in my last post, I kinda hinted that I wanted to delve deeper into the quirk I noticed with the new 2.0 modules feature.  But, to tell you the truth, the quirk is not what I really want to talk.  I'm pretty sure the PSH product team will address the issue before RTM.  After all... this is only CTP3!

No... no... the thing that I really want to talk about is the impending chaos that modules might bring to the now growing PSH driven automation ecosystem.

Now, I'm not saying that modules themselves are a bad thing.  Like I said, in my last post, modules are now my second most favorite feature.  Furthermore, modules are meant to empower us by allowing our "automation works of art" to be more portable and hopefully less conflicting.  :>)

So... the root of my concern is more around the perfect storm that I feel is brewing based on the following items:

  1. PSH is becoming the definitive management interface and backbone for all things Microsoft.  To understand what I'm saying just look at what has started emerge within the Windows 7 beta.  :>)
  2. Also, the adoption of PSH continues to grow thus more people are both actively using it and creating things with it.
  3. Thus... the amount of modules, cmdlets, snapins, and so on will continue to grow.  With modules being a catalyst for even faster growth because it makes sharing so much easier.

At this point, you are probably asking yourself, "Why would all this be bad?"  After all, having PSH for the masses is a good thing.  Well, to summarize my concerns, a world in which the usefulness of PSH grows in the wild vs. with a gentle guiding hand can only lead to the following:

  1. A greater number of resource conflicts - While the product team is attempting to reduce this by employing modules.  Conflicts shall and will always happen when there isn't a captain manning the helm.  :>)
  2. Module, function, snap-in, and cmdlet overload - I already get annoyed when I have to wade through a list of cmdlets that is 400 rows long.  Just image trying to keep track of what everything does once everyone and their brother is pumping out modules!  It just gives me a headache thinking about it.
  3. Duplicated efforts - Do I really want or need 20 network management modules that kinda do what I want?
  4. A sea of digital signatures - You had to see this coming.  If everyone actually signed their modules (and ran PSH with the AllSigned execution policy), like they should.  Then we may have to trust 100s of differently signed modules.  Not necessarily something that I want to do, or manage.

Hopefully, you can see what I have concluded.  Or, maybe I'm just making a big deal about nothing.  But, if this is concerning to you, as it is to me, I propose the following solution:

We organize and create an open source project with the goal of establishing a common management framework based on PowerShell.  Kinda like... ummmmm... the .NET Framework only better.  Microsoft would still be a helm, and control things that are core.  But, the "community" would drive expansion, compatibility, and sanity based on need instead of software release schedules, profit, roadmaps, etc.

At the end of the day, it should be a win/win, I think...

If you like this, check out some other posts from Tyson:

Or if you want, you can also check out some of Tyson's latest publications:

Lastly, visit the Microsoft Subnet for more news, blogs, and opinions from around the Internet.  Or, sign up for the bi-weekly Microsoft newsletter(Click on News/Microsoft News Alert)

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)