David Bolton Strikes Again

redhat Open Source Symposium 2006

The redhat Open Source Symposium was an opportunity to see redhat’s take on open source software and what it meant for the enterprise. With that in mind I was keen to get along, not only to see the presentations but to gauge what other attendees were there for.

The attendance was reasonably good — I’d say there must have been about 200 people in all. From the dozen or so people I spoke to, there was a an emphasis on technical infrastructure staff, and “IT managers” (again with an infrastructure focus). There didn’t seem to be much of a developer representation at all, it really did have a “Linux” feel.

In terms of technology, the main themes for the day were Service Oriented Architecture and Virtualisation. I’m familiar enough with virutalisation and while I guess I could always learn more, its not where we make our money so I focused on the SOA sessions. The key points from the SOA sessions were that an SOA approach allows flexibility, and helps avoid the costs of major architecture surgery (CORBA was mentioned more than once).

From a business perspective, they were hammering Total Cost of Ownership and vendor-lock in. Probably the most pertinent point here that we can use when talking to clients is that to use proven open source is no longer a risk — in fact it could be more of a risk to use a proprietary option. When combined with lower barriers to entry (from a pure cost perspective) open source can make a compelling business case. What typically lets down the open source world is the complexity of the tools, and I’m not convinced yet that the management tools of JBoss (acquired by redhat recently) are any easier to use than last time I checked.

The best presenters were Bruce Badger, President of OpenSkills, Simon Spencer from NAB, and Brad Murdoch, VP of International Operations with JBoss. As engaging as Bruce was, he was explaining open source software to a crowd that largely understood the benefits, so there wasn’t much to be learnt there. Simon’s experiences and advice in moving a “risk averse” organisation like NAB onto an open source platform was great to hear, and if I had to take one thing away, it was that an idea is nothing without incubation and execution, and that a fully formed process is needed to take it from concept to production. Brad was perhaps the most polished speaker – his talk on SOA covered a lot of ground, but its key points were as mentioned above: avoid lock in and reassign the savings.

Now in terms of attendees, I think I spoke to more people who were actively using Linux than those who were looking to make the leap. And I’d tried to focus on meeting business people, the ones I was avoiding seemed to be the hardcore hardware guys, who were interested mostly in virtualisation, and were no doubt even more Linux au-fait.
Anyway, not a bad change from the regular day, and with a couple of lessons in how to approach potential customers with the open source message.

Found in Renaud Wildura’s excellent guide to the use of Java’s final keyword, a quote from Design Patterns:

Aggregation implies that one object owns or is responsible for another object. Generally we speak of an object having or being part of another object. Aggregation implies that an aggregate object and its owner have identical lifetimes.

Acquaintance implies that an object merely knows of another object. Sometimes acquaintance is called “association” or the “using” relationship. Acquainted objects may request operations of each other, but they aren’t responsible for each other. Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects.

It’s easy to confuse aggregation and acquaintance, because they are often implemented in the same way. Ultimately, acquaintance and aggregation are determined more by intent than by explicit language mechanisms. Aggregation relationships tend to be fewer and more permanent than acquaintance. Acquaintance, in contrast, are made and remade more frequently, sometimes existing only for the duration of an operation. Acquaintances are more dynamic as well, making them more difficult to discern in the source code.