"One of the keys to how all this worked was the PARC version of Catch-22, known as "Error-33". One committed Error-33 by putting any externally controlled system, in-house or out, on one's critical path. This included vendors. Error-33 was avoided by doing all that was necessary within a research group and then sharing. Thus, virtually all the PARC hardware — including two big time-sharing main frames, the Altos, Ethernet, Laserprinter, file storage, and the systems that followed — and software — including operating systems, programming languages and development systems, productivity tools, etc. — were completely built inhouse by these few dozen researchers.
This sounds disastrous, but there is an important collection of theories in which the 1st order version and the 2nd order version are completely different yet both are true. For example, in programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true—an incredible amount of time and energy has gone down these ratholes. On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible."
Open Source radically alters the equation; when I build a system on Open Source, even though I may not have built it, I do own it. I own it collectively, but still fully individually, in a way that really only works for software. As a home user I don't find myself fiddling with source often, but as a professional programmer building on an open source stack I do it all the time, and it is qualitatively different than working on a closed stack.
At PARC, I'm sure the cost of "fixing other people's stuff" was more than "building your own"; a few hundred million lines of code later, that balance has changed a bit.
"Unless I'm badly mistaken, in most processes today—and sadly in most important areas of technology research—the administrators seem to prefer to be completely in control of mediocre processes to being "out of control" with superproductive processes. They are trying to "avoid failure" rather than trying to "capture the heavens"."
I think postmodern programming is a combination of both Alan Kay's versions.
An example from my own experience: take Django code base, replace Django templates with Mako, replace Django ORM with an existing object database, add some nice features from other web frameworks, glue everything together, write tests and you have a new web framework, yet there's very little new code. Thus I 1. used existing tools; 2. built my own tool at the same time.
That's how I understand the term "postmodern programming".
"One of the keys to how all this worked was the PARC version of Catch-22, known as "Error-33". One committed Error-33 by putting any externally controlled system, in-house or out, on one's critical path. This included vendors. Error-33 was avoided by doing all that was necessary within a research group and then sharing. Thus, virtually all the PARC hardware — including two big time-sharing main frames, the Altos, Ethernet, Laserprinter, file storage, and the systems that followed — and software — including operating systems, programming languages and development systems, productivity tools, etc. — were completely built inhouse by these few dozen researchers.
This sounds disastrous, but there is an important collection of theories in which the 1st order version and the 2nd order version are completely different yet both are true. For example, in programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true—an incredible amount of time and energy has gone down these ratholes. On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible."
[1] http://www.vpri.org/pdf/m2004001_power.pdf