Packages simply too big

The competent computer user, on unix at least, back in the day, knew how to write his own shell and other small language scripts (reason why AWK exists, for example). Nowadays, the cultural imperative for "no education" and "clickibunti" means that your warm bodies are essentially glorified keyboard peckers and mouse movers, and capable of packing up their own repetetive tasks and have the machine repeat them for them, they are not so much.

This is why you have a toolsmith, or "systems programmer" in IBM lingo: His job is to come up and package solutions for tasks to speed them up, bind together organisational knowledge and when done properly, document the quirks and warts as well as the environment where and why it was needed.

The "packaged application" idea is to gather all that, add special corporate "integration" sauce, and sell it. Mucho profit in a booming market to be sure. But installing those things --so many bells and whistles and modules vaguely aimed at various types of businesses, they are the very definition of software bloat-- requires basically your old system programmer again. Only this time in the form of a gaggle of Highly Paid Consultants. So, they're self-defeating. I don't really see how virtualisation and outsourcing right up into the cloudy sky helps to "flexibilise" that. It's fancier ways to throw more cycles at the problem, not a solution that capitalises on the strenghts of both mechanical computing and human effort.

That very bloat is why free software has a good chance to win big, though: Those scratch-an-itch things tend to do one thing well (and if not someone else'll come up with a better, meaner, leaner solution) and for their other needs have to lean on other solutions. So, open source software needs to play well with others. Add ye olde toolsmith to bend the iron to a shape suitable for local consumption, and Bob's yer uncle.

If corporate and proprietary is to survive it'll have to learn how to play well with others. We might see that in order to do that such corporations choose the easier, less sue-thy-neighbour and more long term route, and go open source with an updated business model to match.

The virtual pint because if I wasn't so broke I'd donate a real one to my own beer fund.

A way to go

I've been working in desktop estate management for a while now, and amongst the many lessons that I have learnt, the one that stands out the most is beware of the proprietary.

Thick or thin client, big or small, these are the applications around which you need to exercise the most caution as they are the most likely to break as the desktop environment changes around them, and the least likely to adapt quickly to said changes.

Unfortunately, as you have rightly pointed out in this article, desktop envrionmental change is becoming faster, and more prolific. Thin client, or web-based software was supposed to be the answer to this, but from what we've seen, has fallen into exactly the same traps that have besieged the traditional software development cycle.

The evidence for this is can be witnessed in the browser usage statistics. The only reason IE6 still dominates the stats is because there are so many corporations whose hands have been tied by web based apps/intranets which have not, or possibly even cannot be updated to use modern browsers.

But this is the primary internet facing component of your operating system. From a security perspective, do you really want it to be stuck in a timewarp? Can you really afford to sit on critical security updates while you wait for your web app suppliers dev cycle to catch up?

We are currently holding off IE8 deployment because one of our primary web-app suppliers is soon switching from SAP to Oracle, and doesn't consider work on the current system to be 'economically viable'.

So, all the disadvantages of the traditional software cycle, with the added stone dragging your browser into the dark ages too?

The real irony is that traditional software has steadily become easier to manage. There are a miriad of solutions out there, allowing you to keep on top of your software suites, all the way from SCCM through to the lighter/cheaper solutions, and any mid to large environment will already have such solutions well established.

Even the the primary benefit originally touted, that of a single point of update has backfired in this new age of global enterprise. It's all very well being able to take one machine (or cluster of machines) offline to update them, but if that machine is serving clients around the world, one man's night, is another mans peak usage hours.

With fat client management software on the other hand, maintenance hours can be scheduled and staggered around the globe.

Finally, all these applications are built on a very immature and rapidly changing environment, with little sign of it stabalising in the near to mid fututre. The recent revelations pertaining to googles rather gun-ho attitutde over security in the HTML5 standard should give any web app developer pause for thought.

Web apps are already plagued with issues from cross-browser compatibility, 3rd party plugin dependencies, security restrictions, security certificate/dns routing, bandwidth, offline/disconnection, security of your data 'in the cloud'...

For these reasons, the web is not the idyllic solution portrayed by sales-speak evangelists, and really should be considered only as a solution if your exsisting product is suffering explicitly because its' client is of the lardy variety, not because your marketing department can break open a fresh box of buzz-words.