There’s a great post over at the Creating Passionate Users blog about the Knowledge hierachy. I’m going to gratuitously steal the pictures (which are Attribution-Non-Commercial licenced so I’m OK)

I think in advocacy we as a community, and me in particular, have a tendency to get stuck in the Data, Information, and Knowledge levels. We’re constantly bombarding people with facts about FOSS. Who’s adoping it (Hey Google is built on FOSS), how much faster / leaner it is (Samba can handle 8x as many clients on the same hardware), how many companies rely on it (70% of the web is delivered on Apache), but we could all do with some reminding to help people develop Understanding and Wisdom – something I need to develop in myself before I start on other people.

Being arrogant I think I understand FOSS development, community, and technology pretty well, and feel OK trying to pass on that knowledge to other people. Being humble I definately need to work on the wisdom, or the bit in parenthesis: systems thinking. I think this is a pretty powerful angle for advocacy that may not involve much talking about FOSS.

Most people are using proprietary software don’t do so on the basis of taking in a load of Information and Knowledge and developing a clear Understanding of the differences and pros and cons of Proprietary v. FOSS and then deriving a reational, clearly thought out decision that Proprietary is best. They use and end up getting locked up in proprietary solutions because that’s the model of thinking that we all end up getting trapped in; by the vendors, the marketing, the press, our experience, and a sea of Data, Information, and Knowledge.

I love a Windows v. Linux v. Mac OS X v. Solaris debate just as much as the next Linux loving advocate but we have to realise that it’s totally irrelevant. IT strategy driven by OS choice is ridiculous – it’s like letting the design of a building be defined by your choice of concrete for the foundation – instead, I think, most architects design the building first then pick the best concrete in terms of price, performance, environmental impact, or even colour. But they don’t start with the concrete, the door handles or the carpet.

If we have confidence in FOSS as good solutions to IT problems then we can feel confident advocating sensible systems level thinking knowing that open source solutions naturally fit in. To get to that kind of systems level thinking we need to break out of the arguments that we get guided into by the architecture of the past. The only beneficiary in a Windows v. Linux debate is Microsoft because it implicitly re-enforces the wrong thinking that operating system choice is important, or needs to be the root decision in an IT strategy.

It will require changing the way round we think about things. For a non-IT example, listen to this clip from the Clean Products Panel at the Bridging the Gap Conference. To summerise;

• GM used to buy bucketloads of chemical from a wide variety of vendors and (badly) manage the chemicals themselves. Their vendors profit motive is ‘How do we sell more chemicals to GM’
• GM eventually turned this around and said to a chemical company, you manage and be responsible for all the chemicals from the minute they come onto site, to the minute they leave, and we’ll pay you $X per car we produce. Now the profit motive is how can we use less chemicals, and how can we be more efficient.
• Results in a 30% reduction in chemical use and a 30% savings for GM.

This change wasn’t acheived by comparing one chemical to another, or one storage container to another, but by changing the procurement system to encourage the results they desire.

Architecting an IT system where client OS choice is irrelevant is probably going to be difficult but it’s going to force you into some decisions that will pay back big in the long term. Like being able to hold you OS vendor to ransom rather than the other way around (or just getting rid of the idea of OS vendor all together – spend the money on stuff that’s important instead).

I haven’t yet done enough thinking on this level to know what are the key tatics in this approach, or what even some of the key points to keep in mind are. There are some I can think of;

• small pieces loosely joined
• open standards and protocols (or at least something with an open implementation)
• look at the problem first not the (potential) solutions
• simplify
• agile development

These are just catchphrases or barely sketched out half ideas in my head, but this is the wisdom I seek, and hope to pass on in my advocacy.