In amusing synchronicity, I was reviewing Bernard Golden’s Open Source Maturity Model earlier today. Then I read My Visit to Sun, where he describes a conversation he had with Simon Phipps before giving a talk at Sun.
In particular:
Many enterprises seeem to operate in a vendor-centric model: they select a vendor and from then on rely on the vendor to define when new technologies should be adopted, when new releases should be rolled out, even what complementary technologies should be implemented. It’s obvious that this causes middle-of-the-pack performance, lock-in, and lack of pricing power. Without rehashing all of those arguments, consider the other implication of this approach: it fosters dependence — an inability to self-direct in technology direction, custom architecture, and unique business offerings. If all you can offer is off the standard menu, you will never serve up differentiation.
When you give away software and trade license fees and pre-sales for support contracts and free downloads, you break the passive-adversarial model between vendor and customer that has served IT so poorly for the past two and a half decades.
That’s not a safe thing, nor an easy thing. That’s still a good thing.
In the F/OSS model, doesn't this dependency just migrate from the vendor to the developer? For example, when a regular user downloads a F/OSS application like Apache, they still have some dependencies on the Apache Foundation?
The circumstances of the dependencies may change, but they still exist.
@chris,
No - it's very different : There are bespoke packaged and supported Apache implementations available, so you have the choice - also Linux (and other distributions) allow you to choose between their build or use the Apache (or 3rd party) source or binary.
And that excludes the option of hiring somebody to do some bespoke work for you - something I see a fair ammount of on a wide variety of projects from specific libraries to large applications like Bugzilla.
This means you can choose when to upgrade, what to upgrade to, and what customisations, back-ports, patches, etc to apply.
On high end systems, this really makes a difference, one of my clients has over 200,000 individual active users a week in one country alone, and being able to test and apply patches and changes early makes a substantial difference - we even drive the direction by writing and suggesting patches ourselves.
None of that is possible with traditional closed source unless you have a really close partnership with a small vendor.