So I'm hanging with Euan at work (his, not mine, but I'm working and he's not), and we're talking about the conceptual problem with "solutions." Which is that they're often either impossible or a bad idea, or worse: a good ideal that's almost always a bad idea. And how the ideal of the Ultimate Solution (a terrible synonym for best, ultimate) almost never appreciates what's actually working in the real world, right now, for reasons that can't often be explained, much less justified.

Heading out of Dublin, taking advantage of the much-appreciated free wireless Net access at the airport.

Also feeling much appreciation for Paul O'Malley of Linux.ie, who picked me up and dropped me off every day I was here, and provided plenty of bonus company as well. Today we did Dublin en route to the airport, including my second excellent "fry-up" (a proper Irish breakfast) in two days.

(In which the tale dives at warp speed from the high level generalities of a musing on architectural standards in large IT shops straight into a quotidian morass of network change management and support problems associated with migration from one tool to another to support a function that is of dubious value in the first place...)

True or false? "No one gets fired for buying IBM." This was an IT management truth for decades and it influenced key stages in the systems development life cycle for Fortune 500 companies from the day it was discovered that there actually was a market for mainframe computers to the day it was discovered that somebody ought to drive a stake in the heart of the last remaining System 370 and turn out the lights on the way out the door.

I learn a lot reading blogs, and one place that never fails to inform is JOHO the Blog. This morning the good Doctor Weinberger points us toward an essay by Dan Bricklin regarding the small software company and open source. Dan says, "I'm trying to craft a license that gets as many appropriate benefits as possible from open source, but still brings in money to put food on the table."

The essay is detailed in its discussion of challenges a small software vendor might expect to face when developing an open source product. Dan invites comments.

My company, Sandhill Technologies, is pretty simple:

• One employee (me)
• A partner (she)
• As many bosses as we have contracts outstanding

My contracts tend to be written with companies that are far more elaborate than my own. If it doesn't appear that they are trying to rob me blind, I'm usually willing to go with their boiler-plate terms and conditions. Negotiating with a big legal department costs more than it's worth, I think....

The guys at Cutting Through clearly get what we're up to here, and share some kind words about it. Definitely an allied site.

The guys at Cutting Through clearly get what we're up to here, and about it. Definitely an allied site.

Slides from Beyond the Tornado, the talk I gave at the Linux Desktop Summit, are now up.

This is a journal, and it's not just mine. The way I see it right now, I'm kinda like the bandleader. Benny Goodman, maybe. A guy who plays one instrument among many.

We need other voices here. How we'll make that happen exactly we haven't worked out yet.

Sticking with the band metaphor for a minute, what we're doing here is building a stage, opening a venue, in a place where there are lots of people but too few sounds being raised.

Journals in the IT business have always been paid for by vendors, by the supply side of the market. Much of the coverage has been what I call "vendor sports coverage." The recent Sun deal with Microsoft, for example. Interesting stuff, but not the only stuff.

Ted Leung: In my mind this is a logical next step in the phenomena that Doc's IT Garage is trying to deal with -- reversing the dynamics of the vendor-customer relationship, using open source style (or more neutrally, commons-based peer production) ideas as one of the ways to do that.

My two cents: Open source is too often a red herring, or a conversation sink — even more so since SCO started fudding all over the subject. The key word in Ken's quote above is relationship. With open source, you often have a relationship with a development community as well as with a vendor (if you're a customer) or a customer (if you're a vendor).