Dan Weinreb’s blog

I have ordered a Quanta XO-1 (One Laptop Per Child) on the Give One, Get One deal, where you pay $400 plus shipping and you get an XO and donate one to the project ($200 tax deduction). This is just so cool that I have to have one. And I need a lightweight box that can do email and browsing that I can carry around easily. There are other good options but the XO is so novel and interesting! It’s just 3+ lb and runs on 2-3 watts with an amazing lithium ferro-phosphate battery, and physically extremely durable, waterproof, and dirtproof, and a great (but small, 7.5 inch) screen. No disk nor CD/DVD, but you can add them externally. And if the OLPC project is a big success, this may be the platform of the next generation of hackers. They are aiming to bring the price down to $100.

http://wiki.laptop.org/go/Hardware_specification

After watching a talk given at Google by Ivan Krstic, I got more and more excited hearing about the hardware and the software. A lot (14, apparently) of hackers, at least some of whom are famous superhackers (e.g. Jim Gettys), were involved in putting together the software. They have thought of and taken care of a huge number of issues. Perhaps I’ll end up contributing open source code to the project someday, although at the moment I’m too busy for that to be feasible.

The Give One Get One deal is only available for another 7 days. It may be hard to get them after that since they are going to be sold only to schools and other educational institutions and governments and in the third world. So if you want one, don’t hesitate:

http://www.laptopgiving.org/en/index.php www.xogiving.org

The only thing I’m worried about is that David Pogue in the New York Times says that the XO’s keyboard is too small for an adult to touchtype on. I asked around, and Luke Gorrie (of SLIME fame) says that it’s frustrating at first but then he learned to touchtype on it at high speed. (I was going to walk over to the Media Lab and try one but I have no time in the next seven days and I’m just too convinced now.) And so many people seem to get along fine on much smaller keyboards, such as those on the Blackberry or smart phones (not touchtyping, obviously, but good enough for email when I’m on the road). So I’ll chance it. Other drawbacks: 2 minutes to boot (hey, Lisp machines booted slowly), and switching between apps is “poky”. (But the apps are fast.)

In a previous post, I mentioned capability architectures. The XO’s “Bitfrost” is not a capability system, but it does deal with the issue of mutually-suspicious protection domains. Given how many XO-1’s there will be, if the project succeeds, it will be an obvious target for malware, and I think Bitfrost will be a big help there. Bitfrost works by dividing up protection domains at a coarse level, whereas I’m more interested in very-fine-level schemes. See:

http://en.wikipedia.org/wiki/Bitfrost

Great technical info in the video of the talk at Google by Ivan Krstic, who is the architect of Bitfrost but talks about all aspects of the system:

http://video.google.com/videoplay?docid=-4285568518538296189

General info:

http://en.wikipedia.org/wiki/OLPC_XO-1

Main web site, but it seems to be down at the moment:

laptop.org

David Pogue’s review in The New York Times, both written and video. Pogue does lots of product reviews and I have a lot of confidence in his evaluations (and I love his books).

http://www.nytimes.com/2007/10/04/technology/circuits/04pogue.html?_r=1&oref=slogin
http://video.on.nytimes.com/?fr_story=6ffd976ed367bacae4171dd4999d36431c84b0f5

There’s plenty more if you Google for “OLPC”.

The XO does everything in Python. You can see all the code, with a single keystroke (that shows the code of what’s running) and even modify the code. In the video, the speaker (Ivan Krstic’) is asked “Why not just use Lisp or Smalltalk?”, and the questioner cites Lisp machines! See, our influence is still there! He replies that doing everything in Python “comes close to the general Lisp machine idea” (of course he, too, knows what a Lisp machine is!). Answer: he protests that it’s a lot like a Lisp machine except that the language doesn’t go all the way down to the metal (it’s based on Linux). Hey are also shipping Squeak (a modern Smalltalk). They used Python because of the “size and momentum” of the community, and because he feels that Lisp has a steeper learning curve than Python does for kids. I won’t object to those reasons.

Hey, Python, Lisp, what’s the difference? So, strange as it is to say, maybe this is the new Lisp machine!

There’s an interesting article in InformationWeek, entitled “Microsoft’s Bill Hilf Reveals Its Open Source Strategy”, interviewing Bill Hilf of Microsoft. He’s described as Microsoft’s “leading light on open source”. It’s mostly about Linux.

http://www.informationweek.com/news/showArticle.jhtml?articleID=203100965

They say he’s involved with Microsoft’s strategy for “dealing with” Linux. That reminds me of John F. Kennedy telling the CIA that they should “deal with” Fidel Castro. And it reminds me of the way Microsoft decided to “deal with” Netscape, when they were competing with its browser — Microsoft’s strategy was to “suck the oxygen out of Netscape”. But that’s just free association on my part! More seriously:

Hilf says “When people buy commercial software, really what they’re buying is a guarantee. You’re buying a guarantee that what you have will perform, and has been tested and there’s someone you can call up, and if things go really bad someone’s liable if something doesn’t work.” Is that so? Look at the end-user license agreement for Windows Server, for example: “LIMITATION ON AND EXCLUSION OF DAMAGES. You can recover from Microsoft and its suppliers only direct damages up to the amount you paid for the software. You cannot recover any other damages, including consequential, lost profits, special, indirect or incidental damages.”

What does a “guarantee” mean? Surely it does not mean “certainty”: plenty of commercial software sometimes performs poorly or has bugs. Does it just mean “there’s someone you can call up?” But that’s true with actively-maintained open source software, too.

Prof. Gerry Sussman of MIT, for whom I have tremendous respect, once tasked me with putting together a plan for a company that would provide open source software that really did come with a legal guarantee. The idea is that the software would be quality-assured really, really well. The goal was to help reassure potential users of open source (or free) software. I wasn’t able to figure out how to make this work, and I’m not sure it would solve the problem it’s intended to solve, but maybe someone else co8uld do better than I could.

The real question is whether the particular open source software in question has higher quality/performance, and whether you get better response time for bugs, than some particular commercial alternative. I don’t think there’s any way to generalize for all open source software. A relatively small number of open source products have a lot of diligent maintainers, and even Q/A people, sometimes paid full-timers; a larger number are written by one person and often abandoned. There’s everything in between. Linux is the most extreme example I know of a very powerful open-source community.

Hilf goes on to say that their big customers have “chosen Linux or Apache or open source in general because of a few simple reasons: either price, or functionality, they want a more modular system or they want something that has a smaller footprint, there are certain needs that they have that are satisfied by that type of software.” Well, those are some pretty good reasons! I’ll add that when I was at BEA, our customers were also interested in the idea that if they needed fast turnaround on a bug, they could attempt to fix it themselves. And when I was at eXcelon, I found that some of the commercial software we bought had woefully inadequate documentation, and I was forced to decompile Java code in order to figure out how the product worked.

There’s another interesting article about Microsoft versus open source: an interview with the authors of a study called “Dynamic Mixed Duopoly: A Model Motivated by Linux vs. Windows”, which has just been accepted for publication in a special issue of “Management Science”.

http://hbswk.hbs.edu/item/4834.html

It’s all based on a simplified formal economic model, assuming that the main benefit of Linux is the shorter development cycle, while Windows’s main advantage is its larger installed base. Under these assumptions, Linux never drives out Windows (they don’t explain why in the interview). But then if you assume governments and large corporations start using Linux because they can audit it for security, and that companies such as IBM support Linux specifically to diminish Microsoft’s dominance, then Windows could get driven out of the market. They add, “This may be one main reason why Microsoft has been providing chunks of Windows’ source code to governments.” The support of IBM et. al. is important because there are tedious portions of the code that would rarely be developed spontaneously by members of the Linux-developer community.

I don’t know how much we can make of a formal model at all, let alone one with such simplified assumptions, as having actual predictive value, but it’s the only thing I’ve seen like this so I thought it was worth looking at.

Their outlook on why developers are motivated to contribute to open source projects in the first place is: “First, some developers see software as scientific knowledge to be shared ‘like the sharing of recipes among cooks.’ In fact, some describe software developers more like artists seeking fun, challenge, and beauty in their work than like calculative, square-minded engineers. Second, some individuals find it fun to go against Microsoft. As the OSS/free software movement gains momentum and developers foresee that victory is within reach, they increase their effort to accomplish this. Third, because most OSS projects have a log file listing all contributors to the code, some developers find it desirable to participate in OSS projects to signal their ability and to enhance their chances of promotion and professional advancement. Finally, user-developers sometimes fix bugs that they find and then release the improved code so that everybody can benefit.” I’d add that some are paid to develop open source software.

Among their list of things Microsoft could do, the juicer ones are: Let governments access the source code. Give binary away free to organizations and individuals who are not willing to spend money on Windows but would be willing to use Linux (this is like what the airline industry calls “revenue management”: charge less to people who can afford less, using various tricky means to identify these people). Make it as hard as possible for Windows applications, and MS Office documents, to work on Linux. “Promote” Linux’s code forking. And finally. “Infuse fear, uncertainty, and doubt into the Linux user community. For this to work, the statements must be perceived as credible. Credibility requires some past FUD announcements to be realized.”

Can you imagine Microsoft infiltrating open source communities with agents provocateurs whose job would be to foment forks? The main deterrent I can see would be bad publicity if they were caught; but Microsoft doing questionable things is hardly news.

Meanwhile, Microsoft continues to maintain that Linux infringes on 235 of their patents, but apparently won’t say which ones! Could they be bluffing? (Citation: http://www.informationweek.com/news/showArticle.jhtml?articleID=199602086) It reminds me of Joe McCarthy’s claim of having a list of 205 communists in the State Department. (It was a bogus claim, but the specific number gave it credibility.) Could Microsoft convince companies that they need to pay Microsort royalties on Linux? Apparently Wal-Mart has paid up. Would Microsoft tie up Red Hat in lawsuits, until they are overwhelmed by legal expenses? Would IBM come to their rescue?

In a comment on a previous blog entry, I was asked why Symbolics failed. The following is oversimplified but should be good enough. My old friends are very welcome to post comments with corrections or additions, and of course everyone is invited to post comments.

First, remember that at the time Symbolics started around 1980, serious computer users used timesharing systems. The very idea of a whole computer for one person was audacious, almost heretical. Every computer company (think Prime, Data General, DEC) did their own hardware and their own software suite. There were no PCs’, no Mac’s, no workstations. At the MIT Artificial Intelligence Lab, fifteen researchers shared a computer with a .001 GHz CPU and .002 GB of main memory.

Symbolics sold to two kinds of customers, which I’ll call primary and secondary. The primary customers used Lisp machines as software development environments. The original target market was the MIT AI Lab itself, followed by similar institutions: universities, corporate research labs, and so on. The secondary customers used Lisp machines to run applications that had been written by some other party.

We had great success amongst primary customers. I think we could have found a lot more of them if our marketing had been better. For example, did you know that Symbolics had a world-class software development environment for Fortran, C, Ada, and other popular languages, with amazing semantics-understanding in the editor, a powerful debugger, the ability for the languages to call each other, and so on? We put a lot of work into those, but they were never publicized or advertised.

But we knew that the only way to really succeed was to develop the secondary market. ICAD made an advanced constraint-based computer-aided design system that ran only on Symbolics machines. Sadly, they were the only company that ever did. Why?

The world changed out from under us very quickly. The new “workstation” category of computer appeared: the Suns and Apollos and so on. New technology for implementing Lisp was invented that allowed good Lisp implementations to run on conventional hardware; not quite as good as ours, but good enough for most purposes. So the real value-added of our special Lisp architecture was suddenly diminished. A large body of useful Unix software came to exist and was portable amongst the Unix workstations: no longer did each vendor have to develop a whole software suite. And the workstation vendors got to piggyback on the ever-faster, ever-cheaper CPU’s being made by Intel and Motorola and IBM, with whom it was hard for Symbolics to keep up. We at Symbolics were slow to acknowledge this. We believed our own “dogma” even as it became less true. It was embedded in our corporate culture. If you disputed it, your co-workers felt that you “just didn’t get it” and weren’t a member of the clan, so to speak. This stifled objective analysis. (This is a very easy problem to fall into — don’t let it happen to you!)

The secondary market often had reasons that they needed to use workstation (and, later, PC) hardware. Often they needed to interact with other software that didn’t run under Symbolics. Or they wanted to share the cost of the hardware with other applications that didn’t run on Symbolics. Symbolics machines came to be seen as “special-purpose hardware” as compared to “general-purpose” Unix workstations (and later Windows PCs). They cost a lot, but could not be used for the wider and wider range of available Unix software. Very few vendors wanted to make a product that could only run on “special-purpose hardware”. (Thanks, ICAD; we love you!)

Also, a lot of Symbolics sales were based on the promise of rule-based expert systems, of which the early examples were written in Lisp. Rule-based expert systems are a fine thing, and are widely used today (but often not in Lisp). But they were tremendously over-hyped by certain academics and by their industry, resulting in a huge backlash around 1988. “Artificial Intelligence” fell out of favor; the “AI Winter” had arrived.

(Symbolics did launch its own effort to produce a Lisp for the PC, called CLOE, and also partnered with other Lisp companies, particularly Gold Hill, so that customers could develop on a Symbolics and deploy on a conventional machine. We were not totally stupid. The bottom line is that interest in Lisp just declined too much.)

Meanwhile, back at Symbolics, there were huge internal management conflicts, leading to the resignation of much of top management, who were replaced by the board of directors with new CEO’s who did not do a good job, and did not have the vision to see what was happening. Symbolics signed long-term leases on big new offices and a new factory, anticipating growth that did not come, and were unable to sublease the properties due to office-space gluts, which drained a great deal of money. There were rounds of layoffs. More and more of us realized what was going on, and that Symbolics was not reacting. Having created an object-oriented database system for Lisp called Statice, I left in 1988 with several co-workers to form Object Design, Inc., to make an object-oriented database system for the brand-new mainstream object-oriented language, C++. (The company was very successful and currently exists as the ObjectStore division of Progress Software (www.objectstore.com). I’m looking forward to the 20th-year reunion party next summer.)

Symbolics did try to deal with the situation, first by making Lisp machines that were plug-in boards that could be connected to conventional computers. One problem is that they kept betting on the wrong horses. The MacIvory was a Symbolics Ivory chip (yes, we made our own CPU chips) that plugged into the NuBus (oops, long-since gone) on a Macintosh (oops, not the leading platform). Later, they finally gave up on competing with the big chip makers, and made a plug-in board using a fast chip from a major manufacturer: the DEC Alpha architecture (oops, killed by HP/Compaq, should have used the Intel). By this time it was all too little, too late.

The person who commented on the previous blog entry referred by to an MIT Masters thesis by one Eve Philips (see http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/ai-business.pdf) called “If It Works, It’s Not AI: A Commercial Look at Artificial Intelligence Startups”. This is the first I’ve heard of it, but evidently she got help from Tom Knight, who is one of the other Symbolics co-founders and knows as much or more about Symbolics history than I. Let’s see what she says.

Hey, this looks great. Well worth reading! She definitely knows what she’s talking about, and it’s fun to read. It brings back a lot of old memories for me. If you ever want to start a company, you can learn a lot from reading “war stories” like the ones herein.

Here are some comments, as I read along. Much of the paper is about the AI software vendors, but their fate had a strong effect on Symbolics.

Oh, of course, the fact that DARPA cut funding in the late 80’s is very important. Many of the Symbolics primary-market customers had been ultimately funded by DARPA research grants.

Yes, there were some exciting successes with rule-based expert systems. Inference’s “Authorizer’s Assistant” for American Express, to help the people who talk to you on the phone to make sure you’re not using an AmEx card fraudulently, ran on Symbolics machines. I learn here that it was credited with a 45-67% internal rate of return on investment, which is very impressive.

The paper has an anachronism: “Few large software firms providing languages (namely Microsoft) provide any kind of Lisp support.” Microsoft’s dominance was years away when these events happened. For example, remember that the first viable Windows O/S, release 3.1, came out in in 1990. But her overall point is valid.

She says “There was a large amount of hubris, not completely unwarranted, by the AI community that Lisp would change the way computer systems everywhere ran.” That is absolutely true. It’s not as wrong as it sounds: many ideas from Lisp have become mainstream, particularly managed (garbage-collected) storage, and Lisp gets some of the credit for the acceptance of object-oriented programming. I have no question that Lisp was a huge influence on Java, and thence on C#. Note that the Microsoft Common Language Runtime technology is currently under the direction of the awesome Patrick Dussud, who was the major Lisp wizard from the third MIT-Lisp-machine company, Texas Instruments.

But back then we really believed in Lisp. We felt only scorn for anyone trying to write an expert system in C; that was part of our corporate culture. We really did think Lisp would “change the world” analogously to the way “sixties-era” people thought the world could be changed by “peace, love, and joy”. Sorry, it’s not that easy.

Which reminds me, I cannot recommend highly enough the book “Patterns of Software: Tales from the Software Community” by Richard Gabriel (http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf) regarding the process by which technology moves from the lab to the market. Gabriel is one of the five main Common Lisp designers (along with Guy Steele, Scott Fahlman, David Moon, and myself), but the key points here go way beyond Lisp. This is the culmination of the series of papers by Gabriel starting with his original “Worse is Better”. Here the ideas are far more developed. His insights are unique and extremely persuasive.

OK, back to Eve Philips: at chapter 5 she describes “The AI Hardware Industry”, starting with the MIT Lisp machine. Does she get it right? Well, she says “14 AI lab hackers joined them”; see my previous post about this figure, but in context this is a very minor issue. The rest of the story is right on. (She even mentions the real-estate problems I pointed out above!) She amply demonstrates the weaknesses of Symbolics management and marketing, too. This is an excellent piece of work.

Symbolics was tremendously fun. We had a lot of success for a while, and went public. My colleagues were some of the skilled and likable technical people you could ever hope to work with. I learned a lot from them. I wouldn’t have missed it for the world.

After I left, I thought I’d never see Lisp again. But now I find myself at ITA Software, where we’re writing a huge, complex transaction-processing system (a new airline reservation system, initially for Air Canada), whose core is in Common Lisp. We almost certainly have the largest team of Common Lisp programmers in the world. Our development environment is OK, but I really wish I had a Lisp machine again.

Richard Stallman has been telling a story about the origins of the Lisp machine companies, and the effects on the M.I.T. Artificial Intelligence Lab, for many years. He has published it in a book, and in a widely-referenced paper, which you can find at http://www.gnu.org/gnu/rms-lisp.html.

His account is highly biased, and in many places just plain wrong. Here’s my own perspective on what really happened.

Richard Greenblatt’s proposal for a Lisp machine company had two premises. First, there should be no outside investment. This would have been totally unrealistic: a company manufacturing computer hardware needs capital. Second, Greenblatt himself would be the CEO. The other members of the Lisp machine project were extremely dubious of Greenblatt’s ability to run a company. So Greenblatt and the others went their separate ways and set up two companies.

Stallman’s characterization of this as “backstabbing”, and that Symbolics decided not “not have scruples”, is pure hogwash. There was no backstabbing whatsoever. Symbolics was extremely scrupulous. Stallman’s characterization of Symbolics as “looking for ways to destroy” LMI is pure fantasy.

Stallman claims that Symbolics “hired away all the hackers” and that “the AI lab was now helpless” and “nobody had envisioned that the AI lab’s hacker group would be wiped out, but it was” and that Symbolics “wiped out MIT”. First of all, had there been only one Lisp machine company as Stallman would have preferred, exactly the same people would have left the AI lab. Secondly, Symbolics only hired four full-time and one part-time person from the AI lab (see below).

Stallman goes on to say: “So Symbolics came up with a plan. They said to the lab, ‘We will continue making our changes to the system available for you to use, but you can’t put it into the MIT Lisp machine system. Instead, we’ll give you access to Symbolics’ Lisp machine system, and you can run it, but that’s all you can do.’” In other words, software that was developed at Symbolics was not given away for free to LMI. Is that so surprising? Anyway, that wasn’t Symbolics’s “plan”; it was part of the MIT licensing agreement, the very same one that LMI signed. LMI’s changes were all proprietary to LMI, too.

Next, he says: “After a while, I came to the conclusion that it would be best if I didn’t even look at their code. When they made a beta announcement that gave the release notes, I would see what the features were and then implement them. By the time they had a real release, I did too.” First of all, he really was looking at the Symbolics code; we caught him doing it several times. But secondly, even if he hadn’t, it’s a whole lot easier to copy what someone else has already designed than to design it yourself. What he copied were incremental improvements: a new editor command here, a new Lisp utility there. This was a very small fraction of the software development being done at Symbolics.

His characterization of this as “punishing” Symbolics is silly. What he did never made any difference to Symbolics. In real life, Symbolics was rarely competing with LMI for sales. LMI’s existence had very little to do with Symbolics’s bottom line.

And while I’m setting the record straight, the original (TECO-based) Emacs was created and designed by Guy L. Steele Jr. and David Moon. After they had it working, and it had become established as the standard text editor at the AI lab, Stallman took over its maintenance.

Here is the list of Symbolics founders. Note that Bruce Edwards and I had worked at the MIT AI Lab previously, but had already left to go to other jobs before Symbolics started. Henry Baker was not one of the “hackers” of which Stallman speaks.

• Robert Adams (original CEO, California)
• Russell Noftsker (CEO thereafter)
• Minoru Tonai (CFO, California)
• John Kulp (from MIT Plasma Physics Lab)
• Tom Knight (from MIT AI Lab)
• Jack Holloway (from MIT AI Lab)
• David Moon (half-time as MIT AI Lab)
• Dan Weinreb (from Lawrence Livermore Labs)
• Howard Cannon (from MIT AI Lab)
• Mike McMahon (from MIT AI Lab)
• Jim Kulp (from IIASA, Vienna)
• Bruce Edwards (from IIASA, Vienna)
• Bernie Greenberg (from Honeywell CISL)
• Clark Baker (from MIT LCS)
• Chris Terman (from MIT LCS)
• John Blankenbaker (hardware engineer, California)
• Bob Williams (hardware engineer, California)
• Bob South (hardware engineer, California)
• Henry Baker (from MIT)
• Dave Dyer (from USC ISI)