Hacker News Reader

Comment by raesene9 | Hacker News Reader

My favourite comparison for all the 3rd party library use is, if you walked in to the CEO of your company and said

"we want to hire some people with no background checks, no interviews and no idea where they live to write code for our critical line of business application. We're then going to put that code into production without reviewing it, and regularly update it without reviewing the updates. Oh also we won't have any form of enforcable contract as come-back if something goes wrong."

You'd, at best, be laughed out of the room.

Yet that's exactly what pretty much every company does with 3rd party libs.

View on HN

On the contrary, you'd be asked what the cost benefit analysis was vs doing it in house, then told to continue.

CEOs outsource critical things without meaningful oversight all the time.

The point I was flagging up was the dissonance of corporate hiring policies relative to their use of third party code.

For hiring, no chance you'd get that policy past corporate HR in any large company. Try hiring a developer sight unseen to work remotely with no contract in any large organization and see how well that goes.

Yet companies effectively do just that with 3rd party library use. the reason the CEO doesn't do anything isn't likely to be because they've made an informed risk decision on the topic, it's because no-one is telling them the risks :)

I work for a 10,000+ person public company that just outsourced critical business functions via a 5 year contract that doesn't have any meaningfully enforceable description of the work to be done.

If you're trying to talk about hiring for full time employment as opposed to contract work... what happens there is as long as people are able to get through whatever idiosyncratic hazing process was involved in hiring, they're going to be at the company for at least a year. It's perceived as hard / risky to fire people, even if they can't program their way out of a wet paper bag.

This stuff happens all the time, it's not that different from evaluation and use of third party code. "This project has 500 stars on github, it must be good." "This guy used to work for Google, he must be good." Now you're stuck.

In the first case you still have a contract, and therefore contact law in your country applies. Blatent breach like "they wrote code that stole all our SSH private keys and then they deployed cryptocoin mining software to our systems" would be covered, regardless of how bad the contract is.

Same with hiring, the person may or may not be able to code, but active malice would likely result in firing, and the code they write should be subject to review before being put into production.

Of course you can argue "hey where I work hiring is trash, we write bad contracts and have no internal standards, so this 3rd party stuff isn't much worse" but I'd suggest that's not an argument most companies would make publicly about their processes.

Whether they'd make the argument publicly or not, it's still true that it is the reality, and the company I currently work for is better than a lot I've seen.

Point taken about active malice... but I've also seen companies with mostly in-house code cover up instances of rootkits on production servers and malfeasance related to credit cards.

I'd rather companies use third party open source crypto, for instance, even if it sometimes gets compromised, because it's a lot more likely to come to light.

Reply on news.ycombinator.com