Category: Four pillars

There’s a strange kernel to this post. Recently I posted something about Agile error messages, and Kevin Marks, while talking to me about it, took me on a tangential journey to a post at chuqui 3.0, headlined Why Do Businesses Shy Away From Open Source? [If you have the time, take a wander round Chuqui. Chuq van Rospach seems an interesting guy; and any blog with a tagline saying “And I’ll keep reinventing myself until I get it right” has got to be worth a read. Thanks for the heads-up, Kevin].

Here are a few quotes from the Chuq post:

• Open source requires you, as a manager of IT, or as a staffer, or as the CIO, to be willing to commit to being responsible for fixing a problem, and therefore, be responsible for the problem itself.
• The support contract is not about fixing the problem. The support contract is about allowing you to shift responsibility for the problem. It is the tool that allows you to go (as the IT person, manager or organization) to the customer, or your manager, or the CIO, or the VP of whatever organization is pissed at you for the problem, and say “we’re doing everything I can, but we can’t fix it until we hear back from the vendor”.

And that got me thinking hard about the importance of accountability. I’ve always felt that rights come with duties, power with vulnerability, empowerment with responsibility. Something to do with my upbringing, I guess. There’s nothing original about it, it’s been half a century since Peter Drucker maintained that organisational change was about accountability, not empowerment. Which is why organisations find it so hard to change; many “organisation men” learn to survive by wearing Teflon, nothing ever sticks. Empowerment without accountability. A very dangerous combination.

I’d never considered the possibility that people would try and patent software; the Drucker reader in me couldn’t see how anyone could claim the rights of “patent” without the duties of “fit-for-purpose”. Unless the software always did what it was supposed to do, and unless you could sue for damages when it didn’t, I couldn’t see software as patentable. Rights without duties. Dangerous.
While thinking about all this, I recalled a seminal article on the subject by Helen Nissenbaum over a decade ago, well worth a read. [I managed to find the reference, but it’s hidden behind a paywall. An ACM paywall. Oh well. You can find the abstract here, and if you have an ACM account, you can get to the whole thing via the same link. Incidentally, Nissenbaum, who used to be at Princeton, is now at NYU and writes some very interesting stuff on trust and identity].

Nissenbaum argued that computers were actually removing accountability, and wrote eloquently about the unfairness of rights and ownership without liability or responsibility. I didn’t agree with every detail in her arguments, particularly when she seemed to assert that collaboration and teamwork reduces accountability. But what she said stuck with me.

And it was only years later that I realised she was right. The way we used to work, in vendor-lock-in worlds, did remove accountability. But it wasn’t the teamwork that did it, it was the vendor-lock. IT departments tended to shift responsibility (and blame) to the vendor, because they could. In fact sometimes they had no choice and felt cool about it, a weird variant of Stockholm Syndrome.

In an opensource world there’s no place to hide. You take responsibility. You’re naked in front of your peers. And you behave responsibly because of that peer pressure, aided and abetted by the motivation you get from peer respect and recognition.

So maybe there’s something about opensource I’d never considered before:

• I’d bought the Given Enough Eyeballs All Bugs Are Shallow argument
• I could touch the value of Free as in Freedom 
• I could see the democratised innovation and emergence and serendipity payoffs
• I’d understood the function flexing and future-proofing and cycle time advantages.
• I could work out the “outsource your maintenance costs” value.
• I could even appreciate the “you attract talent because of open source, not with it” benefit.

But I’d never considered the Opensource Makes You Responsible concept.

Until I’d read Chuqui’s post. [Thanks, Chuq]

Unless we feel responsible and accountable, we don’t build Right First Time. Unless we feel responsible and accountable, we don’t consider the Customer Experience. Unless we do that, there is no emotional asset transfer. And business (as Drucker so beautifully put it) is about attracting and retaining customers, nothing else.
So become responsible. Use opensource. Not just as a tool or an enabler, but as a mindset. 

Continue reading “Opensource makes you Responsible”

I’ve been watching news about IE7 quite closely, with a lot more interest than I’d had in prior upgrades. Trying to figure out what Microsoft will do to make up for lost time, something they’ve been able to do reasonably often. Intrigued by the Ozzie factor. Who wouldn’t be?
It was in that frame of mind that I came across Chris Messina’s recent post on the subject; thanks, Chris!. And as I read through it, I noticed Chris’s comment on View Source and followed the link to the Release Notes.

I wasn’t too bothered to find out that Windows SharePoint Server cannot import Excel spreadsheets while IE7 is running; my attitude to Excel is probably such that I consider the inability to import spreadsheets a selling feature.

But no more View Source? Why? This doesn’t feel right to me. Definitely not a feature.
I think it was Paul Graham who first wrote about the value of View Source, how it allowed the curious to enjoy that “So that’s how they did it” moment. How it helped innovation. And now we have this.

Can’t help but feel that there are more “unintended” consequences to come.

Oh well.

Update:I was wrong. As the comments show, it would appear that View Source itself is not disabled, just the back-door approach to using it. That’s what happens when you critique words rather than real functions. Mea culpa.

I’ve just heard from Julie Meyer that Richard Duvall, the founder of Zopa, passed away earlier this week.

I met Richard for the first some years ago, while he was at Egg; more recently, via Julie, we met a few times while he was busy dreaming up Zopa, getting it funded and launching it.

Earlier this year we were both on the same small panel at Ariadne’s 5th Anniversary celebration, looking at Building Society For the 21st Century. In fact the kernel for this blog was written for that occasion.

Richard was one of the people who really got the power of the Web and P2P, and followed his dreams with his inimitable boundless energy. He didn’t just follow his dreams, he made them happen. Effervescent and charming, he was a pleasure to be with.

It’s normal to feel sad when someone close to you passes away. I didn’t know Richard that well, yet I feel really sad. That was the kind of guy Richard was. My condolences to those he leaves behind.

Bruce Schneier has written an interesting piece on how form follows function in any architecture, be it physical or electronic. My thanks to Kevin for pointing it out to me, and to Cory for making sure I didn’t forget about it …. I’ve been rushed off my feet lately….

Schneier’s arguments are simple, brought to life with eloquent examples and anecdotes:

• [Security-driven] changes were expensive. The problem is that architecture tends toward permanence, while security threats change much faster. Something that seemed a good idea when a building was designed might make little sense a century — or even a decade — later. But by then it’s hard to undo those architectural decisions.
• The same thing can be seen in cyberspace as well. In his book, Code and Other Laws of Cyberspace, Lawrence Lessig describes how decisions about technological infrastructure — the architecture of the internet — become embedded and then impracticable to change. Whether it’s technologies to prevent file copying, limit anonymity, record our digital habits for later investigation or reduce interoperability and strengthen monopoly positions, once technologies based on these security concerns become standard it will take decades to undo them.
• It’s dangerously shortsighted to make architectural decisions based on the threat of the moment without regard to the long-term consequences of those decisions.

All this made me think of the QWERTY keyboard. I grew up in a journalist family, with typewriters (the old Remington heavy-enought-to-give-you-a-hernia kind) outnumbering flowerpots at home. And when I first visited our printing press (I must have been nine at the time) I was quite surprised to see an ETAOIN SHRDLU keyboard. And my father explained to me that the QWERTY layout was designed to ensure that adjacent typebars didn’t jam, by separating high-frequency letters; that the layout had the additional “benefit” of slowing typing speeds down as a result. The linotype keyboard, on the other hand, was designed for speed, and therefore followed letter frequency distributions.

Form follows function. Just look how long QWERTY’s lasted. [An aside: It’s always amused me that the longest word you can form using the letters of the first line of the QWERTY keyboard is …. TYPEWRITER. What an unintended consequence. or was it? Maybe Grassy Knoll designed it]

We live in a world of many many cyber threats, some real, many perceived. I like the points that Schneier and Lessig make, particularly the pace-of-change one. There is always a temptation to take corrective action against security threats, both real and perceived; it is best to avoid that temptation altogether; but if we do give in, what we must ensure is that the corrective actions we take are designed to be as temporary as the threats; that we take care to make the response easily reversible, dismantlable, removable.

Imagine what would have happened if the recent ban on liquids on airplanes was enacted as law. Stupider things have been known to happen. In fact some part of me is actually surprised that the No Liquids rule didn’t become law.

Imagine what we’ve been doing to ourselves in building walls around our own information, within our own information. Actually paying people to build the walls, then paying people to drill through them, then paying people to fill the holes in…..

Now they know how many holes it takes to fill the Albert Hall.

Let’s keep those paths unpolluted.

For most of my adult life, I’ve been bemused, perplexed, sometimes irritated and occasionally completely taken aback by the error messages spewed out by the applications we build and use. Over the last twenty-five years or so, I’ve watched them improve, but at speeds that make glaciers look agile.

Today, while looking at technorati, I saw this:

Something is wrong! We know about it, and are working furiously to fix it. Please check back later and probably everything will be back up and running.

Great stuff. You may not think it’s perfect, given that it doesn’t actually say how long it will take to get fixed. But I like it. It is open, conversational, simple, honest and brief. I tend to think that the uncertainty implied in the message is actually a good thing; it made me think … could we expect to see error messages that are Agile in nature, improving by iteration as better information emerges/is discovered?

Who knows, this may be a leading indicator of the paradigm shift taking place in the applications and services space today.
My thanks to all at Technorati.