> It's just really kind of ridiculous that the same basic problem gets re-implemented literally thousands and thousands of times across different platforms and use cases
Why not? It's incredibly easy and quick to implement one, why not just make one perfectly fit for your use case every time?
The actual issue here is people insisting on offshoring that implementation to GitHub, so that they deal with a brittle, badly defined interface that is not aligned with their needs, instead of just starting with a simple engine and reimplementing whatever they need. It's actually the opposite problem that standards were meant to solve.
You THINK it's easy. A nice clean set of boxes in a line with arrows.
... until you get branching. Exceptions/error branching. Subflows.
Suddenly, you have a fully turing complete engine. The modern compromise is a DAG that hopefully guides a workflow to completion a la the halting problem.
Anyway, there are a ton of piss poor ones with too many bespoke interfaces.
You mean companies that failed because they implemented their own build and deploy scripts? Their own CI/CD workflow engine? Or for trying to sell a workflow engine?
Because I can imagine why almost nobody could be able to do the third one.
Why not? It's incredibly easy and quick to implement one, why not just make one perfectly fit for your use case every time?
The actual issue here is people insisting on offshoring that implementation to GitHub, so that they deal with a brittle, badly defined interface that is not aligned with their needs, instead of just starting with a simple engine and reimplementing whatever they need. It's actually the opposite problem that standards were meant to solve.