joeyaiello

I read all of it, as well as some more of your writings that I found, and I very much appreciate your thoughtfulness. I don't agree with everything you've said here, but you raise some very good points. Thanks, friend. :)

Unfortunately, we can't ever change that one, or the whole world of existing stuff will break.

It's intended as a shell semantic where anything bare on the command line just gets run, no matter your scope.

However when we introduced classes, we thought it was a more "dev-oriented" semantic, so we changed return there.

This will only return 'this will return':

  class foo {
    [string] ReturnTest() {
      'this will not return'
      return 'this will return'
    }
  }
  
  ([foo]::new()).ReturnTest()

We've fixed a ton of these in PowerShell 7 (pwsh.exe, as opposed to Windows PowerShell / powershell.exe), particularly because we needed to support Linux and more of its semantics.

If you're seeing issues within PowerShell 7, please file issues against us at github.com/powershell/powershell

PM lead for PowerShell here, thanks for the callout! I'll take "isn't the worst". ;)

I'd love to get more of your thoughts around how PowerShell might be more useful for the kinds of scenarios you're thinking about. We see a lot of folks writing portable CI/CD build/test/deploy scripts for cross-platform apps (or to support cross-platform development), but we're always looking to lower the barrier of entry to get into PowerShell, as it can be quite jarring to someone who's used Bash their whole life (myself included).

Structured shells have so much potential outside of that, though. I find myself using PowerShell to "explore" REST APIs, and then it's easy to translate that into something scripted and portable. But I'd love to get to a place one day where we could treat arbitrary datasets like that, sort of like a generalized SQL/JSON/whatever REPL.

Plus, PS enables me to Google regex less :D

I'm a PM at Microsoft that worked on open-sourcing PowerShell. As Windows PowerShell, it's a built-in Windows component, and the number of assumptions that could be made because it was both closed-source and part of the OS were immense. Even getting it to build outside of the rest of the operating system was crazy hard. Then figuring out to install it in a supported way was hard, and only then did we get to start figuring out how to eliminate usage of private APIs and start doing legal reviews.

And we're "just" a language runtime and a shell shipped in the OS. I can't imagine how hard it would be to unwind the proprietary bits of something like a GPU architecture running in a tightly integrated SoC with multiple vendors who are all deeply protective of their IP.

I say this all as someone who has been a proponent of open source for 15 years. And all the work was absolutely worth it, and deeply rewarding from a personal perspective.

But I can't say it would probably make the same sense for Nintendo to go through that effort with Pokemon or the N64 architecture.

> If it becomes at all popular then you have further ongoing overhead.

THIS is the one that comes into play. All that stuff you listed before is a slog to go through when you go to open-source, but unless you're parking the thing as a proof-of-concept/end-of-life, you're now signed up for maintaining the repo. That means triaging issues, pull requests, helping out when contributors don't understand why their build is breaking, etc.

And there's the PM aspect of it: you don't just want to develop a bunch of features without talking to your community, so communicating (in a public friendly way) what you're planning to work on, when folks might reasonably expect that, how they might be able to help out, which of their contributed features you might be able to take depending on where you're at in your lifecycle, and RESPONDING TO COMMENTS all takes way more time than just "building [closed-source] product" in a team of 5-20.

And of course, one of the hardest of all: telling people "no, we can't take that change" when they've spent hours and hours doing work for your project for free. In that regard, we're still very much iterating on a transparent design process that allows for consensus BEFORE too much work has been done (though as we all know, building prototypes is often one of the best ways to find out if a design works right or not).

If you're doing it all right, everyone involved in the project should be doing some amount of all of this every single day. There's no compartmentalizing an engineer on an OSS project as "someone who just writes feature code" vs. "someone who does the repo stuff".

So going back to OP's point: no, it doesn't literally "cost anything" (or very much) to do the basic act of open-sourcing, doing it the "right way" at scale where you're truly engaging and working with the bazaar is very expensive.

Full disclosure: I'm a PM at Microsoft working on PowerShell and was heavily involved in it being open-sourced and ported to macOS/Linux.

PM for PowerShell here, no ETAs right now, but we're working closely with some O365 teams (starting with Exchange Online) to bring their modules up to compatibility with PS 6.x.

As a product manager (technically "program manager" at Microsoft, but it's roughly the same as product managers across the industry), project management is one of the many things I do, in addition to the list above. But I am explicitly not a project manager in that I'm supposed to minimize time spent on that and share some responsibilities in that space with my engineering counterparts.