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.Â
I think you also need to consider trust in this very large equation. Organisations will transfer responsibility to consultants to remove responsibility – but I wouldn’t say they trust them. They transfer responsibility, of course, to transfer the blame – that is the trade.
With opensource you need to transfer trust outside of the organisation to a group of people you can’t see and rarely meet. The prime issue here is, I think, that an organisation retains responsibility for fixing its own pain points within opensource (perceived good) but has to trust the community not to insert new pain points essentially beyond its control and most possibly beyond its own testing capability. There are new bugs in Linux in what an organisation should be able to consider solid parts of the system beyond the need for testing.
I agree. And that is why enterprises need the services of a new breed of intermediary, providing testing and certification services for a given hybrid stack. Paid for.freedom not gratis.
You have to do this in a way where you remain accountable for the customer experience, rather than by creating another route to abdication.
Is the responsibility about the support contract or the freedom to second source?
If you’re in charge of Facilities, and the COO complains about the trash cans filling up and stinking up the place, you can’t blame the janitorial service — even though you have a contract with them that says the service, not you, will empty the trash. That’s because you have the freedom to switch to a “compatible” service that can empty the same trash cans. If you’re using proprietary software, you can point at the EULA to prove there is no second source.
If you have a RHAT support contract, in theory you should be able to call Progeny and get a compatible build of the same software with Progeny support. Does RHAT hold the market share it does because the technical costs of switching are too high, or because the threat of a second source makes them offer higher quality support?
The provider of the end-to-end service must retain responsibility and accountability for the experience. You buy a car, not headlights and axles and carburettors.
This provider, in Malcolm’s example, is an inhouse IT department. It need not have been….It could have been an ICT provider like the one I work for.
When the provider contracts in services and creates an experience as a result, the responsibility stays with the provider, the “prime contractor”. And a good provider will have built in substitution plans, taking out supplier A and replacing with supplier B when required.
Usually the threat is stronger than the move. But, in order to have a threat, there must be substitutability. Not lock-in.
I prefer to think that RHAT works well because of second-source threats, but it’s been a while since I looked at them closely.
Another aspect of open source is a wider choice, if not in all, in some fields. One cannot make a choice without finding their own requirements and secondly whether the tool can satisfy those requirements or not. Usually lack in this research or information digging results in unaccountability, as one cannot justify selection of the tool for the job.
Authenticity is a word on everyone’s lips in the internet world these days and it seems to me that the genuineness implied in that captures the notions you describe here. You can’t be authentic if you have donned a teflon coat.
I may be an optimist, but I am starting to believe that the world may be changing. That simple notion of doing good work follows from everything I am talking about here and could be the cultural foundation for a long period of prosperity during the internet age.
Nic, software has been a special case for too long. The delivery manager can’t blame a broken truck because he or she could rent a truck and get the stuff delivered. The advertising manager can’t blame the newspaper because the company could always put its ads on a billboard or Google or something. The peculiar lock-in terms of software contracts are contrary to the way everyone else in the company is expected to work.
So it’s not so much that the world is changing, it’s that software — thanks to open source licenses that put the customer and the vendor into a fair balance of power — is growing up as an industry to take on the same level of responsibility and accountability that every other product or service has.
And not a minute too soon. It’s been a long time coming.