There’s a weird phenomenon I’ve noticed again and again in tech companies. Tell me if this sounds familiar:

When a team needs a specific feature, the first reflex is to do a quick Google or GitHub search. They’ll grab some open source library, often maintained by people they’ve never heard of. Maybe it’s even a brand-new project with just a handful of stars. No problem! If it works, it gets the job done, quickly and for free.

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… but will it be maintained?” “Can we really trust that code?”

Somehow, grabbing random code from an unknown maintainer is fine, but grabbing code written by your colleague is treated as risky. Why? Let’s dig into the psychology behind this.

The psychology at play

1. Social proof beats personal proof

If a library has stars, downloads, or other companies using it, it feels “validated by the crowd.” That’s a safety net. If we use Alice’s library (Alice being our colleague), there’s no crowd. If something goes wrong, it feels like our decision alone, and that’s scary.

2. Blame avoidance

This one is very human: if a popular external library breaks, nobody gets blamed. “Hey, everyone was using it!” But if Alice’s library breaks, the person who pushed for it will get the blame. Better to be boring and safe than smart and exposed.

3. Conflict-of-interest reflex

Even if Alice isn’t trying to promote herself, the situation looks like self-promotion. That tiny perception of “self-interest” triggers extra skepticism. With strangers, there’s no such suspicion.

4. The “prophet without honor” effect

We know our colleagues too well. We’ve seen their messy commits, their coffee-fuelled late-night hacks.

Strangers online, on the other hand, get the halo effect of a clean README and a nice logo.

5. The vivid bus factor

Many external libraries are actually one-person projects. But that risk feels abstract. With Alice, it’s vivid and concrete: “If she leaves the company, we’re doomed.” Concrete risks feel bigger than abstract ones.

6. Process mismatch

Company processes usually distinguish between:

• external open source,
• and internal code.

A colleague’s open source sits in a gray zone between the two. Anything that doesn’t fit neatly into a process is automatically treated as suspicious.

Why it matters

This little psychological quirk has real consequences:

• Good code gets ignored. Employees may build useful libraries, but the company re-implements the same thing instead.
• Wasted energy. People prefer to adopt stranger code than trust someone they actually know.
• Morale hit. If you’re the maintainer, it feels like your work isn’t trusted.
• Security irony. Sometimes we reject a package whose maintainer sits three desks away, yet happily depend on a random stranger across the internet.

How to fix it

I don’t think there’s a silver bullet, but there are a few practical ways to reduce this weird bias:

• Apply the same criteria to all libraries. Judge both external and internal open source on things like tests, release cadence, docs, security policies… not on who wrote it.
• Move projects into neutral spaces. Put the repo in a GitHub org instead of a personal account. Add multiple maintainers. Write down a governance doc. This makes it feel less “personal.”
• Frame it the right way. When proposing it, don’t say “This is my project”. Say “This is an open source library with X features, and I happen to contribute to it.”

Final thoughts

The funny thing is: employees often maintain their projects because they love them, not because the company asked them to. That’s often a strong guarantee of long-term care.

So maybe the next time a colleague suggests a library they maintain, we should pause, notice our psychological reflexes, and give it the same fair evaluation we’d give any other open source. Who knows; it might just be the best option.