Humour me and come along for a slight detour.
In a recent post, I tried to connect up TheManInTheDoorway with Ed Byrne and Hugh Macleod, emphasising the need to de-commoditise. And today I came across this in Aqualung. DefDiff or the Definition-Differentiation model.
Now the debate really intrigues me, and will influence how I write the Foundation and Empire piece. Because thereâ€™s something I donâ€™t understand. Thatâ€™s when I can learn something.
Why do we need a model thatÂ helps us throw away internally built components and replace them with externally sourced ones, as a means of moving from differentiation to commodity? Why should we worry about the â€œlegacyâ€ constraints of existing APIs and formats?
Iâ€™m not questioning the process. Iâ€™m questioning the need for a new model. I think we already have a valid model.
Itâ€™s called opensource. I have always believed that opensource should never be about deep differentiation, in fact that opensource works best when the problem being solved is shared by many. WhenÂ the problemÂ is a commodity.
Maybe itâ€™s me thatâ€™s warped. I want to commoditise the problem. Then the solution must of course be commoditised.
Once people realise that opensource is the new outsource (yes I know Iâ€™ve said it before, but so what?) then this becomes easier to grasp. [An aside: Wouldnâ€™t you just love to go to your boss and say youâ€™ve outsourced 50,000 part-time jobs s/he never knew you had?]
Platform and device and UI/browser independence come as standard when you buy opensource. So you donâ€™t worry about legacy conflict, provided you have the right principles in place in the first place.
You know, sometimes I think we can rewrite enterprise IT strategy to just one line:
Make it demonstrably easier to consume opensource day after day.
You get the ability to throw away the commoditised. You get to lower maintenance costs on the soon-to-be-commoditised. If someone else gets there first your costs of acquisition are lower. You can keep concentrating on that which differentiates you.
Which leads to an interesting corollary: Only keep the problems that are unique to you. Thatâ€™s a whole new subject in itself.
More later. In the meantime, Malc, Ric, thanks for taking me somewhere else in my quest for the Foundations.
Opinions, comments and flames welcome. Almost requested.
One thought on “Four Pillars: Preparing the Foundations: On opensource”
I wonder if, to understand the impact of OpenSource on IT Construction industry, it is also important to understand how the human motivation behind the growth of open source interplays with the human motivation behind the growth of IT Construction industry.
The challenge in the enterprise strategy would be not just to enable the consumption of open source(inward looking) but also the creation of open source(outward looking) which could ostensibly be acheived by aligning these human motivations something extended enterprise communities do very effectively. The Official Blogosphere.
I choose to use the words human and not economic motivation for that is the precursor to economic motivation.
Your thoughts requested.