October 28, 1996
The Trouble with Components, Part Two
By Bob O'Donnell
Some issues just refuse to die and I think component software is going to be one of
them. Several weeks back I wrote a column on the industry's move to component software
models and questioned whether this was really a step forward for IS managers and users.
[See Plugged
In, Sept. 16.] Among the points I argued was that component software could lead to an
administrative nightmare for IS managers trying to maintain some sense of order over their
companies' desktops as well as for adventurous users eager to soup up their machines.
I apparently touched a tender nerve with the subject because I received a barrage of
e-mail and found that the column was even picked up by one of our online news rivals, News.com. The responses I received were split: Many agreed
with my points, but several others argued that component software is meant for programmers
only and that it's not intended for end-users. As a result, they said, the support and
other maintenance issues I discussed would not be a problem - in essence, programmers
could handle them. A few also pointed out, and rightly so, that there has been and will
continue to be a significant market for reusable software objects that programmers can
essentially buy from each other and use in their respective programming tasks -
particularly for custom, in-house programming projects.
But it seems that different segments of the industry have different definitions of what
component software really is. Apple and the LiveObjects (nee OpenDoc) gang, for example,
have been touting end-user customization and component software usage for several years
now. And with the rapid growth of the Navigator and Explorer platforms, an entire cottage
industry is developing to create Netscape plug-ins, ActiveX controls, and Java applets
that users can freely add to their browsers/operating systems. This is precisely what
component software devotees have described for years.
My response to this notion of end-user component software usage again is, who's really
going to guarantee interoperability among all these software parts? Who's going to
maintain the file formats? Who's going to support all the millions of permutations when
some of them don't work (and some definitely won't)? And, finally, how is anyone going to
be able to manage all of this, either as an individual or on a company-wide basis?
I know that there are organizations developing standards that are supposed to make
everything work together perfectly, but are they going to take your support calls when two
of your components won't work together and each of the respective vendors blames the
other, or potentially the browser platform you're working on? I don't think so.
Frankly, just thinking about the issue is almost enough to want to make me go out and
buy some network computers (NCs) so that I don't have to worry about everything working
together. And in fact, if component software implementations prove as messy as I think
they might, the tightly-controlled and highly-managed NCs might have a fighting chance
after all.
Of course, there are other possibilities. The new Web-based software distribution
method incorporated into Marimba's new Castanet
(a beta of which was reviewed by InfoWorld last week) offers the ability to add a
certain degree of control to the process if IS departments determine which applications
and/or components are subscribed to. More realistically, however, Castanet's ability to
continuously update applications and/or components is probably going to exacerbate the
problem because users are going to start getting updates without even really knowing about
them (nor the ability to easily refuse them - at least in the current version).
I have to admit that I find it distressing to have to discuss these issues because I'm
an avid promoter (and user) of hot, new technologies and a firm believer in the importance
of letting a PC be a truly personal device; in many ways, component software is a
tremendous embodiment of these two principles. In the end, though, I can't shake this
nagging feeling that the component software path we seem to be headed down isn't quite
right.
©
Copyright 1996, by InfoWorld Publishing Corp., a
subsidiary of IDG Communications, Inc. Reprinted from InfoWorld,
155 Bovet Road, San Mateo, CA 94402. Further reproduction is prohibited.
