chris horn's blog

Professional investors understand liquidity. They understand asset backed securities, and they understand the risks when assets subsequently emerge to be poorer quality than they were represented to be. Sub-prime assets can be embarrassingly illiquid and career changing.

In the world of enterprise IT investments, customers have likewise yearned for liquidity. Lock-in to assets available solely from any single vendor implies significant risk to the purchaser. Bad investment decisions into IT assets which subsequently emerge to be poorer quality than they were represented to be, can be embarrassing and career changing – particularly if the assets are illiquid and difficult to replace.

Financial markets have been driven by liquidity. However by contrast, purchasers of IT assets have found it challenging to be able to subsequently replace and substitute alternatives when desirable.

Until now.

Today, I believe that the software and hardware industries are fundamentally changing in favour of liquidity. Software is increasingly componentized. Software has increasingly recognized industry standards which facilitates substitution of alternatives. Open source provides liquidity through lowering the cost of change.

Enterprise software vendors should be trusted partners in providing and maintaining tailored solutions. The ability to successfully integrate a variety of components from a variety of sources to an enterprise level of service is valued. The ability to scalably manage multiple configurations, and evolve them dynamically over time, is valued. Tailorable, personalized solutions for specific customers, partners and staff, but all as part as of the holistic enterprise, are valued. Dynamic systems enable liquidity amongst software assets – no matter from which particular vendors specific assets are obtained.

New, and sustainable, business models are emerging from software vendors who deeply understand technology liquidity.

Single, monolithic, vertically integrated silos of software stacks is thinking from the last century. Integrated stacks are illiquid if any specific components or layers cannot be readily substituted by better alternatives on the market today, or which may emerge tomorrow, from any vendor.

It does not take an oracle to foresee what will happen if BEAS are purchased by ORCL. Overlapping products – portal servers, application servers, service busses, Java development platforms, whatever – will be culled: “synergies” throughout the two organizations will be executed. ORCL will attempt to cross sell its own offerings into the BEAS client base and migrate them away to ORCL alternatives.

Professional investors understand liquidity. Even if they are new to investing in IT equities, they therefore should have little difficulty in understanding that enterprise IT customers likewise yearn for liquidity of technology assets. In the past, enterprise vendors have been slow to offer liquidity. Now, the IT industry is changing fast, and the potential upside for investors in IT is vendors who understand and are executing on technology liquidity: vertically integrated illiquid stacks are from a former and sub-prime era.

Think liquidity.

Like some other teenagers of my generation in the seventies, one of my hobbies at the time was faithfully constructing scale models from plastic kits from Airfix, Revell, Historex etc. As I developed my skills and interest, I took great pride in adding extra levels of detail – particularly for ship kits. Eventually I converted particular kits so as to model an aircraft, ship or vehicle not directly available as a standard kit, by moulding balsa, crafting acetate sheet and so on – for example building a twin engine, triple tail fin Avro Manchester from the Airfix kit of the successor four engine Lancaster. The monthly Airfix Magazine was a great source of designs and examples, and I still have a shelf full of back copies here in my office at home.

When I was an engineering student, I took a similar interest in building my own, albeit fairly simple, analogue electronic circuits – the usual things such as oscillators, radios, fire/smoke detectors, etc. Of course, as with converting plastic kits, having a good stock of spare parts - scavenged from broken electronic circuits – was useful. I used to keep them sorted into empty margarine tubs on my shelves.

In more recent years, I became more and more involved in computers, from the digital gates and circuits up to microcode, assembler, compiler/interpreter systems and finally full systems and applications. I was fascinated when they became affordable as home systems, and played around adding extension cards and interfaces to my first PC. I was initially really impressed by Dell when I saw their range of alternative pre-configured systems for direct order across the internet. Dell used to have a plant in Bray just a few miles away from my home, and I have bought many systems over the years from them for home, school and charitable use.

But I’ve often thought there must be quite a few people out there like me who aren’t quite happy with a specific system they buy from Dell (or indeed any other supplier). Although I carefully chose a configuration before buying, still afterwards I frequently tailor my purchase further with additional cards, expansions and options. I also wonder whether somebody out there has already built the perfect system for creative digital photography, or multi-screen home media management, or whatever. Or whether anyone would be interested if I could publish my own designs and configurations. Or whether any configurations would be commercially interesting, for example for specialist systems such as creative digital media design.

Reflecting on my fads above, the common aspects are a desire to build interesting variations of basic designs; from additional parts either built myself, or stock-piled somewhere (not necessarily in margarine tubs!), or purchased elsewhere; to look at designs published by others, and perhaps even to publish my own.

Well, that’s what Cloudsmith is doing for the world of software. One way to think of Cloudsmith is as a derivation of Dell’s world, for software. You can browse an online catalogue at Cloudsmith and see what “distros” – configurations - of software components are available. If you want to chose any particular one, you click it and it “materializes” – ie downloads its parts, and then automatically assembles them together – onto your machine. And like getting a system from Dell, the different components of your configuration will usually come from different “repos” (repositories - think Dell sub-suppliers) around the world. So rather than just a single download of a binary file, a materialization will usually automatically fetch multiple files, from multiple places, and assemble them automatically for you on your machine as a complete system. The distro is thus “virtual”: it is not monolithic (like an old download) and its parts are not hosted at Cloudsmith (any internet repo can contribute).

If you like what you find, you can send others the “Cloudlink” you used. When they click it, the same components will materialize from the cloud of components available in multiple repos across the internet, and assemble and install on their machine too. So, you can materialize something specific without having to yourself connect to the Cloudsmith site and without having to search the online catalogue for it – just get the Cloudlink for it from someone else via an email or blog or whatever, and the magic will happen when you click.

Whats kinda nice about the Redhats of this world is that they pre-assemble a large collection of software components for you as a full Linux system. Whats nice about Cloudsmith is that if you build your own interesting set of software components, then you can publish that configuration at Cloudsmith, and reliably make it available for other people to use. It need not of course be as complex as a full operating system: just a nice application or tool or subsystem for a particular use which you have put together, using your own design or as an interesting derivation from somebody else's published distro. You can publish novel and interesting things that you’ve done, for others to take a look at and possibly use – no longer are you or they tied just to the pre-assembled varieties which the software equivalents of Dell provide. And if you have components from a new repo which Cloudsmith does not yet know about, you yourself can simply add that repo to Cloudsmith’s map of the world – it is the Cloudsmith software equivalent to introducing Dell to a new sub-supplier.

Why hasn’t a service like Cloudsmith existed up to now ? One reason is that although there has been a proliferation of useful re-useable software components developed and published around the world in many online repos, there has equally been a proliferation of software version control, make and build systems. It is difficult to justify re-engineering everything globally to use the same version control and build technology. IMHO it is impossible to impose one build or version control technology, or one IDE, on everyone: and it is short-sighted to expect everyone else to use the one that you happen to think is best. However, with some thought and help, it is possible for systems like Cloudsmith to automatically, on the fly, interpret the meta-information in all these version control and build system technologies, and thus automatically derive a global perspective and capability across many different repos.

But how do you know that somebody else’s published configuration is any good, and trustworthy? Well how does a plastic modeler or an electronics hobbyist know that somebody else’s design is any good ? Part of the answer is the popularity of the design – how many others are using it, and what do they say about it – and part of it is the reputation of the designer. Social community sites on the internet in general work because most people are ethical, and many people can watch, observe, comment and mend where necessary information which is incorrect.

Assembling and publishing new configurations of components is fun. Is it however just for hobbyists and software hot-rodding ? I believe that many commercial organizations will find interest in discovering and contributing to software configurations and assemblies that add real value in their business domains. I think enterprise managers will find reassurance not only in the popularity of certain distros, but also because they can be reassured that precisely the same distro (and bill of materials) is reliably installed on every machine under their control, and because component updates can be notified and controlled. I think vendor product managers and technology strategists will find interest in the concept of being able to build their own private “cloudspaces” for their licensed customer communities, to manage and distribute software in a controllable way.

Now, let me put my hand up and confess that all of this isn’t yet as smooth as we would like at Cloudsmith just right at the moment: it is an alpha version for the community to experiment with and give us feedback on. The materialization wizard, the wizard to build a cloudlink are IMHO both pretty good and straightforward to use. Private and public cloudspaces are ready to use. But today, the publishing wizard and the wizard to register a new repo are IMHO a bit clunky: we’re improving them right now and we expect better versions within a couple of weeks. Our online documentation is being improved. However, if you’re interested, contact us and we’ll talk you through online and get you involved in the Cloudsmith community.

As some of you may know, I regularly holiday just outside Roundstone in Connemara. I’ve just come back to Dublin yesterday after some time there again.

If you haven’t yet been to the west of Ireland, I think one of the most striking things is the web of small stone walls that embrace the fields, pastures, meadows, boglands and tracts. Each is made by hand, and almost always as dry stone walls without mortar. They usually are as a result of clearing granite stones and rubble from the fields, and are economic: not requiring mortar, they do not suffer from frost attack, and so little maintenance is needed. At first sight, they all appear similar, but in fact there are different construction styles, with single, double and combination walls as the basic classification. They are malleable: walls can be easily moved and re-configured – gates are not strictly necessary since a few stones can easily be removed and put back again to, for example, let cattle through. Patrick McAfee’s book and website are a very readable commentary.

From ground level, the profusion of little stone walls can appear as a complex pattern, perhaps even fractal-like. But viewed from a high point, perspective reveals the logic of the landscape and the paths – the boreens – lined with walls either side, gently meandering to distant places.

I came back to Dublin last night, and this morning read Martin Banks’, of Reg Developer, excellent overview of Buckminster. Since I first wrote about Buckminster, the team has considerably improved the tool, including the documentation kit. Martin’s article makes use of a bricklaying analogy, and I guess I hinted in my own blog entry that if you are to build structures from re-usable bricks, then it might be useful to have a web site somewhere at which various designs could be published found and compared…

Well, also while I was away in Connemara, www.cloudsmith.com went live. Many of those on the Buckminster team have collaborated to put the site together, and the initial incarnation of the site certainly turned out to have richer functionality than I myself expected in a first iteration. There is a fairly detailed overview on the About Cloudsmith page, but in summary:

• Cloudsmith keeps meta-data about assemblies of software components.

• Software components can be sourced from any number of public and private repositories worldwide. Of course, components from private repositories are only available to those duly authorized to use them.

• Cloudsmith does not store the components themselves: but it knows where they are worldwide and how it can access them in the appropriate repository formats.

• A software publisher – an individual, project, or company – can register one or more specific software component assemblies with Cloudsmith.

• A software consumer – an individual, project, or company – can search and browse for available assemblies; and can readily download and install any particular one – “materialize” in Cloudsmith-speak – onto his local machine (or indeed another machine if appropriately authorized).

In effect, Cloudsmith is building a global map of software components (in various forms: source, binary, versioned, and optionally with test suites, documentation and license agreements). Professional software developers - individually or in a community project or working on a commercial offering – can publish interesting new assemblies of components, sourced across one or more repositories.

One of the neatest capabilities of Cloudsmith is a Cloudlink. A Cloudlink is simply a URL: it can be sent in an email, or given in a blog or whatever. When a Cloudlink is clicked, the software assembly which it denotes is then materialized without further intervention, onto the local machine. This gives a very simple download mechanism: publish a Cloudlink, and anyone clicking on it within a recent-vintage web browser can download your software. In practice, when a Cloudlink is clicked, behind the scenes the Cloudsmith site is contacted, and it resolves the differences between the assembly of software components identified by the Cloudlink, and those already available on the local machine, and then fetches (as appropriate from various repositories worldwide) and downloads the missing components.

Cloudlinking in turn enables “virtual distributions”. A software publisher can create a virtual distro, whose components reside across multiple (eg open source) projects and repositories: materializing a virtual distro requires nothing more than a web browser.

If your project is looking for a simple way to make its software available to the worldwide community; if your project is itself using software from multiple sources and multiple projects; if you want to keep your community regularly updated with patches and extensions; if you want to manage installation and distribution processes; then Cloudsmith should be worth taking a look.

Software components, and configurations and assemblies of them, are very malleable. It is relatively easy to define new interesting configurations, as well as new components. Looking at the world wide activity, and the multitude of repositories and projects, it is easy to become overwhelmed. It is possible to detect patterns, and different styles of construction, but sometimes it can be very confusing to see overall themes, to understand how other people are using configurations, and what changes have occurred.

I’m reminded of Connemara’s dry stone walls. They are numerous, wonderful, simple, easily changed, easily re-built, easily maintained, and as a result have lasted for decades. But in the landscape and up close, they are confusing to absorb and see the overall picture. The perspective of height gives clarity.

Cloudsmith is giving clarity to the construction of assemblies of software components.

I was the Chairperson of the Irish Management Institute a few years back, which was a little strange because I have no formal background whatsoever in business management, economics or finance! One of the raging discussions we had at the board level of the IMI was what should be the future of executive education in Ireland, including the relevancy or not of business school teaching to the needs of modern entrepreneurship and global business development. I found The Economist article thus particularly interesting, since it alluded to discussions about whether international business schools have lost their way and value.

Then, by coincidence, Monday’s Financial Times had a supplement on Business Education, including its international ranking of the top global executive education schools. It carried several very interesting articles suggesting that the top schools have changed their product from business education to business advice, and almost to management consulting. Customisation of curricula and classes lead to faculty not so much teaching, but instead providing insight in a discussion about specifically how to address issues within a client company, and/or specifically how to apply a particular idea or theory within a client company.

One of the things I had asked myself during my years at the IMI was whether there can be such a thing as a management profession. A profession, by definition, implies some core knowledge, which may be expanded and refined over time by appropriate research and in the light of experience; a way of asserting that an individual has attained a particular level of competence in that knowledge, and therefore can be admitted to the profession; and a code of ethics particularly as to service to the public, including appropriate disciplinary actions if these should be broken (The Economist article makes similar comments). As a professional engineer in Ireland, I am comfortable that Engineers Ireland operates our national engineering profession accordingly. The medical and legal professions are of course similar examples.

But can there be a management or business profession ? Is there a body of knowledge, an admissions procedure, a code of ethics and a disciplinary mechanism ? Can there be a guardian organization for the profession ? In fact should there not be one, so as to protect the public and including shareholders and investors ? However would such an organized profession stifle innovation and entrepreneurship ? As The Economist observes, Bill Gates dropped out of university and would presumably never have made the grade to become a “professional business manager”.

Hmmm. So what is executive education all about ? Can business management ever become a profession ?

I hesitate to comment further in general for all industries, but I do have some views more specifically as applies to the software industry.

In the mid 90s I had the sincere pleasure of having John Cullinane on the board of directors of IONA. John, as I am sure you know, founded and ran the first software company to file an IPO, the first billion dollar software company, and the first company to do a Super-Bowl ad! His company Cullinet was well known during the 1970s and 1980s. John has written an excellent summary of some of his lessons from those years, which I believe are as applicable today to software companies as they were then, in his book “The Entrepreneurs Survival Guide: 101 Tips for Managing in Good Times and Bad”.

One of the things John said to me early on as a board member at IONA was “You know Chris, managing a software company is actually easy”. I did a double-take when he said this to me, but he explained what he meant and I now basically believe he is right. Certainly compared to companies with manufacturing operations, managing a pure play software company would appear easier. I personally believe – and I sure some may wish to disagree with me – that the key operations of a software company (in no particular order) - engineering and software development processes; distribution channels and sales management, including compensation structures and channel conflict resolution; market segmentation analysis and product marketing; product management; professional services fulfillment; pre-sales technical support; after-sales support; product maintenance and upgrades; financial management, including financial planning and administration; internal IT systems; HR management, staff compensation, and gaining staff commitment; corporate marketing and PR; corporate governance; board procedures; management metrics and key performance indicator analysis; customer care and stratification; even M&A post-integration – in summary, all the functions of a modern software company are now reasonably well understood. There is – arguably – a body of knowledge out there which I suspect many of us in the industry would agree represents best practice in the industry, accumulated over the several decades of the pure play software industry since Cullinet. Listening and participating in the year long Leadership for Growth Programme here at Stanford has re-enforced my view. Perhaps somebody should write a book some time to capture this current body of practical knowledge – how to run a software company.

I guess if what I suggest above is true, then in principle two rival companies with very similar product offerings, and very similar strategies, and of very similar sizes, in principle should be unable to out-execute each other. That is a controversial claim, since execution is key to the success of any software company: but I do believe that a professional experienced software CEO is unlikely to make mistakes in execution, since what is needed in execution is actually now reasonably understood across the industry.

Competitive advantage then in the software industry is increasingly unlikely to come from execution alone. Instead, in my view, advantage comes from strategic insight and analysis, from new products and new business models. Advantage comes from understanding the current state within a particular segment of the industry, and leveraging that to introduce new products and services, perhaps in new ways, and which add sufficient value to motivate the market to invest and customers to buy.

“Success is 10 per cent inspiration and 90 per cent perspiration” said Edison. I think that the 10 per cent inspiration to conceive of a new idea is perhaps right; the 90 per cent comes not from actual execution, but from analysis and consideration of whether that new idea is actually worth executing upon – building a strategic plan and getting comfortable with it. If the strategic plan is worth executing on, then the steps to actually execute, given the body of knowledge about modern software company operations, are reasonably straight forward to identify: it should be reasonably obvious what needs to be done, and it becomes a matter of trying to actually do it.

An accepted body of knowledge will not, in my view, stifle innovation. Bill Gates would not have suffocated had such a pragmatic tome been available to him.

Perhaps I’m just representing a personal bias. I get excited by discussions on the state and direction of the industry, and where the current leverage points and opportunities are. I get less excited by discussions about operational issues, which of course are important and critical, but reasonably obvious in what needs to be done. Innovation in the industry creates competitive advantage; sheer execution is increasingly unlikely to do so.

I’m open to counter-persuasion. Flame suit on. What do you think ?

Part of the dilemma with the global software community today is that there are so so many open source repositories and projects. I guess amongst the best known community owned initiatives are Apache, eclipse and SourceForge. But there are very many others, as a quick Google will reveal: for example HotScripts, NetLib, RubyForge, and CodeHaus. Most of course are primarily specific to a particular technology but, nevertheless, large scale projects frequently span several technologies.

How can you easily and quickly put together your own project which relies on software components from several different source code repositories ? If your project works out to be cool, how can you easily and quickly share it with other people who may be interested in it ? Now, Linux distribution vendors such as redhat and ubuntu do a great job packaging together a large set of Linux based components – in ubuntu’s case, over 16,000 according to their web site. Great. But what if I myself want to package together some components which I found useful, in a configuration which those Linux distro-vendors don’t currently offer ?

The problem is generally exacerbated if the components which you want to select come from different repositories and projects, having different repository and dependency technologies – CVS, Maven, Subversion, Ant&Ivy, whatever. The problem is also made more difficult because of version dependencies on your installation environment and other components.

In an earlier blog entry, I wrote how assembling software today is reminiscent of childhood experiences with toy building kits, such as Lego. However, there is some danger that in assembling software components from different sources, you end up with a large pile of individual Lego bricks on the floor! There should be a better way of defining and tracking component assemblies across technologies and repositories.

I was excited to see that last week at eclipsecon, AOL’s Lucas McGregor announced the Eclipse Spaces technology project. I guess the essential concept is simple: just in the same way that MySpace provides online storage for friends to share videos and photos and news and events, there is now an opportunity for developers to informally and easily share online interesting component assemblies with one another. The eclipse project process of course offers a formal, process driven approach to collaboratively developing new software between companies, and I guess Apache has something similarly formal between individuals. But Eclipse Spaces suggests something less rigid, in which components which do not necessarily conform to the precise terms of the eclipse.org license, can be informally assembled as personal and individual projects, especially if they come from other repositories outside of eclipse. And since Xdrive is free, this would be a wonderful added service for AOL to provide to the global software community.

I was also delighted to see that Eclipse Spaces is one application of Buckminister’s publishing and materialisation technology for software component assemblies. Henrik Lindberg, Thomas Hallgren and Filip Hrbek are included as the initial set of committers to Eclipse Spaces, all three from Cloudsmith. I’m also delighted to see Malcolm Sparks on the list too, an old IONAian who joined IONA when Ejbhome was acquired in 1999. And Bjorn Freeman-Benson and Ward Cunningham, both from the eclipse foundation. And finally Dennis O’Flynn, the eclipse Corona project lead from Compuware. Looks like a very solid team.

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 ?