[simonrobb]

It doesn't really cost anything to open source something though. These are all projects which are developed for a reason: the commercial version might be prohibitively expensive at Uber scale, or not technically capable of operating at Uber scale, or just plain doesn't exist yet. At that point you can engage with the tech community and offer it as OSS (not to mention make your engineers happy), or you can keep it to yourself and eventually lose that opportunity to somebody else.

[dougk16]

> It doesn't really cost anything...

Depending on context, sure this could be true. Like if you're comparing the cost of releasing some small OSS module of Uber's to Uber's annual revenue, sure, it's going to be a negligible cost. But if you compare against the cost of developing the module in the first place, it can easily be an equal expense. For example I spent several months on a BLE library for Android (https://github.com/iDevicesInc/SweetBlue) and asked my company to open source it. It took several more months to get the library to a point that was suitable for a proper OSS release. So cleaning up code, making sure no sensitive info, swear words and such, documentation, lawyery stuff, icons, PR copy, blog post, basic website, wiki, and much more nitty gritty I'm glossing over.

I mean a company can just throw code over the wall into GitHub and call it OSS, but I associate a basic level of polish with a proper OSS release that does indeed take a good amount of effort. And that's just initial effort! If it becomes at all popular then you have further ongoing overhead.

I'd say a general rule is that open-sourcing something is at least 50% of overall cost of the project.

[simonrobb]

> So cleaning up code, making sure no sensitive info, swear words and such, documentation, lawyery stuff, icons, PR copy, blog post, basic website, wiki, and much more nitty gritty I'm glossing over.

I'm the manager of one of Uber's OSS projects, and all that the things you listed here ring true. I just know that in our case at least, OSS prep absolutely pales in comparison to the feature/operational work put in by the team.

To be clear, when I added "really" to that first sentence it was meant to communicate that there is some cost, but in the sense that it's negligible to Uber's losses, as you point out. I was responding to OP's "dubious use of resources" comment. But I can see that wasn't clear.

[dougk16]

Yup I gotcha, I wasn't really disagreeing with you, just adding the obligatory "well actually it depends" comment. ;)

[joncrane]

>I'm the manager of one of Uber's OSS projects

Do you expect to still be doing this same job (or one step higher) in 6 months?

[simonrobb]

Yeah absolutely! It's a successful project and pretty integral to Uber, I love what I do and have a lot of faith in my manager/director. I don't anticipate any reason for our situation to change.

[joeyaiello]

> 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.

[JMTQp8lwXL]

Tangent: Could you explain why I might want PowerShell on MacOS or Linux, if I use those as my primary OS? (I usually only open my windows VM for checking that my websites work in IE 11).

[joeyaiello]

Linux is actually half of our usage on PS Core[1], so it's a great question. A lot of folks use PowerShell inside of CI/CD pipelines, especially for cross-platform app development of .NET Core applications (having a single build/test/deploy script is often cited as vastly preferable to trying to maintain a split of .ps1/.cmd/.bat and .sh/.py/.rb).

But also, lots of folks prefer an object-oriented pipeline. Many of those folks (our primary use case for 10+ years has been IT management) are used to PowerShell on Windows and starting to learn or be exposed to other environments.

We've also got lots zsh-style optimizations in PSReadline. In some cases, we've got some catching up to do, but there's also lots of unique interactive optimizations hiding around[2].

It's also great for interactively exploring REST APIs and building scripts via that experimentation. Try running

Invoke-RestMethod [or irm] https://api.github.com/.

Store that as a variable:

$a = irm https://api.github.com

And then look at all the properties you can explore:

$a | Get-Member [or gm] $a.<tab><tab><tab>

Oh, and of course, one of the big reasons is "so you don't have to open a Windows VM to remote into your Windows Server boxes and manage them from a Macbook".

This is obviously not an exhaustive list, but it'd take a lot more time to write about every benefit and scenario here. In any case, it turns out that our user base is pretty spread out among different scenarios, but between our repo and usage numbers, we've been really happy with how excited that such a diverse group of folks really love PowerShell.

And feel free to reach out to me on Twitter @joeyaiello if you ever want to talk more about your experience (or just hop into our GitHub repo). :)

[1] https://aka.ms/PSGitHubBI [2] https://docs.microsoft.com/en-us/powershell/module/psreadlin...

[JMTQp8lwXL]

This was far more detailed than I expected. You seem very passionate for PowerShell. The rest method exploration looks very cool, I knew I might learn something cool by asking. Thanks!

[xmichael999]

100% agreed, I started doing this for a small project my company has. We don't really use it anymore, but it would be helpful to many hobby projects however we are now sitting here saying 3 weeks work to just give this code away? ick.

[novok]

A lot of this work is self made at companies although.

[sbarre]

That's not true. It costs quite a bit to open source a product if you're a commercial entity.. It needs to be reviewed (by legal, security, engineering, etc) and approved..

You're not just flipping the public/private flag on the repo.

[on_and_off]

Also, the doc, blog posts, feedback from the community, evangelization at conferences, thinking out the API design so it answers enough cases, not just yours, all take engineering time, that's not free.

[CydeWeys]

We open sourced my team's project a few years ago ( https://nomulus.foo ) and it was a substantial amount of work. There's everything you're saying plus a fair amount of engineering to get the darn thing working externally; we were built/hosted within the Google monorepo which is obviously not externalizable. And you end up spending lots of time writing documentation that you hadn't ever gotten around to when it was just a project being worked on by a handful of engineers all sharing adjacent desks.

[est31]

Not disagreeing but elaborating: The costs are higher when it's an already existing product of which parts the company doesn't fully own enough rights of for publishing. Even higher when it's not known which parts are fully owned by the company and which parts are of foreign origin. The costs are lower when it's meant to be open sourced from the start and it's been a project constraint since before the first line was written.

[simonrobb]

Of course. But compare that cost to (say) six full time engineers pumping out code for a couple of years. It's not the dominant cost by any means. Not to mention you're paying those other folks a salary regardless.

If it helps you attract better talent, well - there's a financial incentive there through increased efficiency which I'm sure on its own is more than equal to the review cost.

[gowld]

Why would you give your open source code a tighter security and engineering review than your in-house code? Are you hoping for security through obscurity? And quality through obscurity?

[VBprogrammer]

If you are going somewhere where you have to get changed in public, say the gym, do you make sure you are wearing your good underwear?

[sbarre]

I'm pretty sure I didn't say anything like that?

[rifung]

> It doesn't really cost anything to open source something though.

Yes, it costs next to nothing to just open source a project if you mean literally just putting the source on some hosting site.

However, open sourcing something properly, where you respond to issues, document things properly, and provide build/test infrastructure to external developers is much more work. Not only that but you have to be much more careful when creating APIs and be much more vigilant about keeping backwards compatibility.

[theincredulousk]

There was the fixed cost of developing it, and then the potential lost revenue of not selling it, similar to an opportunity cost.

If the presumption is that the software would be useful ("developed for a reason") economics suggests there is some price people would be willing to pay for it, and you forfeit that when you make it OSS. That absolutely costs something.

Sure you may not want to be in the business of commercial software (support, maintenance, ultimately just responsibility) which is a completely sane thing to avoid. However when you are bleeding money at the rate of a small country's GDP per year, avoiding opportunities to generate profit based on intangibles like community engagement can come off as ill-advised. In fact, if your company is declared bloated, it stands to reason that you should have the capacity to take on the additional overhead of selling the software. It is not that contributing to OSS is wrong, or that your points are wrong, just that there is a time and situation for this kind of strategy.

Contrast with Amazon, whose entire development of AWS was for the reasons you point out. Instead of open-sourcing it, to the extent that would be possible, they made it into a product and almost in a single move turned consistent overall loss into a massively profitable company.

So this is not at all to argue against the merits of having healthy OSS contribution at a company, but more to say that a company can't contribute to OSS if they are bankrupt - so avoiding the latter should be prioritized over the former.