Tightening the bolts on open source

Today, I assembled a second typing chair for my office. Not much of a column opening, I grant you, but stick with me, it gets better.

On the underside of the seat was a notice that gave a dire warning about serious injury if the chair was not assembled correctly and said I should "check and retighten all bolts and parts at least every three months."

Now I don't know about you, but I have never included my office chairs on my routine maintenance schedule.

I suppose chair maintenance makes sense but only if one is concerned that an untightened chair could be a risk to life or limb, which counts me out.

I imagine there are people who routinely check the tightness of the bolts on their chairs - people who gingerly sit down and tentatively wiggle their bottoms to test if the chair is about to spontaneously disassemble. I am not one of those people.

Now this led me to thinking about open source software. "Why?" you might wonder. Ah, because the whole problem of maintenance and management seems to be a central issue in the argument over open vs. closed source software.

With closed source software, we've come to rely on vendors telling us about upgrades and patches, a service we like because we feel it reduces our workload. We let the antivirus subsystems autoupdate themselves, and, of course, we let Microsoft Corp. tell us what updates are available for selected Windows components. But beyond that, it is all a bit, well, slapdash in the closed source world.

Let me digress to note that even if you don't want Windows Media Player to be updated to the dreaded Version 9 through the Microsoft Update service, you can't tell it not to offer you that update again. No, Microsoft knows what is best for you - a consequence of our wanting the vendor to hold our hand.

Anyway, people who don't believe in the value of open source point out that open source providers have no interest in telling you about fixes, patches and updates, or in creating fixes and patches in a timely manner. I contend the flow of information about open source problems is no worse than in the closed source world.

I know many of you have had serious problems with just about every type and level of proprietary software available. Above and beyond the usual gripes, the real problems range from the vendors not admitting to problems and not informing users of known problems to being way too slow to fix the code even when the problem is admitted to and widely circulated.

What I hear from open source users is, well, nothing like that. It seems that by committing to open source, you also commit to a greater level of self-reliance. What it comes down to is that, if you are serious about your IT infrastructure and you use open source, you have to know more about the software and must be willing to spend on training.

However, proprietary software has a few advantages - the documentation might be more readable (although not necessarily more thorough), you sometimes can get solutions running with less effort, and premium support and service might be available.

When you add it all up, the costs of open source and proprietary software might be the same, just distributed differently. It's just another example of the old axiom "There's no such thing as a free lunch."

The choice between open source and proprietary software is a trade-off and a gamble. The trade-off is all about whether you get better value, service and support from commercial closed source vendors as compared with that from the developers and the community that surround open source projects. The gamble is whether you'll be right when things go wrong. So, which are you betting on?

Now excuse me, I must go and plan my chair bolt-tightening schedule.

Join the newsletter!

Or

Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about Microsoft

Show Comments
[]