I've spent a ton of time thinking/working on this problem myself. I came to roughly the same conclusions about a year ago except for a few things: - Build syst

I've spent a ton of time thinking/working on this problem myself. I came to roughly the same conclusions about a year ago except for a few things: - Build system != CI. Both are in the set of task management. Centralized task management is in the set of decentralized tasks. Scheduling centralized tasks is easy, decentralized is very hard. Rather than equating one to the other, consider how a specific goal fits into a larger set relative to how tasks are run, where they run, what information they need, their byproducts, and what introspection your system needs into those tasks. It's quite different between builds and CI, especially when you need it decentralized. - On the market: What's the TAM of git? That's what we're talking about when it comes to revamping the way we build/test/release software. - There's a perverse incentive in CI today, which is that making your life easier costs CI platforms revenue. If you want to solve the business problem of CI, solve this one. - There are a number of NP Hard problems in the way of a perfect solution. Cache invalidation and max cut of a graph come to mind. - I don't know how you do any of this without a DAG. Yet, I don't know how you represent a DAG in a distributed system such that running tasks through it remain consistent and produce deterministic results. - Failure is the common case. Naive implementations of task runners assume too much success, and recovery from failure is crucial to making something that doesn't suck.