chris horn's blog

When I was a kid, my sister and I loved sharing our toys and playing together. She had a farm, with farm buildings and fenced fields; a hospital, complete with a helicopter landing pad for emergency cases; and a dolls house, whose front swung open to reveal a hidden world for miniature furniture and figures. I myself had a garage, which had an inspection bay and an elevator for the cars; docks, with piers and cranes and ships; and an airport, with runways and a passenger terminal, and tiny fuel trucks and baggage carts. We would sprawl ourselves across the play room and build our town, playing as gods as we moved people and animals and freight in our virtual world, from the farm to dock to the airport to the hospital. Of course, we had to try and ignore the differences in scale of our toys – her dolls house dwarfed everything – as well as the bumps and crevasses in our roads, where the edges of the bases of the toys butted up against each other.

In those “black and white days”, as my now 10 year old daughter calls them – the days before colour TV and lcd flat panels – there wasn’t a lot of plastic, and wonderful kits like Lego™ had only just begun appearing. Now my own kids can build towns from Lego kits, with consistent scale across all the buildings, unless of course they choose to make one building much bigger than the others. The roads all smoothly meet up at the junctions, and Lego people and animals and freight all appear wonderfully realistic as scenarios are enthusiastically played out for Dad’s benefit.

What is even more wonderful about toys such as Lego is that children’s fantasies can be cultivated, as they themselves design and construct their own buildings and vehicles and systems, using their imagination to mimic and extend their worlds. They are not limited to the pre-designed model described by each Lego instruction sheet or booklet. Indeed, my teenage son shares designs with his friends, sketching out their own instructions, and photo-copying them for each other. I googled to see whether there is a web site somewhere where people can share their designs and instructions with each other – I could find a few (such as http://staff.science.uva.nl/~leo/lego/ and http://www.telepresence.strath.ac.uk/jen/lego/ and Lego’s own http://factory.lego.com) but no single aggregation: now, there’s an idea if someone hasn’t already done it.

In 1992, when I started building Orbix v1.0 - our CORBA implementation - with John Moreau and Bridget Walsh, the software community was talking about the novel concept of object oriented programming, and some proponents certainly drew parallels with construction kits such as Lego. If civil engineers build using pre-fabricated components, and kids build complex buildings and systems from re-usable Lego bricks, then why can’t the software industry build using a portfolio of re-usable objects and components ? A decade plus later, I guess today we pretty much have learnt this lesson, and much of our complex software artefacts are constructed using re-usable components and common design patterns.

In the “black and white” days, toys were complete. A dolls house was a dolls house. A toy garage was a toy garage. You couldn’t re-assemble it to build something closer to your imaginary perfect garage. A decade ago, software applications and indeed operating systems were likewise monolithic. Sure, you could configure products like SAP R/3 and SVR4, but you couldn’t delve inside them, learn from them, and build systems which were closer to the perfection you craved for your organisation. Today, open source, and software componentisation, has changed the industry, and so you can now assemble and build tailored – and even generally useful – software yourself.

However, now the interesting thing, I think anyway, is where is our – I mean the software world’s – equivalent of those Lego instruction sheets and booklets, those photo-copied personally designed instructions for new models ? Software design patterns are not really the same thing: a software design pattern gives a “how-to” elegantly solve a commonly occurring scenario, regardless of what you are actually building; a Lego instruction sheet, whether direct from Lego or invented by one of your friends, tells you how to build a complete and finished model.

That’s why I got very enthusiastic when Mitch Sonies and Henrik Lindberg approached me last year to talk about Buckminster and Cloudsmith. Buckminster is open source technology which they have donated to the Eclipse foundation -- although Buckminster is not dependent on Eclipse, a “headless” version also exists. A specific software configuration is captured in an RMAP and CQUERY. I like to think of a CQUERY as akin to a Lego instruction sheet, with the RMAP saying which Lego blocks are in which containers and bags. An CQUERY captures, both explicitly but also implicitly by transitive closure, all the necessary software components – other completed models and even individual bricks – needed to build a fully complete system, or component. Given a CQUERY and RMAP, Buckminster then can actually go ahead and build – or “materialize” in Buckminster parlance – the artefact so described, for you on your machine.

Now, you might say, gee Chris, ‘make’ systems have been doing that even since before you were a developer back in the 90s. Well, Buckminster is a bit more than that. What if you want to build something that depends on components from different software repositories: some repositories inhouse in your company or on your own private computer, and some remote across the internet. What if these repositories use different formats – CVS, maven, clearcase ? What if there are version dependencies between the components ? What if there are alternative repositories for the same component ?

Some of the Eclipse projects are looking very hard at Buckminster, and I understand that some have already adopted it. I think there will be quite a bit of discussion about Buckminster at the forthcoming eclipsecon conference. But I don’t want you to think of Buckminster as an Eclipse-based Java-centric tool. Because it isn’t. Back to the Lego analogy – as well as Lego, not only is there Duplo from the same company, but also construction kits from Young Architects and Brio and Imagibrick and others. In our software industry, we’re similarly plagued by different core technologies, leading to bumps and cravesses as you try to butt together one completed system with another. Buckminster at least solves the problem of defining and materializing useful configurations of software – regardless of the technologies – Java, PHP, C# or whatever - used.

One of the most frustrating things about the software industry today, I think, is that although it is much easier now to build interesting new artefacts and systems from re-usable components, it is quite difficult to communicate these configurations and fit them together with other peoples’. Linux distribution vendors, such as RedHat and Ubuntu, do a fine job selecting a specific configuration of several thousand software components, and warranting to a greater or lesser degree that they should all work together. But, sometimes creative developers have different configurations that they seek, or want to define, share and publish to the world. Can interesting new virtual distributions be rapidly defined, communicated and materialized ?