The Soap-Box - "Black Box" Quandary!

by Dan Conklin

Published 1998-03-01    Printer-friendly version

(Editor's note: "The Soapbox" is an arena in which a reader can express his or her opinion on a Clarion-related subject. The viewpoints contained in this column are solely those of the author and do not reflect the opinions of Clarion Online or its staff. Submissions for "The Soapbox" should be non-inflammatory. Clarion Online reserves the right to refuse any submissions)

I have been involved in many different software and hardware market segments since the late sixties, and our company has been involved as an application developer in the Clarion world off and on for a couple of years. We have just entered the role of third-party developer by taking over the Power Browse product, and are having to address a widely accepted view in the Clarion community that really is totally anathema to the way the rest of the computer universe operates. Who in this community decreed that a product developer using normal mechanisms to protect what they have invested in nonrecurring engineering was the Unpardonable Sin?! In case anyone missed my point, I'll spell it out in simpler terms. Since when is a "Black-Box" (the rest of the world uses them all the time, they are called DLL's) a bad idea for a software developer?

One of the first responses I would expect to get to this question is that "TopSpeed has always provided their source code (templates in the pre C4, templates plus OOP base class source in C4)!" If that is true in actuality, where do I get a copy of the source for the CW2RUN16 & 32, CW2ADM16, CW2GEN16, CW2ASL16, etc., DLL's? Do Clarion developers not realize that relative to things uniquely Clarion (things that get built into the kernel of our apps) TopSpeed is at the Top of the Food Chain and, therefore, faces almost no risk in distributing Clarion source (clw and tpl/w), which has almost zero value relative to the rest of the Windows development community.

If we third party developers devour some Clarion code magnanimously distributed by TopSpeed and regurgitate it as an add-on product, it is in no way a negative to TopSpeed. If the new product is any good, it just makes developers more productive and/or development easier, attracting more programmers into the community (i.e., more CW sales). On the other hand, if TopSpeed likes a particular feature in a third-party product, such as in-line edit or reusable browse code in a DLL (OOP), and that poor developer is required by the community to make his source available, all TopSpeed has to do is get a copy and slightly re-engineer it (if the cat is worried about copyright prosecution from one lonely mouse). In this environment, any other third party developer could employ a similar technique to quickly generate a competitive product!

"That would never happen in our little community" some of you might be thinking. I have a case in point to prove that to be a crock! A short time ago I dealt with a Team TopSpeed member relative to employing a very useful template set of his in a product that we expect to ultimately release as "RoboTools", or something similar (see PBQUEST1.ZIP in the 3rd-party section of the TopSpeed forum). I casually expressed an interest in licensing his "nonrecurring engineering" for a royalty or one-time fee. Since then, I have not heard from him. I suspect that he got the jitters about Christech stealing it instead, or had a similar relationship developing elsewhere, and didn't want to be too helpful. (At the beginning he was very helpful).

He, and all other 3rd-party developers, should be jittery. The package that he sent me is 100% template code, so therefore, I have a copy of all of his source. We would much rather contract to start from a working package that we like - and have already integrated - but if we can't get an agreement together we will probably end up developing our own, naturally using his as an example (who wouldn't). (If you have been following our forum and news group messages you will know Christech has plenty else to accomplish.) This will definitely delay the introduction of RoboTools, which may actually be this template set's developer's objective at this point. This is a terribly sad state of affairs for us 3rd-party developers and I believe it will ultimately be bad for the whole Clarion community.

I can imagine a group of developers sitting around saying "So, according to Conklin, app developers should be the ones left hanging out to dry if a 3rd-party developer, such as ToolCraft, decides to drop a product, such as Power Browse!" My answer to that is, figure out a solution, don't just transfer the problem to somebody else. In this relatively small, tight-knit community it will ultimately bite all of us, and has! We are not just throwing this problem off on the rest of you, though. We have a proposal that could end up as one solution.

One conversion option that is already working in our Power Browse-to-CW2 converter could be easily made to "Sourceify" (dumb sounding but you will see what it means when the converter is released) almost any 3rd party template. In Power Browse's case, it totally eliminates any PB template reference but the application ends up using the Black-Box DLL just like it did before. Many of you may be scratching your head wondering how in the world that is actually a "way out" of any third party template set. The fact that almost everyone has been demanding that "Source" be available is actually the heart of this solution. The availability of source code for the Power Browse library, along with the "Sourceify" option in the converter (a future update is planned to be universal) makes all of the Power Browse source available to you, some of which just happens to ends up neatly integrated in your app at embed points.

If this approach ends up being acceptable to both application and 3rd-party developers, we at Christech would hope that, in the future, as much add-on software as possible would be in libraries. This would leave very little to be processed at build and compile time. This whole concept should work marvelously with the new OOP approach. There is one other requirement, though, for this proposal to work at all: A central repository for source from all 3rd-party developers so that it cannot be pirated, but is guaranteed to be available in case its creators go "belly-up".

The catch? Whoever maintained the repository would have access to all 3rd party code. One option for alleviating this complication would be to encrypt all of the source to be entered into the source repository, and have another independent entity maintain the encryption key. This may all sound very complicated, but something like it could be a great relief for 3rd party developers and, therefore, could stimulate a boon in add-on products for all of us.

Dan Conklin, President

PowerRAD/Christech Research Company

The New Champions of Power Browse!

http://quantumation.com/powerrad

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942