The Architecture of Open Source Applications

This looks like a very interesting book, and it's free to view online: The Architecture of Open Source Applications.

Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well—usually programs they wrote themselves—and never study the great programs of history. As a result, they repeat one another's mistakes rather than building on one another's successes.

This book's goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

looking for contributions

We hope LtU readers will enjoy the book (and please do purchase a copy --- all the royalties go directly to Amnesty International). We are actively looking for contributions to either an enlarged second edition or an entire second volume: if you would like to write 5000 words or so describing the architecture of some interesting piece of open source software, please check out our FAQ, or contact us directly. And if you're a grad student in computer science, and looking for an interesting research topic that will lead to widely-cited papers, please get in touch as well --- I have a proposition for you :-)

I have bought the book after

I have bought the book after seeing the description here and reading through some chapters.
It's maybe not directly relevant, but I was personally not so enthusiastic about giving the money for the book to charity. I would rather have given money to the open source projects described on the book, the authors, or simply paid less. I think activity in the open source community and helping charity organizations are distinct and I don't like to collide them. I also understand that that may have been the will of the book authors, which I respected by my purchase.

XKCD 871?

In effect, you are paying the authors ...

... who are then passing on the income to a third party. If you didn't know they were doing this, or what the third party was, how would that affect anything?

In effect

I have a hard time believing that all authors, if they had the individual choice of how to use some of the book income, would choose to give exactly this amount of money to exactly this charity organization. I rather assume that the idea comes from some of them, and was naturally accepted by the other (who would refuse?), but would potentially have made something else if given the discretionary choice.

All in all, yes, I would prefer not to know. When you sell me something, you don't need to tell me how you plan to spend the money if it's entirely unrelated. If you tell me, I suppose that's because you think I should be aware of it, because maybe somehow it justifies the price I pay. It's a source of awkwardness when it doesn't.

This is getting really

This is getting really off-topic for LtU.


The reason I became interested in programming language design was because of the plethora of design examples, critiques, and mathematical tools available for ensuring or predicting well-behaved design. If you trace through the history of language design, there is such a rich body of papers about design, especially in the glory days of Dijkstra, Wirth, Brinch-Hansen, Kay, Landin, Strachey, Scott, Gelertner, Shapiro, etc. back when the Communications of the ACM allowed several page "letters to the editor" with detailed public critiques of prior articles.

I think that most of the chapters from this book, I cherrypicked reading, disappointed me. Allman's chapter on sendmail is a weak apology for what, by today's standard (qmail), is a horrible piece of software; who cares that it is the most popular? In America, we vote more for the next American Idol than we do our President. Popularity has a very weak correlation to importance in our daily lives.

Likewise, I thought the chapter on Eclipse focused too much on Eclipse from a social perspective and didn't really discuss architectural details. While events like Eclipse Ganymede are cool and a testament to Conway's Law, and the article demonstrates Conway's Law well, it doesn't say anything too meaningful about modularity other than "We used OSGi." Similarly, it didn't say anything too meaningful technically about emulated widget toolkits versus native widget toolkits provided by the OS, not even basic questions like do the emulated widget toolkits call the underlying OS's APIs? Why is that a good or bad idea? This author also brings up bizarre timing issues in Swing, but doesn't bring up any actual examples of timing issues for a cross-platform GUI toolkit, such as (a) time resolution for the native toolkit varying across systems (b) the fact focus transfer in Swing is asynchronous and dependent on procedural invocations of GUI objects, and most programmers don't understand this model of focus.

I could go on.

Thumbs DOWN.

I second this

I read parts of the book and can only say that I was disappointed too. Primarily since the book doesn't deliver what the title promises: a thorough exposition of the architecture of software. Most chapters just discuss a piece of history, an occasional design decision, how to use or configure programs, or the initial assumptions on writing a piece of software. The sole exception, possibly, was by the author of LLVM; but even here I sorely missed some design pictures. I mean, surely software engineering has passed the point that software is loosely described with a few ideas. Where are the package diagrams, library dependency graphs, maybe some UML?

Having said that, I think that Z-Bo is too negative. A book on the architecture of software is a good idea; I am sure a lot of architects are interested in that. Only thing I can say is: Better luck next time.

I really liked the LLVM chapter, actually

That was a great chapter. In particular, he referenced external documents as pointers for further reading. He didn't copy and paste his Ph.D. thesis into this book, but instead gave the technical highlights as to why his Ph.D. project ended up being a huge open source and commercial success.

Let's compare with Allman's sendmail:

  • No mention of qmail
  • Complete refusal to see a common security problem in all of his security examples (ambient authority) and waving his hand at the problem as academically difficult, when it is clearly not; qmail stomps out ambient authority by writing an interpreter that serves as a powerbox for mail functionality
  • Good programmers stomp out stupid ideas, including one's they were responsible for. Allman's critique was so incredibly weak he may as well have been Tiger Woods P.R. director for apologizing to his wife.

For Eclipse, there also is very little external references. Because the author positions Eclipse as the be-all end-all of IDEs, it is beneath the author to talk about specific useful subsystems in an IDE, and how the subsystems are integrated. For example, a valid external reference for text editors is The Craft of Textediting, which explains the Emacs everything-is-a-buffer model in detail. There is also the book Inside SharpDevelop which discusses an IDE with a much more narrower focus. Then there is also Practical API Design by the author of NetBeans.

Also for Eclipse, what about how monolithic the development tools currently are and how when people re-use the code, they use monkeypatches using aspect weaving to get Eclipse to talk to their plug-in. Clearly there are some design issues in Eclipse.

I also really hated the chapter on CMake. My summary: "It started off as a way to manage building C/C++ code on multiple platforms, and morphed into this ginormous thing nobody ever imagined. My God, how did this happen? Let me tell you..." If anyone wants to read a book about a great build system, read Software Configuration Management using Vesta. The justification for writing a new build system there is miles beyond what CMake did.

Having said that, I think that Z-Bo is too negative.

I could be much more negative :)

The hard thing, though, is that it is hard to be too negative when people are still alive. As Henry Petroski, author of famous design error and evolution books, points out: The best examples he uses always come from the past, since there is usually political motivation and other reasons for not using fresh examples for criticism. One of his few fresher examples is the Tacoma Narrows Bridge.

chapter favorites and dislikes

My favorite, so far, is the Berkeley DB chapter which, to my mind, is squarely about various aspects of software architecture. I think it is a rehash of stuff the BDB folks have presented elsewhere, before, many times ... but they assembled it nicely and appropriately for this collection. (I guess I'm also biased because I have long thought BDB is truly a great example of good software architecture. I wish I knew and had had a chance to work with people like that.)

Like z-bo, I didn't like the Sendmail chapter but for different reasons. It appeared to have nothing at all to do with software architecture in any useful sense and was instead a hash of many earlier sendmail talks that were mainly about amusing anecdotes signifying the importance of sendmail throughout history.