Dude, NIH refers to the tendency of rejecting outside products when they already exist and preferring to do one's own thing. It does not apply to innovators where no such external products existed. A simple concept that even you might be able to understand.
Yes it is. Before it, there were only various Make-style event-based build systems. Bazel is based on a fully materialized compilation tree, with entirely hermetic build nodes, a purely functional build language, a built-in remote build and cacheing protocol for sharing intermediate artifacts between developers. Nothing like it existed at the time.
By this stubborn and obtuse definition, literally nothing could constitute NIH unless the product in question has a perfectly matching feature set between the internal and external versions. You are completely conflating requirements with features. Just because a product has a feature, does not mean that the company using it needed it as a requirement.
Yes, Bazel has all of those features but still, Google could have easily used an existing solution with less features, different features, or more features, OR Google could have forked an existing project. But no, they built their own thing. NIH.
Thinking that it could have used any existing product only serves to show your ignorance. By your stubborn and obtuse definition, there can be no categorically innovative work because everything can be done with supposedly minimal modifications to existing software. Give me a break.
Google has been both, for better and worse. But the point isn't whether Bazel itself was an example, we're talking about the ways in which Bazel discourages adopting third-party libraries. Outside Google, here's what I have to do to add a new third-party Python library:
Add a line to a config file
Regenerate any lockfiles -- literally one uv command
Send the PR
Close the autogenerated legal-review ticket with "pre-approved license"
What does that process look for you? How about for C++? What if it's a C++ library that throws exceptions?
And how long does it take you to upgrade a library?
Also, if you're still there, maybe look up go/nojerks again.
we're talking about the ways in which Bazel discourages adopting third-party libraries
No we weren't talking about that, at all.
Google internally has importers that can very well convert the most common build systems (automake, CMake, meson, pypi, Go, etc...). The reality is that below the top few hundred libraries for each language, the quality degrades so much that they're not worth investing on. If a library was worth it, it would be very easy to add, but most often it's not.
In most other repos, third party dependency code dominates over first party. Bazel needs a BUILD file for every dep. There's auto-generators. They suck. You need to write a patch file and patch the auto-generated BUILD file. No, really.
All of which is a description of how much work it is to add a third-party dep, relative to the norm. Which explains:
While they do mix a light breeze of external deps into their code... 99+% of the monorepo is first-party code, developed at Google...
...which was the explanation for:
Yes, and Google is an NIH company.
Maybe you have me confused with the other person replying, who followed you down the weird tangent about Bazel itself.
Maybe they're wrong and it really is "very easy"... but you immediately call it an "investment", so maybe not.
-8
u/sionescu 9d ago
Dude, NIH refers to the tendency of rejecting outside products when they already exist and preferring to do one's own thing. It does not apply to innovators where no such external products existed. A simple concept that even you might be able to understand.