Why Declarative Build Systems Aren’t Popular

Declarative build systems like Bazel (open-source of Google’s Blaze), Buck2/Buck (from Meta), and Pants v2/v1 (from Twitter) are all ideologically similar. 

Define software builds declaratively via BUILD files written in some configuration language (buck2 and Bazel use a Python subset called Starlark, and Pants v2 uses pure Python3 async coroutines). Then the graph is used to build the DAG. You get incremental builds and caching through content-addressable storage. This also means you can offload to a remote build server. This means fast, reproducible, and “correct” builds (many dependency bugs are eliminated with the declarative approach). 

But these open-source systems aren’t widespread out of the biggest tech companies. Why? My experience working on a few Bazel adjacent projects at Google (Kubernetes used Bazel for a bit, TensorFlow still uses Bazel, and I built a reproducible package manager for distroless containers).

Not built for open source. These build systems need to know all of their dependencies before starting a build. This is easy at Google, Meta, or Twitter — all third-party dependencies must be copied into the company’s repository, checked for licenses and security vulnerabilities, and vetted. Most development, in open-source and at smaller companies, relies more on other people’s code than their own. Those projects solve for shareability and code reuse, not reproducibility and correctness. 

Closely coupled with monorepo architecture. Declarative build systems require unilateral buy-in across projects. It’s hard to ship truly platform-agnostic tools — it’s mostly optimized for their parent company’s monorepo, development environment, and production environment. Most developers deal with distributed repositories across GitHub and external package managers. It’s often hard for them to collect or even understand their full dependency tree before building.

Not helpful or detrimental for small projects. It’s the equivalent of Kubernetes — valuable ideas for large deployments but significant maintenance for even the most experienced development teams. While you get many speed benefits from adding a build system like this, it comes at the cost of developer velocity and maintenance. Developers must learn and maintain the system and port third-party software to it.