What a boon to those of us who write about technology a good exploratory data analysis package would be. It's not that charting trends involves EDA; time series analysis is, I guess, the relevant statistical tool for trend-watching. But just spotting trends is relatively easy, and we writers don't feel that we're doing the job unless we find the megatrends behind the trends, discern the pattern formed by the tangled threads, and extract the big picture.
The human faculty psychologists of the early part of this century were drawn to the lure of the single measure that captured all that was important to know about a person, sometimes calling it IQ, sometimes factor G (for Grail?). They ended up inventing factor analysis and the whole idea of exploratory data analysis. Sometimes, like them, we technology watchers wish for a machine that we could pour all the time-series data of product announcements and technological innovation into and that would grind out the single-summary, meaning-of-it-all megatrend.
Because we don't have one of those machines, we strike one flinty observation against another and look for sparks. It's a living. It's also a vigilance task, such as watching a radar screen, and after a long stretch of peering one can start to see bogies that aren't there. Lately I've been noticing a number of trends that seem to be connected, or maybe they are aspects of a single trend. Inasmuch as I can't put a name to this megatrend, it probably doesn't exist. Let me just say of the following items, then, "Here are some things that are going on. If you think like James Burke, maybe you can find the underlying theme that connects them." Here's one thought: Distinctions that once mattered are becoming matters of indifference.
Adobe has this plan. John Warnock, the Xerox PARC alumnus who cofounded Adobe and invented the PostScript page description language, wants there to be a universal document format. Any document of any kind that can be printed or displayed on any device should be printable on every printer and displayable on every device, and it should be the same document in all essentials, regardless of the resolution of the device, the availability of fonts, or the hardware or operating system platform. And Adobe should define the format.
Adobe is well on the way to producing such a format and the products required to make it work. The project is code-named "Carousel," and is scheduled for release this year, which of course means next year.
Most of the press materials on Carousel emphasize the publishing implications: true electronic publishing, magazines on disk. But because every application displays information on screen and most also print, we're really talking about every application domain there is. Anybody involved in application development should know about Carousel.
Carousel is an extension of PostScript, but it goes well beyond PostScript. PostScript versions for different machines aren't identical, but Carousel's format is intended to be universal. Only PostScript printers can print PostScript documents, while Carousel documents will be printable even on dot-matrix printers. PostScript doesn't know about documents; it creates a page, rather than a document. Things such as margins, column widths, and tab settings are not part of the PostScript page description. They will be part of the Carousel document description.
If you don't have the fonts used to create the document, you won't see the document properly even if you have PostScript and the creating application. Using Carousel, you don't need the original fonts. Carousel will support Adobe's new Multiple Master Fonts, so that all important font attributes get carried along with the document. On display or printing, you may get a simulated font, but it will match the original closely enough that character widths and line breaks, for example, will be preserved at any resolution.
What Carousel needs to succeed is user demand. Adobe will sell to users a viewer, conversion utility (for the PostScript output of existing aps), and a set of Multiple Master Fonts. To the developer, it'll license the technology. If it has a prayer of making this universal, Adobe needs to price the user and developer packages low. Well, the user package, anyway. Even if the developer price is daunting, demand from users can nudge developers along, of course. And users are being nudged right now by an article that is scheduled to appear in this month's MacUser magazine.
Wouldn't it be a comfort to be able to say, like some user, "I'll believe it when I see it," or "I'll cross that bridge when I come to it"? But developers and writers on technology, if they want to stay on top of developments, are forced to believe in things that don't exist and to cross bridges while still on dry land.
One such landlocked bridge is Taligent, the Apple-IBM joint venture and its currently eponymous and nonexistent but nevertheless important operating system. The Taligent folks are serious about the job of creating a seminal instance of the next generation of personal computer operating systems, and they'll do it. Assuming that political considerations don't intervene, which is a big assumption, but one we sort of have to make.
On that assumption, the Taligent story includes this promise: Existing applications will run on hardware running the Taligent operating system. Taligent, an object-oriented system, will support objects called "personalities," one for each supported operating system. These personalities will be operating system emulators, and the promised emulations are the Mac operating system, AIX-A/UX or whatever UNIX Taligent recognizes at that time, and OS/2.
Taligent itself is intended to run on a variety of hardware platforms, including 680x0, 80x86, and RISC hardware. And it's supposed to be scalable, a word that promises so much, so it will run not only on different processor families but also on hardware of differing speeds and capacities. Faster hardware will be preferable, but any hardware meeting minimal criteria should be OK. So the hardware doesn't define the system.
Emulation of other machines and operating systems is not a new idea. If it's practical today, it's because of the power of the hardware. There is some irony in the fact that the speed and power of the hardware makes the choice of hardware somewhat irrelevant. But the irrelevance is only technical. Politically, it is not clear that all emulators will be available for all hardware platforms.
Michael Kei Stewart has ceased publishing his Developers' Insight newsletter, closing it out with grace by paying back what he owes his subscribers. His final issue includes an article on just-in-time software technology, written by one Sandy Ruby.
Ruby argues that the pace of software development is driving the big software houses to buy rather than build. Microsoft buys DOS 5.0 utilities from Central Point Software. Borland buys a Windows interface builder from the Whitewater Group. Lotus buys word processing technology from Samna.
Traditionally, it's been the smaller companies that buy technology to keep up with the biggies that can afford to build their own. But more and more often, the large companies are looking outside for technology. The forces driving this move, Ruby says, are risk and speed. Speed to be the first company in a market, or at least to reduce the time lag between your competitor's Excel and your 1-2-3 for the Mac. The risk is the risk of committing internal resources to a path that turns out to be the wrong one.
There may be other ways to speed up product development. Maybe OOP, done right, or some variation on or combination of software engineering methodologies, will make it possible for big companies to get products to market fast. OOP seems to be helping Borland get updates cranked out fast, but that's not the same as turning out new products based on new technology, which is what keeps the industry (as opposed to a company) alive. But buying is what the big companies are doing now.
This trend is not bad news for the small developer. The buyers and sellers both stand to benefit in outsourcing, and the sellers tend to be smaller, more focused companies.
Smaller companies can benefit from the trend in the role of purchasers, too. When a small company buys technology from another small company, it may be able to compete with a larger company that goes it alone. Ruby cites the example of Clarion licensing JPI's TopSpeed code generator. TopSpeed can compete technically with the big guys, so Clarion has less to fear from their future database offerings. We know that, in this rapidly-changing industry, small companies can compete with large ones. Here Ruby suggests one way.
Although Ruby doesn't use the analogy and I'm not sure it works, isn't there a parallel between small companies banding together in this way and the acknowledged superiority of almost any user-selected suite of focused applications over an integrated package? The big company building it all is saddled with the problem that the product is only as good as its weakest development team. Like an integrated package is only as good as its weakest component. The small firm can choose technologies rather than teams, eliminating uncertainty as well as delay.
In the same issue of Developers' Insight, Bill Lohse talks about small software developers pooling their resources. Lohse has been involved in sales and marketing in one area or another of the personal computer field since 1978. He got his start in the industry at IMSI, moving from there to MicroPro and IUS, going on to found Breakthrough Software, and in recent years working in magazine publishing as the publisher of several Ziff-Davis publications and president of Ziff-Davis. His latest venture is Software Venture Partners, a venture capital company with an interesting premise.
Software Venture Partners invests in startup companies, and requires these things: that they have great products, that they put together a business deal with Lohse's company, and that they want him involved in their company one day a week. Lohse is quite serious about this last item. Software Venture Partners is limited to backing five companies at a time, so that Lohse can actually spend one day a week with each company.
What Software Venture Partners offers to entrepreneurs is marketing savvy and, eventually, a cooperative pool of resources in the areas of marketing, sales, and tech support.
Lohse knows that software entrepreneurs are reluctant to give up any control in their businesses. That's why he's skeptical about the idea of a software cooperative. In such a venture, he says, "it's going to be difficult to engender the kind of consensus needed. You're going to have to get three or four companies to act together, without the guidance of someone who can say, 'You ought to listen to me, because I've done this before successfully'."
Software Venture Partners is not a coop, but a way for entrepreneurs to get capital and savvy marketing help at a time when they need it most without giving away the store. I first met Lohse when he was with MicroPro almost a decade ago, and I know he knows what he's doing. His venture is too new, though, to have a track record. He welcomes calls from developers at 702-588-3171.
Ruby's view of small companies licensing each other's technology does, I think, suggest a level at which new and small companies can work together without giving anything up.
Of course, anything a small company can do, a well-managed large company can also do. But remember, the bigger they get, the better is the chance that, rather than trying to beat you at your own game, they will hire incompetent executives at astronomical salaries, blame the Japanese for their failures, and demand that the Federal government bail them out when they can't compete.
Copyright © 1992, Dr. Dobb's JournalThe Universal Document Format
The Increasing Irrelevance of Hardware
The Outsourcing of Technology
The Outsourcing of Marketing Savvy