February 25, 2015: Google open-sourced Bazel (née Blaze) and sucked all of the oxygen out of the room.
Before Release: 2004–2015
Blaze had been in use inside of Google for years, with early iterations starting in 2004. The first public presentation about Blaze happened in 2010, at an event that happened before gtac2010, Google Test Automation Conference. It didn’t even make the main event. A video of the presentation was posted in early 2011. At authoring time of this blog post, it has only been viewed 20,321 times. That was followed up with a series of blog posts about Blaze in 2011.
Amusingly, the Blaze clones beat Bazel to the market. People who left Google and pined after Blaze rebuilt it at Twitter (Pants) and Facebook (Buck). However, even with a multiple year head start, they didn’t gain enough traction to prevent Bazel from taking the throne.
The market for tools of this power and complexity didn’t exist yet.
Release: 2015
Bazel launched to mixed reviews, with Blaze users being the most-excited.
Gradle, the most-compelling alternative not of Blaze lineage responded to the release with a blog post. Since Bazel’s release Gradle has evolved to be more-similar to Bazel and that blog post has been taken down. Gradle’s commercial instrumentation offering now supports Bazel in addition to Gradle.
At launch there wasn’t a ton of fanfare because most companies and software at that time did not require something like Bazel, and, if you needed it, you built it custom. Microsoft contemporaneously built a tool called BuildXL (Microsoft Build Accelerator) which they started on before Bazel was released but only released publicly many years later in 2018. You’d be forgiven for never hearing of it.
After Release: 2015–Present
Even after release, Bazel wasn’t done influencing the build world. A year later in 2016 Please was released which was “heavily inspired by Blaze/Bazel and Buck and follows a lot of similar concepts.” The primary observation of Please is that the user interface and authoring experience for Bazel is complicated, and could be better.
Both Pants and Buck did a full rewrite after Bazel’s release, and they now hew even closer to Bazel. They’re distinct in the details, but feel very similar if you squint. Buck2 even supports Bazel’s Starlark.
Twitter stopped using Pants and adopted Bazel. Microsoft published BuildXL. Toolchain Labs set up shop in late 2018 to support Pants, and shut down without ceremony in 2023. Most every other modern tool which is not of Blaze lineage is either single-language focused, or never reached critical mass. Lots of academic build tools started showing up with compelling incrementalism patterns, and research into build systems kicked into overdrive.
Build System Formalization
In September 2018, Andrey Mokhov, Neil Mitchell, and Simon Peyton Jones worked to bring some formality to build system definitions with their paper, Build Systems à la Carte. They attempted to reduce the set of options in the build system space with a rubric that they believe constrains the core set of options for build systems.
| Rebuilding strategy | Scheduling algorithm | ||
| Topological | Restarting | Suspending | |
| Dirty bit | Make | Excel | |
| Verifying traces | Ninja | Shake | |
| Constructive traces | CloudBuild | Bazel | |
| Deep constructive traces | Buck | Nix | |
This formalization has held up well since being released, though further published papers including Neil Mitchell as an author indicate (somewhat unsurprisingly) that Applicative build systems can be built in a way such that they may electively choose their scheduling behavior. These refinements have made it into Buck2, which, as the most-recent rewrite, has the privilege of having the most-polished system architecture. But it basically doesn’t matter.
Back to Banging Rocks Together: 2018–Present
On October 16, 2018 the state of the art got stuck in a local maxima: GitHub released GitHub Actions along with their YAML-formatted specification. It’s effectively a graph of imperative build scripts. The underlying approach for using it as a build and CI tool reduces to make clean && make. And, it turns out, that works just fine for a surprisingly large percentage of users.
Sometimes GitHub Actions users hit problems that cause them to discover true build systems, but even then they don’t typically migrate. People tend to remain on poorly-working—but working!—solutions far longer than they should. They only know the word “Bazel” which is synonymous with “complicated” in their minds.
Can We Get Unstuck?
Notably, the companies that have obviously made money in this space are:
- GitHub, possibly, with GitHub Actions as an addon product outside of their core competency of repository hosting. They have leveraged the OSS ecosystem centralizing onto GitHub into a GitHub Actions upsell which is extremely easy to adopt and helps to create a moat around their services.
- Gradle, a surprising stalwart, who primarily sells introspection tools for build tools. They maintain Gradle itself effectively for lead development and generation. Their continued existence at this point may be attributable to Android’s market success.
- Build farms and external CI providers who can only make margins on top of their hardware and engineer salaries. These companies are trapped in a race to the bottom with mostly-undifferentiated products.
We can see that, thus far, companies authoring a build system do not make money from the build tools themselves but instead from value-added services. This raises the difficulty of entering the market as the approach for monetization is tangential to the necessary core competency of creating a build system. We can see the same thing in the JavaScript framework ecosystem where a company like Vercel invests heavily in framework development but gives it away and instead sells additional non-core services to their users.
Complicating that, the existence of multiple projects (Bazel, Buck, Gradle, Pants) with hundreds of engineering years invested available to end-users for free has changed the market. Users unaccustomed to paying for their tools won’t choose to switch to a paid tool—even if it is better suited. This is a rational decision! Costs to switch to Bazel are typically overestimated, the return on investment for doing so is worthwhile for build stability, the long-term cost of ownership reduced to undifferentiated remote execution providers in a race to the bottom, all with readily available support from consultants.
A Future New Build Tool?
From a survey of the ecosystem and history we can see that a future new generic build tool must:
- Be accessible to users of GitHub Actions
- Deliver one or more extremely compelling differentiating features
- Develop a monetization strategy–which is probably not contingent upon direct licensing
- Rabidly defend any space that they successfully create in the market from encroachment by agile incumbents who have more resources
- Provide functionality on par with Buck2/Bazel
- Have lower operational costs and complexity than Buck2/Bazel
- Overcome or sidestep the ecosystem effects of Buck2/Bazel
Failing any of those means that the fallback is sponsorware—amusingly, the same model as Bazel and Buck. Finding sponsors willing and able to fund multiple developers (either by hiring them to work on the tool or via donation aggregation) is in itself the same kind of work as turning it into a company; a VC model is just a different sponsor. But there isn’t an obvious acquisition exit as the largest companies generally already have their own horse in this race. That likely means it must be profitable enough on its own to justify investment, and taking anything more than Series A funding would set a possibly-insurmountable financial target.
There is probably one slot left in the tool complexity/power hierarchy. Threading that needle could be lucrative, but it’s going to be difficult. And it is already a crowded space.