The article has some really good points.
To me reproducible builds is about setting an expectation for the degree of communication and quality of the software. A reproducible build means there must be a certain build process specified, it must be communicated in a useful way, the benefit vs cost must be considered.
That’s a bit of a soft answer, and those things can be achieved without reproducible builds. But an expectation of reproducible builds sort of ‘enforces’ a certain degree of this, whereas documentation alone or bash scripts alone can drift and decay with no clear indication of how much drift has actually happened.
I feel like the degrees of benefit are ignored (it’s not a binary yes benefit or no benefit). It’s better to be able to have ten separate individual builds which conform than a single one. Even if those ten could be colluding for malicious purposes or whatever, it seems like the degree of benefit is higher than an ad-hoc build.
I also feel like the case they present where ‘build it yourself means the external reproducible build becomes redundant’ is incorrect. Doing the build process yourself adds a data point of trust for the other people who have also done the build (and shared their results). A reproducible build encourages a group experience of the build process, whether doing the build or simply consuming the outputs as an end user. I feel there’s value in the social dynamic enabled by reproducible builds that can’t as easily be had with ad-hoc builds.
But, overall, I really appreciate the arguments put forward against reproducible builds. Thanks for the link.