Hacker News Reader

Comment by module0000 | Hacker News Reader

I've worked for 2(out of many) employers that allowed me to spend significant time committing our improvements and modifications upstream to open source projects we used in-house. This was very enjoyable, and I wish more employers behaved that way.

One of the enjoyable aspects of this practice, was during the selection process for "what software do we want to use?". I didn't have to select only open source projects which were "almost a perfect fit, with XYZ problems we can live with". Instead, I got to select software with (to me) better criteria:

* what are the upstream devs like to work with?

* what is the future of this project?

* is this project something we would be proud of our association with?

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

View on HN

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.

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?

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.

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

Reply on news.ycombinator.com