Here are some notes from the sessions I attended Thursday…
Nick Gall
He had me, then he lost me, and then he had me again. The basic premise was that the of the 4 freedoms of OSS, the “freedom to change” is the one you need to actively architect in to your systems.
The 3 keys to architecting for change are to focus on identifiers, data formats, and protocols and NOT to focus on APIs. Nick had to rush through the last few slides that laid out recommendations such as making every resource a URI and ensuring apps are composable. This would be a good talk to pair up with Web 2.0 concepts.
David Heinemeier Hansson
OK. OK. OK. I’ll learn Ruby and Rails. I get it, greatest thing since sliced bread.
In addition to the 3 main benefits of Ruby/Rails that are always presented (convention over configuration, change is instant, and complete/integrated stack) David stressed that Ruby/Rails tries to NOT be flexible. “Flexibility is overrated. Flexibility is not free.” This is basically the paradox of choice argument but it is interesting to think about intentionally setting out to design an inflexible language. It would seem to me that you could take an overly-flexible language and constrain it easier than you could take an inflexible one and open it up. So that would suggest that Java could become more Ruby/Rails-like but not the opposite. I guess time will tell.
Katrik Subbarao
Katrik used an extended metaphor of Water/Earth to “clarify” what OSS is. Water is transparent and fills the gaps between the solid, non-transparent solids. This was somewhat entertaining but the problem with metaphors is that they are just metaphors and they break down too easily. This presentation would probably most useful to an audience who was new to OSSS and had never considered mixing OSS and Commercial software. Katrik did do a great job however in not giving a vendor pitch for HP.
Robert Lang
I had no idea that origami had progessed to this level. Check out his work
Calculating ROI – R0ml
R0ml kicked off with the assertion that ROI studies aren’t real. Everyone says they do them but few can produce the numbers. To get real numbers is prohibitively expensive, but industry average numbers can spin the story either way (ie for or against using OSS). In the end, there are 5-6 ways to tell the ROI story (hardware savings, license cost savings, etc) and it is best to just pick one rather combining the calculated ROI of each.
Ruby for Java developers
I got boxed out of this one. The door-attendant said it filled up immediately. Drats.
Geronimo
Geronimo M4 should be out this week which will be nice. The M3 release was over 7 months ago and I’ve never been able to successfully build from the HEAD. I was suprised at how raw the admin console pages are but the GBean management stuff seems very consistent and well thought out.
OpenBRR
The folks (SpikeSource, OReilly, CMU) behind the Business Readiness Rating explained the framework and how they see it being used. The audience seemed pretty positive on the idea. One of my concerns about these types of ratings systems is that it is hard to have a single rating that covers differnt types of software such as end-user vs developer frameworks. With the BRR, it appears the framework is flexible enough to allow it to support both types.
One good question from the audience was regarding whether or not companies could get sued for publishing the BRR ratings they did on a project/product. I suppose this is just as likely as getting sued for any message you post on a blog/message-board.