This is a very syncretic fusion between computing, dialectical materialism, entrepreneurial laissez-faire idealism and a bombastic techno-optimism.

Unsurprisingly, it harbors plenty of confusion.

"Towards a Mass Flourishing" makes the outrageous claim that the hacker ethos is best embodied in Silicon Valley. In reality, SV is one of the most detached from the MIT hacker ethos, instead having its own entrepreneurial hacker culture that is markedly distinct.

The "Purists versus Pragmatists" essay romanticizes the release of Mosaic and gives little credit at all to Ted Nelson's ideas, who is shoved aside as a purist crank. It's a false dichotomy through and through.

"Agility and Illegibility" again romanticizes widespread access to personal computers as some entrepreneurial Randian vision, that of Bill Gates specifically.

The "Rough Consensus and Maximal Interestingness" essay misquotes Knuth and incorrectly attaches philosophical meanings to technical terms like dynamic binding and lazy evaluation. It further espouses the "direction of maximal interestingness" and grand visions in the post-dot com bust era, when in fact systems software research is becoming increasingly conservative compared to as recent as the 90s.

"Running Code and Perpetual Beta" presents the dogmas of "release early, release often" and constant chaotic flux in software as a natural result of great ideas, as opposed to being the result of a cascade of attention-deficit teenagers. Note that fault tolerance, stability and security are not mentioned once.

"Software as Subversion" equivocates "forking" as being a Git terminology that somehow reclaimed its negative stigma, when it is purely a GitHub redefinition. The author makes no distinction between a clone and a fork. Also a misrepresentation of OS/2's mismanagement to argue in favor of "worse is better" (ignoring all other great systems besides OS/2) and babble about how blockchains are pixie dust.

"The Principle of Generative Pluralism" sets up the false dichotomies of hardware-centric/software-centric and car-centric/smartphone-centric. I suppose it somewhat reflects the end user application programmer's understanding of hardware.

"A Tale of Two Computers" prematurely sets up mainframes as obsolete compared to distributed networked computers (they are not exclusive) and makes the error of ascribing a low-level property to an ephemeral, unimportant abstraction - its marvel at the hashtag when the core idea of networking has enabled the same for much longer, and will continue to.

"The Immortality of Bits" is one of the worst, and makes this claim: "Surprisingly, as a consequence of software eating the technology industry itself, the specifics of the hardware are not important in this evolution. Outside of the most demanding applications, data, code, and networking are all largely hardware-agnostic today." This reeks of an ignorant programmer, oblivious as to how just how much hardware design decisions control them and shape their view. In fact, this is a very dangerous view to propagate. Our hardware is in desperate need of being upgraded to handle things like capability-based addressing, high-level assembly and thread-level over instruction-level parallelism. This stupid "hardware doesn't matter" thinking will delay it. The essay also wrongly thinks containerization is a form of hardware virtualization. It further says the "sharing economy" will usurp everything, which is ridiculous.

"Tinkering versus Goals" again sets up tinkering for the sake of it as leading to disruption and innovation, and not churn and CADT.

The "Free as in Beer, and as in Speech" essay clumsily and classically gets the chronology and values of open source and free software wrong. Moreover, the footnote demonstrates a profound bias for the "open source" ideal of pragmatism. This is in spite of the fact that many of the consequentialist technical arguments for OSS like the "many eyes make all bugs shallow" argument have proven to be flawed, whereas free software making no claims of technical superiority and using ethical arguments has a much stronger, if less popular case.

----

Overall, I do not recommend this.