Over the past two years, the NEXTSTEP community has witnessed the birth of an object industry. Unfortunately, the variety of objects for sale so far has been limited. But that may change as more developers find an opportunity to remarket their internal development tools as commercial products.
Objects on the open market largely break down into two categories. The first contains objects that take off from where NEXTSTEP stops, providing useful tools for extending the AppKit, integrating the disparate parts of NEXTSTEP, or adding functionality that NeXT simply forgot. Some examples include objects like Objective Technologies' award-winning SmartField-Palette and RDR's RDRSwitchView. Most of these objects are good, solid implementations, though I haven't seen anything yet that I would call inspiring.
The second group of third-party objects contains specialty classes that provide specific functions, like Hot Technologies' BarCodeKit and Trillium Sound Research's TextToSpeech Kit. By and large, these are niche products. If you need to solve a particular problem, they're great; otherwise, they don't apply to a broad segment of application projects.
This dearth of objects is one of the reasons that NeXT's ObjectWare machine is still sitting on the runway, all fueled up but with its engine idling. For ObjectWare to really take off, developers need to offer rich sets of powerful tools, instead of just a few simple nice-to-haves that any competent programmer could write in one or two weeks.
There's a simple metric for answering the question, "What makes a good object?" An object is good if it's cheaper Ð in both the short and long run Ð for a developer to purchase and use rather than write the code from scratch. NeXT's AppKit passes this test; the same can be said of only a few third-party kits currently on the market.
Like most developers, I have developed my own library of objects to speed development of full-blown applications. My objects are mostly related to building document-based applications: abstract superclasses for an Application delegate, a Window delegate, and a document controller that provides support for reading and saving files; an intelligent set of objects for dealing with Preferences panels; a FontWell and FilenameWell inspired by NeXT's ColorWell; and a variety of subclasses for NeXT's Cell, Text, and List objects.
I'm not particularly unusual. Lots of third parties would benefit from looking at their own applications to see what common code can be abstracted and put in a separate foundation classes library.
But should I set up shop and sell my objects just because I have found my own classes to be useful? Providing the tools is only half the work. The other half involves extensive testing, writing documentation, and providing support. If the only person who tests an object is the person who wrote it, it's likely to have dozens of lurking bugs. They may not trip you up, but they'll certainly catch your customers.
I haven't done this work for my classes, so please don't write me asking for copies Ð I'm not giving them out. Still, there is a golden opportunity out there for developers who are prepared to do the work needed to remake their internal objects into commercial products. The buyers are out there. So far, it's the products that have been found wanting.
Simson L. Garfinkel is the senior contributing editor to NeXTWORLD.