From: monty@sprintmail.com

Subject: Second computer revolution -- Microsoft:Ford::Linux:GM?

Your essay on the Second Computer Revolution reminded me of the history of the automobile industry.

Before Henry Ford, there was a flock of tiny automobile companies, none of which dominated the industry -- to the extent the production of automobiles deserved the name "industry" at all. Automobiles were curiosities, priced out of reach of all but the wealthiest.

Henry Ford applied industrial engineering methods relentlessly, to drive costs down. He created the mass-production automobile industry, then dominated it for years. His style of management was centralizing and dictatorial -- not only did he not cultivate subordinates who could think and act independently, he systematically drove them away. He never asked his customers what they wanted -- he knew what they wanted, and by God that's what he was going to produce, and people would by God buy it when he produced it. And he was right -- for a while. For a long while.

But then Alfred P. Sloan took charge of General Motors -- a hodge-podge of mutually antagonistic formerly-independent auto manufacturers put together by his predecessors. Sloan invented the decentralized industrial corporation. (A student of American political history might be tempted to say that Sloan merely applied the original Federalist principles to industrial management.) And he invented (or maybe discovered?) the segmented automobile market and invented (no question here) the used-car market. And GM left Ford gasping in the dust.

And Henry Ford not only never understood what he had done wrong, he never even grasped that he had done anything wrong. The Ford Motor Company only survived because he died before he could quite completely destroy it.

Would Sloan have been able to make his contribution, had Ford not previously made his? No. But that doesn't somehow transform Sloan's contribution into a mere derivative of Ford's.

But I've been wondering who will play Alfred P. Sloan to Bill Gates' Henry Ford.

Dear Dr. Pournelle,

If you think about it, there are a lot of parallels between the early history of the automobile industry and the personal computer industry. When first introduced, both were curiosities used mostly by those with the time and money to indulge in a new hobby. Neither were cheap or reliable enough to replace what preceded them.

Eventually a product came out that was cheap and reliable enough to appeal to large numbers of consumers (Model T for cars, IBM PC w/ DOS for computers), though many people still used older technology. Both the Model T and PC were good enough to satisfy most people unfamiliar with such technology. While the novelty lasted, the industry powers (Ford and IBM / Microsoft) were pretty much able to control the market and keep competitors small.

The infrastructure improved to the point that demand for both products became almost universal (Interstate Highways for cars, the Internet for PCs). Consumers, now more familiar with the products, became more technologically sophisticated. No longer was the finicky performance of the early autos (or PCs) acceptable. Without the novelty factor, fewer people were willing to tolerate the problems that plagued early autos and PCs. Consumers now demanded lower costs and greater reliability.

Failure to realize this market shift nearly killed the U.S. auto industry, as the Japanese (long disregarded as an insignificant niche market industry) capitalized on the opportunity.

Will the same fate befall Microsoft (it seems to have already happened to IBM)?

If so, who will be the Japanese of the computer industry? Apple, Linux, or will it be some company or system not yet widely known?

What is certain is that if Microsoft doesn’t change its focus to creating a stable and reliable system, at a low price, someone else will.

Linux isn’t there yet (and may never be) though it may form the basis for such a system. Mac could have been there (and could still be) if not for Apple’s management.

Like you, I’ve devoted countless hours to tweaking and debugging my systems, yet still suffer occasional crashes. After suffering through CP/M, DOS, Windows 1,2,3.0,3.1, and the various versions of 95, occasional crashes and reboots actually seem acceptable. But would we keep a car that broke down every fifty or sixty miles, or needed a complete overhaul every three or four thousand miles?

NT may be more stable (as the Model A was more reliable than the model T), but consumers today expect, at least, the reliability of the Toyota Corolla.

Chuck Fenton [cfenton@rc.net]

Dear Mr. Pournelle,

I have followed your columns and read your books for 20 years. I just went to your website to catch up on your recent activities. I was very happy to hear you have landed on your feet, after the Byte fiasco. I will miss the old Byte, your column, etc.

My real purpose for writing you regards your work in progress: "The Second Computer Revolution". I have worked in the computer industry for 24+ years. I have observed many of the so-called new technologies, or innovations, are just old ideas re-wrapped in post first revolution glitz. I believe, as you have stated, that the biggest achievement is the cost of ownership. These old ideas, can now be distributed to the masses in a fashion that makes them ubiquitous.

As for my ideas on "The Second Computer Revolution" (TSCR, pronounced tiscar):

I believe TSCR will be known as the revolution of the software mechanics (redeemed hackers). The first revolution brought computers to the masses. Demographically, there are masses of young people that have never known life without one. Some of these young people (and older folks like me) are not content with first revolution mediocrity and problems. Sure we like the features the first revolution has put on our hands, just like owning a car. However, some of us want to soup it up. We are not content to the boundaries placed by off-the-shelf applications. We want the source code; all the source code.

In the late ‘70s I worked with a very innovative operating system on a mini-computer. I had the source code to the operating system, which was nearly all FORTRAN. If I needed to enhance the system to achieve some purpose, I did.

In 24 years of software development, the single biggest impediment to long term success/cost of maintenance, in a project, was depending on a third party utility for which we did not have the source code. To depend on a third party, is to tie your success to the success of something you may have little or no control over. If the third party is small, your risk is greater, unless you can out right buy them lock stock and barrel. If you have the source code, the third party can go in the tank and you have what you need to survive.

The young generation of technophiles will be less and less enamored with the latest thing Bill and the folks in Redmond have to offer. Linux, JAVA, and the like, offer ways to soup things up and break the ties to third party mediocrity. Sure, Linux is like working on Japanese motorcycle in the ‘60s with a badly translated shop manual, but I am the one working on it. I can tinker with it. I can break it. I can learn about it by working with it. It is no longer a black box. It is a box that I can change the contents of to suite my purpose. It the box breaks when I use it for something it wasn’t designed to do, I can change or fix it.

So I believe TSCR will be the demand for, and use of the source code by the software mechanics; the source code to everything. I don’t think it will happen real fast, but I believe that operating systems like Linux and the GNU philosophy contribute to TSCR.

I could rant longer, but I have a cold and have run out of gas.

Keep up the fine work. I buy your stuff.

I am given a month off every five years in addition to vacation as a sabbatical. I plan on writing some historical fiction. I got to get it out of me. I appreciate what you have written about writing. Thank you.

I teach data structures and intermediate C++ programming, the middle course in our core CS curriculum at George Mason University. The previous course covers mostly the C core of C++, and the following course finishes data structures and covers the advanced topics in C++ programming. This course sequence emphasizes programming projects in standard-compliant C++, and at its conclusion, the students are ready to be entry-level programmers.

I teach my class wearing the persona of a curmudgeonly old software engineer who demands his students learn how to build programs that people’s lives can be trusted to. I also talk a lot about the old hacker ethic. It’s just a style, but a lot of the students seem to enjoy it.

My course is no more difficult (and is in many ways easier) than old-fashioned high-school Latin-II.

How do I know? I get advanced placement students from time to time, and they seem to have learned the material already (and better), the difference being that the high-school instructor covers the material in 180 hours over a year rather than in 52 hours over a semester. Learning to program does take a lot more time than that—the homework and readings in the text for my class take about 20 hours a week. The difference between the high-school and the college course is that the high-school teacher supervises a lot of what I simply expect the students to do on their own.

That suggests that computer programming is something like repairing cars—the high-schools could easily produce plenty of qualified entry-level programmers.

You don’t need to go to college to become a competent programmer.

What will it mean when everyone learns to program in high-school? In World War II, the US Army was motorized—because most Americans knew how to keep a car running. If the high-schools take on the teaching of programming, most Americans will know how to keep a computer running and the collaborative groups you’ll be able to organize to solve hard problems will be enormous. It’ll be a major step towards Vernor Vinge’s asymptope. We have no clue what that will be like.

The Second Computer Revolution and the automotive analogy

About all I can agree fully with is "It’ll be a major step towards Vernor Vinge’s asymptope. We have no clue what that will be like."

In the early days of the automobile it was certainly true the proverbial Yankee ingenuity worked. Obligatory footnote/example - the family keeping the car running (without going to college) in The Grapes of Wrath.

Today it is certainly true the proverbial Yankee ingenuity does not work. Obligatory footnote/example - a recent Road and Track word from the Editor where the staff who as a group had all the education and experience possible stood in a group around a car dead in the editor's driveway and had no idea where to start to do something useful. Solution-tow it to a specialist.

If I recall correctly Dr. Pournelle essentially desktop published one of the Sparta books so as to work closer to deadline. Seems to me this was worthwhile because the desktop publishing was quick enough to free up time to actually write.

There exists a truly full featured desktop publishing program with open source code. It is called Interleaf. I wager almost nobody who has a choice uses it. I'll wager too that if Interleaf had been the only desktop publishing tool available to Dr. Pournelle the book would still be in process. [aside - do the aerospace and automotive companies who have adopted CATIA have source code access today?]

For these very web pages Dr. Pournelle did not start with a requirements list but with the market leading commercial software.

The user groups who sprang up around the HP41 and TI58/59 were communities who followed open software rules. The same people may be active in similar roles today but those communities have vanished.

I suggest that despite Internet years the first computer revolution is still in progress. An analogy more useful than the Industrial Revolution may be the French Revolution with Bill Gates as Napoleon. Microsoft may be brought down but the increase in centralized power will endure. See for instance Repetitive Stress Injuries and Big Brother in the workplace (your call may be monitored, your e-mail read, your browsing recorded, your keystrokes counted). Big iron did not impact me in the workplace nearly so much nor so adversely.

In my experience companies where the marginal cost to do custom coding is small [because they have computer junkies on staff looking to impress people] find the coding is a negligible part of the total cost of ownership. Where possible commercial software is deployed and many custom projects are superseded at the earliest possible moment by common off the shelf software (cf. COTS and POTS). Of course my experience is high tech low profit companies.

Jerry,

I read the message by Mr. Tiomoid of Angle and I think that he’s missing the point. Open-source software is neither collectivism or socialism. Economic labels which derive from the trading of atoms, are, in my opinion, inapplicable to the trading of bits.

Open-source software development most closely resembles the scientific community, rather than any commercial enterprise. Scientists are not generally allowed to "own" the theories that they originate. Other scientists are perfectly free to modify those theories and republish them. They are not, however, allowed to claim credit for something they did not originate.

Does this mean that scientific production is "sparse"? Does it mean that the rest of us non-scientists are "parasites" because we reap the benefit of scientific research without contributing to those theories ourselves? I suppose you could in fact answer "yes" to both of those questions if you wanted to be really cynical and dogmatic.

This gives me a great idea for a paper: "Socialism with an academic face." :-)

The fact is, however, that science simply cannot work any other way. The open and unrestricted sharing of scientific information is the only means by which science can move forward. I don’t think that there are many scientists in the world who would prefer a model whereby scientific theories were treated as trade secrets. Like open-source software development, science absolutely depends on widespread criticism.

Your point about non-material rewards is well made. Too many economic theories, in my opinion, assume that we are all perfectly rational and perfectly greedy; Which is to say that as individuals, we spend all of our time working for our own best interests, (where "best interests" is define in some simplistic economic terms.) However, we also have animal instincts, simian behaviors, and other behavioral loopholes. As a game designer, I’ve spent my entire career exploiting these non-rational behaviors. One of my aphorisms, "Humans are compassionate predators", represents my deep feeling about the complex mix of human psychological make-up, the strange combination of the lizard brain’s "I must eat the world" impulse to the warm-fuzzy monkey-brain’s desire to hug and snuggle and rub various body parts together (like the handshake, for example.) Any statement of economics which does not take these behaviors into account is incomplete.

I personally am very excited about the concept of giving my work away, because of all of the benefits I will receive from doing so. First, the respect of my peers. Secondly, assistance in creating my magnum opus, which I would create even if no-one paid me to do it. Thirdly, notoriety which could potentially help me economically. As far as business models go, I would rather be a _guide_ than a _gatekeeper_, i.e. I have this beautiful forest, and I don’t want to put houses on it, so I can either build a fence around it and charge people to get in, or I can hire myself out as a tour guide and show people all of the best places, guiding them to just the right spot for their unique needs. The latter job is a lot more interesting, in my opinion.

I’ve been following your TSCR thread, with some interest. I’ve been actively involved, and making a living in the computer industry since 1958 (my God! That’s 40 years! Sigh!). I started out as a system programmer for several years. I then moved on to solving business problems, so I became an applications programmer for several more years. I then went into a series of specialized activities – wide-area, then local-are network design, technical support, engineered computing infrastructure work – and finally reach my career climax, to date, - I’m a full-time consultant. :<))

Why all this horn-blowing? Well, it’s only there to establish that I have some reasonable experience basis for my views.

Now, on to TSCR!

Open Source Software development has a long and glorious history in the industry. A tremendous amount of innovative development work has been done first in university environments. These environments, while politicized as all get out, are the most nearly meritocracies that I’ve seen, anywhere. Peer praise and peer review are the very stuff of life (and death) in academia. I remember the enormous network of people who participated in developing Project Athena at MIT. Some of it was funded, other pieces were done because the authors wished to do them. The vast body of work of the various global standards bodies reflects the same sort of drive. Many participants are company employees, but many are not.

The central point of all that work is that these hundreds of collaborators have produced large numbers of very good things! Many of those things simply could not have come into existence without unfettered collaboration across and through all types of barriers. There are many folks that spend endless hours editing and reviewing standards proposals and white papers because they enjoy it – they’re often completely unpaid and they thrive on the awareness of their contributions within their small communities of interest.

For those classes of intellectual product that can be produced within loosely tied (usually by public standards and published APIs, and motivated by horizontal rather than vertical organizational pressures) structures, the collaborative method probably has no equal, let alone superior. However, one of the areas where this method frequently breaks down is if the many independently developed components must be integrated and then proven to work to some explicit level of performance.

Complex integration generally requires significant capital investment to create a test bed. It requires substantial amounts of fairly scarce talent and skills to engineer (in the loosest sense) acceptable solutions. It requires that participants be willing to be held to the agreed types and levels of compliance and completeness. It requires that people be both willing and able to deliver whatever additional efforts are required, and when they are required, by the integration team. That kind of time-invariant effort cannot usually be obtained by collaboration, alone. There needs to be a structure, one with organizational goals and rewards, adequate funding to purchase what it needs, and a charter that makes the delivery of the resulting solution critical to its mission. Obvious examples include NASA in the ‘60s, the peace Core in the ‘60s, and nearly any business enterprise that has been around long enough to be deemed successful by its investors.

I find myself much more willing to bet the success of my enterprise, and my clients’ enterprises, on solutions that have been engineered by profit-motivated people. Solutions built by other enterprises that have both the will and the resources to stand behind what they produce and to risk losing it. I also much prefer to engineer solutions based on source code that is stable, and is widely supported.

Red Hat, and others in the field of ‘thin vendor’ offerings, cannot provide their customers with anything like the sort of support IBM, Microsoft, and other large enterprises can deliver. UNIX became a significant member of the mission-critical platform group only when IBM, Hewlett-Packard, Digital Equipment, and others integrated UNIX into their supported platforms. Prior to that time, UNIX was much more a university phenomenon than a business tool. How does this bear on OSS? How can an organization provide the breadth and depth of technical support needed to meet mission-critical requirements if they do not have control of the source code? Linux is released in a very carefully controlled and well-managed fashion. However, its very volatility (a feature of the OSS method that I heartily appreciate, from a research perspective) nearly prohibits any organization from making the necessary investment in skills and knowledge to provide detailed, continuous, and comprehensive support for it. This applies as much to the IBMs of the world as it does to any enterprise of less than global scale. (Obvious exceptions are the globally scaled work of the U.S. Department of Defense, which supports lots of mission-critical software that doesn’t scale worth a damn, but is necessary given available technologies and solutions at any given time.)

If an enterprise has to develop very deep skills to support the very infrastructure on which a solution is based, components of the operating system in the Linux case, then only fairly specialized enterprises can seriously consider employing those solutions. This could prove to be a ‘great limiter’ for someone like Red Hat and for the overall Linux effort.

The Linux effort is extremely valuable to the industry, since it will provide a somewhat compensated method to encourage rapid development and integration of components to a highly engineered operating system platform. For Thorvald, Linux is obviously a labor of love. It produces a platform that makes UNIX something people with almost no resources can deploy to learn, to understand, and to use for experimental development. A very laudable goal, and a wonderful achievement.

I still would rather have the resources of a major software vendor behind the platforms I recommend for deployment of solutions critical to my, or my clients’ missions.