Re: Influencing Adobe on FrameMaker

[Dan Emory <danemory@xxxxxxxxxxxx>]

Bill Hall and Larry Kollar suggest that the answer is to give up on trying 
to save FrameMaker, accept XML as the universal iinformation interchange 
format, and simply find a suitable replacement for FrameMaker. But that 
doesn't work for companies that have huge libraries of legacy FrameMaker 
documents. For such companies, the costs of reliably converting those 
unstructured docs to XML, SGML, or some other format would be prohibitively 
high. Some companies are already confronting this problem as a result of 
the abandonment of most flavors of Unix in FM V6.0, although there is at 
least a migration path (even though difficult) to some other supported 
platform.

The cavalier way in which Adobe has been abandoning support for Unix 
platforms without advance warning is unconscionable. Versioin 6.0, the 
first major release in 4 years, was a vast disappointment. It is almost 
certainly the final release before Adobe puts FrameMaker into maintenance 
mode where it will be left to die. After all, the FrameMaker code is 
already more than 12 years old, and I'm sure much of it is spaghetti by now.

The real question, then, is whether it is possible to sustain the viability 
of FrameMaker /FM+SGML (and thus maintain most of the installed base) for a 
number of years after Adobe abandons it.

  I know of at least one company (and there are probably other major 
license holders) which have binding commitments that entitle them to the 
source code if FrameMaker is ever discontinued. It might be possible for 
outside developers to get hold of that source code.

Products like FrameScript are capable of overcoming many of the product's 
deficiencies, and, as more people use it, a whole panoply of scripts may 
become available to the installed base. Also, third-party developers may 
be  more tempted to develop new enhancements and add-ons to FrameMaker if 
they knew that Adobe is not going to produce any more new releases that 
might wipe out their products. In fact, companies like Finite Matters, Omni 
Systems, Blueberry, Frank Stearns, Qudralay, and others may be strongly 
motivated to provide new products in an effort to extend the viability of 
FrameMaker/FM+SGML, and thus preserve their own installed base of users of 
their products

I can think of several products that might offer lucrative opportunities 
for 3rd-party developers. Here are two of them:

1. A Unicode-to-Frame-Character-Set converter that would preserve 
foreign-language text when converting from Word 2000 to FrameMaker.

2. An XML-to-SGML Converter that would allow XML documents to be imported 
as SGML documents into FM+SGML. This should be possible using XSL 
transformations, but there may be better ways to do it. Since FM+SGML can't 
handle Unicode, the conversion process requires that upper-ASCII characters
(and some others) be converted to entity references.

I'm sure that many of you could identify other needed enhancement products.

It might even be possible for the Frame user community to develop what 
amounts to functional specs for such enhancement products, and literally 
put them out for bid to third-party developers. If a respondent stated that 
he'd be willing to produce the product at a price of X dollars if he could 
get firm advance commitments for X number of licenses, it might be possible 
to set up a process for accomplishing all of this.


====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
majordomo@omsys.com with "subscribe framers" (no quotes) in the body.



** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **