Taking charge of your own destiny
Scoble has posted 12 reasons that Web 2.0 entrepreneurs are steering clear of the Microsoft platform. It’s an interesting list (the comments are full of treats too) but for me it misses the key reason that open source development tools are so compelling: they put you in charge of your own destiny.
Allow me to elaborate.
As developers, our lives revolve around abstractions. The key activity when programming is designing and using abstractions—we weave them together to create new ones, with our target being an abstraction that lets our users achieve their goals.
The problem with abstractions is that they leak. The taller the stack of abstractions (browsers on templates on Django on mod_python on Apache on Linux on hardware on a network) the more components there are that can go wrong. When they do go wrong, we need to work out why and find a solution.
If your development stack includes closed source components, there’s a limit on how far you can dig. Run in to a bug is the underlying platform (or an undocumented feature or just something you don’t understand) and you are left at the mercy of your vendor. You only control the top part of your system.
Contrast this with open source. If some part of your stack breaks, you have a bunch of possibilities:
- Go to the project’s bug tracker and seek a solution there.
- Work out the cause of the problem and fix it yourself.
- Hire someone else to fix it for you.
Proprietary software vendors may offer paid support options, or even give you access to their bug tracker (if you pay them enough). But if they let you down there’s nowhere else to turn. With open source there’s always something else for you to try.
There are a great deal of other advantages to developing on top of open source, but to my mind the ability to completely understand and control the abstractions that form your building blocks is the most important of them all. Unfortunately for Microsoft, it’s also the one that is hardest for them to duplicate.
Another option (in some cases) when part of your stack breaks: replace it.
Granted, this isn't always an option, but it probably is much more often with open source than it is with proprietary products. Look at how many conversion utilities are available out there...
Dougal Campbell - 1st November 2005 22:14 - #
Developing the wikipedia stats thing on django+wsgi+pydb+mysql+ubuntu is my first experience in which the whole stack was open. Every bit of my prior dev has been firewalled to a greater of lesser extent.
Last week, I was, in fact, just commenting to a coworker that this was a clarifying experience for me. Though you might prefer not to get into the guts of the DB backend for your favorite webdev framework, having it as an option is incredibly liberating.
A few years ago, it dawned on me that it is a simple matter of time before CIOs are at risk of failing their feduciary duty in selecting proprietary systems when it is not necessary. At the time it seemed far off. Now, I'd place it at about 2 years.
Long bet?
Jeremy Dunck - 1st November 2005 22:19 - #
Simon Willison - 1st November 2005 22:26 - #
Robert Lyons - 2nd November 2005 02:23 - #
Organizations which are cash-sensitive have an interest in exploring free options. In terms of talent pool and initial learning curve, it's likely that doing your first Python GUI will be more expensive in the short term. But the pool is growing, and the learning curve is a diminishing cost.
On the other hand, if you want to take advantage of high-end features (of a platform, of a library, whatever), you generally sacrifice other choices. I find, though, that most IT shops overestimate their position on the continuum of rich versus reach.
All of that points to two situations in which you can introduce alternatives. Low-risk/cost pilot, and the-ship's-sinking-and-you-must-save-us. No matter how risk averse an organization is, high risk is justifiable when the alternative is certain failure.
With projects failing at 40% and IT orgs tethered to consultantware, you should get a chance some time soon. ;)
Jeremy Dunck - 2nd November 2005 04:22 - #
It's not just Microsoft. I think the LAMP stack beats the MS Stack at most levels.
I have the dubious pleasure of working with Oracle DB and various Java app servers. Now we have some big customers, they won't run their business critical stuff on anything else. I think the driving factor that you can't avoid is that age old one - "No one who bought IBM got fired".
If Oracle screws up, your DBA is on Metalink hunting for the cause of the problem, or on the phone sorting out the fix. With an SLA in place who's to blame? Oracle. Who fixes it? Oracle. When the C level exec explains 0.5 days lost revenue to the shareholders they go "Ohh right, Oracle, unavoidable, but fixed quickly, good job".
If PostgreSQL screws up, your DBA is on the PostgreSQL mailing list archives, trawling. He can't find the problem so he calls up your prefered PostgreSQL support company. They then find the bug in the source and send you a patch, and tell you how to fix it. When the C level exec explains to the shareholders why they lost 0.5 days revenue he mumbles something about database and Whassicalled consulting, and the shareholders go "Ohh, right, dodgy software, why aren't they using Oracle or Microsoft, who are Whassicalled Consulting... they only have 5 employees!!!!!".
This isn't good. This is what has to change first. Google and Yahoo! help somewhat, but they are different. They aren't an international power company, or telecoms company, or supermarket...
(It's late, I'm not sure what I am trying to say so I will stop the rambling there!)
Mark S - 4th November 2005 00:11 - #
I work for a small telecommunications (cable TV, high speed data, telephones ) company and we run most of our operations off of Linux, Apache, mod_perl, and PostgreSQL ( aka the OTHER LAMP ). While I agree that some people hear <insert unfamiliar software package here> and freak out, their fears are usually put to rest when you show some real world examples that are big. For example the .org and .info TLD registries are run off of PostgreSQL databases. The company that won the bid for those was the only company running PostgreSQL and the only one not suggesting Oracle or DB2. If it's trustworthy enough for that I think most C level exec would be ok with it.
P.S. I've been running multiple PostgreSQL databases 24/7 for going on 7 years now and I've never had it "screw up". Now I have screwed it up, but it was always my fault. :)
Frank Wiles - 4th November 2005 18:24 - #