My blog has moved!

You should be automatically redirected in 4 seconds. If not, visit
and update your bookmarks.

Monday 20 August 2007

Cloudsmith goes live!

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, 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.


Adrian said...


Speaking as a small farmer's son from the West of Ireland, I loved this analogy. However, working at home a few weeks back with my brother building those things, I suggested to him, wouldn't it be great if we got a concrete pump to fill up all the gaps for better support. Also in IT, my brother thought there might be something to it, as we were both sick of maintaining them. Far from being low maintenance:

* Cattle love to scratch their necks on them
* Wind will knock the stones over
* Ground subsidence will cause them over time to de-stabilise, or create weak spots that you always seem to be building.
* Constant rebuilding causes the stones to become rounded (and that's a big pain!)

So in one sense it got me to thinking of Buckminster. While my initial investigations of it have been very promising, the same problems that stone walls face are also here. I will give you though that cattle can't use Buckminster for scratches, so it's safe there!.

Dependencies that builds rely on can change, and if the meta-data that Cloudsmith maintains goes stale it can cause problems. So for example, there can be some brittleness for me where a cloud can be materialized fine today, but not tomorrow because one of the pieces I depended on has changed.

I see similar problems with Maven where we use SNAPSHOTS and they can disappear at any time (or a new one breaks a build).

I guess this is my slightly meandering way to say that we will still need to provide some means of allowing builds to be concreted, or made permanent. A "release" needs to be materialized at any time, not just today or tomorrow. So a means to say, this "virtual distro" is gonna be "good" and will not become stale because one of its components had a change recently.

Adrian Skehill,

chris horn said...

I’ll pass on experience working with stone walls in Connemara – I’ve been a mere regular visitor there for 27 years, but not frequently worked the land.

Buckminster has a number of facilities to aid dependency changes. The Introduction to Buckminster
and Buckminter specification documents
give the details, but here’s a summary.

A specific, fixed, physical configuration of interdependent components can be given by a bill of materials (BOM). A BOM is auto-generated by Buckminster during resolution and then used during materialization to fetch specific (versioned) components. In addition a BOM can be saved (via the materialization wizard) and then re-submitted at a later date by the same or another user so as to materialize precisely the same set of components, assuming of course that they still exist in the various repositories concerned.

More typically however, (logical) version schemes are used to allow more flexibility during resolution and materialization. Buckminster supports multiple version schemes – OSGi, string, timestamped, triplet – and also an extension point to add further version types.

Version dependency information can be given within CSPECs. Note that CSPECSs – for Eclipse developers at least, at this point in time – are automatically generated by Buckminster during resolution – that is Buckminster uses whatever meta-data is currently available for each resolution/materialization. Thus, per se, Buckminster itself does not maintain meta-data: instead, it converts meta-data “on the fly”, reducing the possibility of the stale meta-data situation which you mention in your comment.

In addition, the auto-generated CSPECs can be manually extended (or extended by a tool outside of Buckminster) with CSPECXs – CSPEC Extensions. A CSPECX can also contain version data (in any of the version schemes..): however since the CSPECX is given to Buckminster by a developer or external tool, it is the responsibility of that developer or external tool to ensure that the CSPECX does not used stale meta-data.

In practice, CSPECs (rather than CSPECXs) are prevalent, and are of course auto-generated.

Finally, Advisor Nodes provide very considerable flexibility to extend the semantics of resolution and materialization.

As an aside, all the Buckminster artifacts I mention above - CSPECs, CSPECXs, etc - are XML files in the format prescribed by the Buckminster specification.

Now: what I have just written, was all about Buckminster (the Eclipse plugin). What about Cloudsmith’s (the web site’s) meta-data ?

Cloudsmith is engineered using Buckminster. Cloudsmith is a place (on the internet) at which Buckminster artifacts – and in particular CQUERYs (each of which is a pre-formatted query identifying a useful collection of components) and RMAPs (each of which identifies a repository on the internet or an intranet) – can be easily found, browsed, searched for, etc. Any dependency information between components is handled by Buckminster (as above) rather than Cloudsmith.

Having said all that, if you chose to go ahead and sign up at Cloudsmith – its completely optional to do so – then if you read the sign up page carefully, you will note that we say “Our policy is that whatever starts off free, stays free. So if we want to find new ways of making money, we have to find new ways of adding value.” I won’t go into details here, but you might imagine some of the optional added value features we have on our roadmap, and for which we intend to charge a modest amount (“We have not decided exactly how much the annual fee will be, but we want users to think it is an incredible value. We can safely say it will be somewhere between €25 and €75, per user, per year.”)

Finally, we are acutely conscious that the “kickstart” sections of the Cloudsmith web site are not yet live: we really do hope to have those available soon. They should hope also clarify and explain how to use Cloudsmith – and its features – even better.

mitch sonies said...


Your comment is very much on point. In the sense of being something we have thought a lot about, rather than not!

Bear in mind that this is an alpha release. If you start playing with Cloudsmith now, by the time your distro changes, you may find that Cloudsmith may be of some help there!

Whether this does anything for the cows, however, I will leave to others...


chris horn said...

The kickstarts are there now...

chris horn said...

initial version at least...improvements on the way..