Software Stack? Software Network! (And From There to Dependencies)
I enjoyed reading Stephen Walli's essay recasting the "open source stack" into a network of components. As soon as I saw it, I wondered whether the transactional costs of many interface points are responsible for a lot of the difficulty in getting a particular level "right". For example, the troika of applications, libraries, and languages is a painful one: from Microsoft's DLL hell, to anyone who's been caught in the endless GNOME upgrade cycle.
Obviously the circular dependencies are a problem, but I wonder whether the bidirectional nature of each dependency is a factor--the fact that libraries are written for applications, and applications written to use libraries, meaning that changing one probably means a change in the other. This locks in with what David Heinemeier-Hansson (plug: EuroOSCON keynoter) said in an O'Reilly Network interview:
That's why we hold the notion that "frameworks are extractions" so very dear in the Rails community. Frameworks are not designed before the fact. They're extracted when you've proved to yourself that an approach works. Whenever we get ahead of ourselves and try to leap over the extraction process, we come back sorely disappointed.
In other words, they break one direction of the arrows: libraries are extracted from applications, so applications shouldn't have to be rewritten when the library changes. I'm having a lot of trouble picturing how this would scale, though: it's easy for DHH when he extracts Rails from Basecamp, but how does that work in the GNOME world? There a shared library has to support a hundred applications, and so you must merge differing needs. When the API requires a change because of one or two project's needs, all applications have to be changed. It'll be interesting to see how more people using Rails breaks or fails to break existing Rails applications.
tags:
| comments: 5
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4252
Comments: 5
Edd, my experience with GNOME has been that installing a new application requires a different version of a library that you already have. The library upgrade (even if a minor version number change) breaks another app you have, or has its own dependencies. After an hour of going around like this, I discover some fundamental incompatibility (Gfoo doesn't work with the version of the library that Gbar absolutely must have) and rm -rf it all off my machine in disgust.
I had this problem on FreeBSD, I had it on Linux, and I had it on OS X. Each time someone tells me the problem no longer exists, I try again. Each time I run into it again. At this point, it's going to take a lot of people to convince me that the problem's solved before I try again.
I'm not saying GNOME sucks because of it. Perl has a very similar problem with CPAN modules and version numbers. While the problem of spending 45m installing modules only to end up with CPAN.pm attempting to upgrade your Perl version is mostly gone, it's still the case that dependencies are an unsolved problem in Perl. I can require a specific version of a module, but I can't install multiple versions. Despite this, Perl is still good and useful. So I'm not about to call anyone else "poopyshoes" because there's a strong odor emanating from my own boots.
Mac-Linux sniping left as an exercise to the readers :-)
I don't think it's an accident that more complex Perl-based web applications (e.g., MovableType) ship with most of the required libraries. It's a bit sad though that this usually only happens for applications that are also targeted towards non-technical users.
Did I hear someone say open source stack? Time to take a shot! (courtesy of the Web 2.0 drinking game)
we have been looking at this issue:
i think openlogic has a great notion "stacros" (from stack+macro)
http://www.redmonk.com/jgovernor/archives/000945.html
but Stephen o'grady has been doing a great job on some of these issues. modularity vs integrated innovation...
http://www.redmonk.com/sogrady/archives/000950.html
http://www.redmonk.com/sogrady/archives/000880.html
Post A Comment:
RECENT COMMENTS
- james governor on Software Stack? Software Network! (And From There to Dependencies): we have been looking at...
- Justin on Software Stack? Software Network! (And From There to Dependencies): Did I hear someone say ...
- mardoen on Software Stack? Software Network! (And From There to Dependencies): I don't think it's an a...
- gnat on Software Stack? Software Network! (And From There to Dependencies): Edd, my experience with...
- Edd Dumbill on Software Stack? Software Network! (And From There to Dependencies): While I won't deny ther...
Edd Dumbill [08.31.05 02:03 PM]
While I won't deny there's no issue, I don't think there's an "endless GNOME upgrade cycle". GTK 2 has been binary compatible for a long period--about three years, if I'm not mistaken.
Sure, if you want the new candy, you upgrade. I'd be worrying about the OS X upgrade cycle more.
For details of the work being done to rationalise the GNOME platform for developers, see http://live.gnome.org/ProjectRidley
In many ways Ridley is the acting out of extracting the framework from the applications--lots of diverse little libraries being condensed back into one framework. (It's taken a long time for the GNOME world to come to the point of realising it's not always the abstractions and their boundaries that count most, but the applications.)
As per Rails, I expect we'll see something akin to what's happened with Zope and platform libraries such as GNOME: products will be released targeting a stable version of the platform, and then need to be rewritten in part for the next stable release.
During the development of GNOME there've been two sorts of change: the long-running major change (1->2), and the incremental improvement (the 2.x series). It seems you need both. Sometimes the 1->2 (or should I say 9->X) change brings greater success, and sometimes it means the end; but I'm not sure it's avoidable.