Re: Influencing Adobe on FrameMaker [long]

[Larry Kollar <Larry.Kollar@xxxxxxxxxxx>]

I realize this is a late response, but wanted to give this the
considered answer it deserves.

Dan Emory writes:

>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.

Well, I didn't say all that, but it's fairly accurate. Let it stand.
This assumes that Adobe doesn't have a sudden change of heart and
begins actively developing FrameMaker (preferably while soliciting
input from the users) -- if this happens, or Adobe simply open-sources
Frame, you can bet I'll stop looking for a replacement.


>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.

Quick question -- how do documentation departments migrate from Word
to Frame today?

In my experience, I've migrated from troff to Word and from Word to
Frame. You do it one document at a time. When you have slack time
(and in my 17 years of technical writing, I can confidently say it
happens), writers could determine which documents would be changed
during the next release cycle and convert those.


>[Frame Version 6.0] 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.

This is a good point that many people often don't consider -- just
because software (or hardware) is abandoned doesn't mean it becomes
immediately useless. However, I've heard a lot of mention of glaring,
long-term bugs in FrameMaker that have never been fixed, and (if you
are correct) will *never* be fixed. You can do wonders with the FDK
if you know how, but if the internal engine is buggy you can only work
around it at best. How long can we continue to support a dead product
in this manner? Eventually, people will find suitable alternatives.


However, while you (and many of us) lament the shrinking Unix support,
I don't see how third-party developers are going to help with that.
Most of the current third-party support is Windows-only, with isolated
Mac support. And I can safely say most MacOS and Unix users would
rather drop Frame and find a supported product than switch to Windows.

The comment about "12-year-old spaghetti code" is rather ironic --
it's a good reason for Adobe to abandon the code! Maybe some of the
long-standing bugs we gripe about have stayed around because it's
just too hard to rip them out.


IMO, there are only three ways that supporting FrameMaker can work,
long term:

  - Adobe sells FrameMaker to a company that wants to keep it viable.
    This is probably the most likely fate for Frame. I would hope that
    the new owners would want to preserve -- or even expand -- the
    cross-platform viability, but it's more likely that the platform
    base would continue to shrink toward the McDonald's of operating
    systems.

  - Adobe opens the source code to FrameMaker. Even this is not a
    guarantee of viability, as the developer community would have
    to wade through the spaghetti before being able to do anything
    significant.

  - Adobe has a change of heart. About as probable as opening the
    code.

I won't say anything for or against InDesign, since I know little
to nothing about it.

	Larry




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