I think part of the problem is that a lot of big, "old school" companies seem to think their code is special. Every shell script, every ugly library, every half-functional API is some precious gem of intellectual property to be hoarded and protected at all costs.

We, of course, know that's completely ridiculous. But try convincing your manager that.

Hits close to home. Many closed sources libraries are nowhere near the level of _documentation_, quality, and collaboration that is routinely expected of open-source software.

Their code is special, in that is is unsuitable for open source due to how impossible it would be to describe to someone outside of the organisation how to use it!

I feel a bit like that with Microsoft open sourcing a lot of its projects. Ok so now I can get the MSBuild source code, great... but how the * do I understand it? And that's a developer focused company, let alone some company that paid some cheap developers to knock something up in houses 6 years ago that no one even in the company is brave enough to touch. They might not even know how to build it!

The point is to make their code open source they'd need to do a lot of work to document (at a minimum) and refactor (ideally) the code to make it good enough for open source. They'd need to remove dependencies on proprietary tools (in house or paid) as much as possible.

there's the opposite problem as well:

"We don't want our brand to be damaged by showing our bad code to the public"

So true. And these crappy wheels keep getting reinvented over and over at different companies. Sharing the effort and making a better wheel for everyone sounds like a good idea so long as it's not your core business. There must be a downside right?

> working on this project, will myself or my team be exposed to new skills and technology?

How much weight would you say you give this piece of criteria in the overall decision?

A lot! The devs get to weigh in a lot on this choice, and we chose OpenStack (almost) entirely because of the ancillary stack that comes with it(RMQ, libvirt). Our devs wanted an excuse to spend time with the libvirt APIs, and use RMQ in general.

Do you still think that choice was the right one?