FrameMaker's Future

[Daniel Emory <danemory7224@xxxxxxxxxxxxx>]

I've noticed a number of threads discussing
FrameMaker's future. Here is my take on it.
Those who think they can somehow revive FrameMaker
support for the Mac are living in a dreamworld, which
should become apparent after they face the realities
discussed below. 
 
There are a number of those realities which revolve
primarily around the absolute necessity, for a product
like FrameMaker, to rely heavily on successfully
capturing a large bloc of large license holders. To
understand the importance of the big licenses holders
requires a review of FrameMaker's history:
 
1. FrameMaker was created by FrameTechnology in the
mid-to-late 1980s, thus the core code is nearly 20
years old. I've been using it since 1990
 
2. By December, 1995, FrameMaker had reached its
zenith with the initial release of FrameMaker+SGML and
FrameMaker Version 5.0. At that point, Frame's client
base consisted mainly of large companies, many of
which owned thousands of licenses. Despite the massive
scope of the SGML capability, release 5.0 was
amazingly stable and bug-and memory-leak-free, proving
the elegance and adaptability of the original core
code 
 
3. Shortly before the release of Version 5.0,
FrameTechnology was purchased by Adobe. Within a year
or so, Adobe had pretty much dismantled the Frame
Technology organization, eliminated the training and
customer support groups, and lost most of the Frame
Technology programmers.
 
4. The first release by Adobe was version 5.5, whose
main purpose was a failed attempt to capture the Asian
market by adding double-byte, Rubi and related
features, plus a half-assed HTML converter. The
release had more bugs than the movie Starship
Troopers. It took four releases, culminating with
release 5.5.6, to make it once again (relatively)
bug-free and stable. The memory leak problem, however,
had grown significantly. .
 
5. Although Adobe had declared ambitions in the late
90's to carry out a major revamp and modularization of
the FrameMaker code, nothing ever came of it. 
 
6. As a result of the failure to modernize and
modularize the code, the next two releases, 6 and 7,
had relatively modest added features, primarily in the
structured document realm. Although these releases
were relatively stable, the memory leak problem
continued to grow---one of many symptoms that the code
had become intractable. This intractability of the
code has, quite obviously been the main reason why
urgently needed new features to fully support XML
(e.g., schema and Unicode support) have failed to
materialize. And the ultimate killer App feature, the
ability to convert an EDD's format rules into XSL
instances is, apparently, unachievable.
 
7. During the era when Frame Technology owned
FrameMaker, the company's secret to success was to
cater to the big companies which owned the vast
majority of the licenses. Those large companies
demanded the following things:
 
- The power to have a major influence on what new
features were to be added to each new major release.
 
- Heavy participation in Beta testing of each new
release.
 
- Paid Maintenance contracts for each license in
return for free upgrades and superior (and free)
customer support via email and phone. In effect, these
maintenance contracts provided a huge portion of
advance funding needed for the development of each new
release.
 
- A superior customer training organization which
provided both training and high-quality training
materials, giving those companies the option to
purchase the training materials or to purchase
training by Frame Technology trainers, both on-site
and at Frame Technology's headquarters in San Jose.
 
- Superior User Manuals which provided users with the
in-depth details of the product
 
Wihin a year or two after Adobe bought Frame
Technology, Adobe had abandoned and dismantled this
entire support structure, and had radically degraded
the usefulness of the User Manual.
 
This extreme degradation in the entire support
structure for FrameMaker explains, more than anything
else, the rapid growth in the number of subscribers to
the Framer's Lists. That list has become the
substitute for what existed before Adobe took over the
product.
 
8. The combination of what is described in items 6 and
7 above began to produce a growing abandonment of
FrameMaker by the big license holders, which has now
reached a torrent. This loss of the big license
holders was the final blow to FrameMaker's future,
among other reasons because the main source of
advanced funding of new release development costs has
been evaporated.
 
9. The advent of high-end XML/Database Content
Management Systems requires heavy integration of the
authoring software into that new environment. Adobe
has done nothing to adapt Framemaker to that
environment. Arbortext, with its Epic Editor product
has not made that mistake. It has all the bells,
whistles and add-ons which allow it to be fully
integrated into a high-end CMS environment. FrameMaker
has lost its chance to become the authoring system of
choice in this environment, which means it can never
again become the pre-eminent choice of large companies
requiring thousands of licenses.
 
10. The saddest thing about all this is that a vast
array of talented aftermarket developers has evolved,
who produce an incredible array of enhancements to
FrameMaker capabilities. During Frame Technology's
reign, it produced a thick annual guide to all of the
products and services available through those third
parties which was offered to all license holders.
Inexplicably, Adobe immediatley abandoned that
marvelous sales tool, which Frame Technology
salespeople would invariably use as part of their
sales pitch to potential customers.. 
 


=====
Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
DW Emory <danemory7224@xxxxxxxxxxxxx>

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