Why we trust strangers’ open source more than our colleagues’
33 points by cry-inc
33 points by cry-inc
But here’s the paradox: If the exact same feature is available in an open source project maintained by an employee, suddenly people get suspicious.
Wait, what? Who does this?
I already had something similar happening to me. I had a fun little project over a weekend, spoke about it at work and people found it great and wanted to use it. Later it was questioned like « but there are open source versions on GitHub with many more stars! » so we switched to one of those… I felt a bit weird but got over it.
I'm glad no one has ever told me they made a decision based on github stars because I doubt I'd be able to stop myself from laughing in their face.
I think there are two ways to approach this.. one: familiarity breeds contempt. When the code comes from some distal person or group, it's the acceptance of a gift and you may never interact with the people or community. On the other hand, when the thing has a face internally envy and jealousy would be two obvious human emotions where others that should have aligned incentives don't row in the same direction.
The other is not quite what the article is about but the Joy adage "No matter who you are, most of the smartest people work for someone else" is a funny statement that is profound. Even if you are the dominant tech company in a time, the majority of the best people work elsewhere. Therefore, some project that warrants technology fellowship across companies is probably superior to something that is simply corporate sponsored open source. Once in a while, you get a Linus Torvalds working at Transmeta type of situation but most FOSS is either composed of a larger governance body (foundations), or maybe just not that important in the overall situation.
Objectively your colleague's OSS code is less trustworthy because of the draconian terms of the IP license agreement they signed when they joined the company.
In the scenario you describe the employee does all the OSS work, but they won't actually be the owner of the code or the project: company almost certainly legally owns both under common labor law like Calofornia's the moment the lines get blurred between work and personal.
So now you're using a project whose legal owner doesn't really know or care about preserving it. The grounds are set for nastiness, and all you can really do to protect against this madness is make sure that you won't end up in a fight with your own employer
Wow. That’s a lot of armchair psychologizing. Sure, judge internal and external projects by the same criteria, but make sure to include all the criteria, e.g.:
If the above averages out to be more true for the OSS project than the internal one, you bet I’m going to advocate for the OSS. Otherwise it’s just NIH syndrome, which is usually a big waste of time. The more reinvented wheels an org depends on, the less time senior devs have to work on problems that are critical to the org’s mission, the longer it takes to onboard new devs, and the harder it is to retain them because their time is being wasted on stuff that will have no relevance in their next job. The only exception I’d make is for software that’s critical to the mission of the org, because that is exactly where everyone’s heads should be, and if there’s an OSS project that’s better, then the org should either get behind it or dedicate the resources to make their internal project the better one.