Re: Zaurus discontinued in US -- vendor lockin or mitigating risk

["Bryan J. Smith" <b.j.smith@ieee.org>]

On Thu, 2004-10-21 at 10:42, Joe L. wrote:
> I'm unhappy to hear about the Zaurus exodus however while they're still
> here maybe prices will drop a little. And with it being a FLOSS-based
> device it's a great example of linux vendor lockin protection.

Agreed, but with one caveat.

- PalmOS still a GNU target, Standardware platform

Of course, PalmOS is still a GNU target, which I would call I
Standardware (open standards, closed source) OS, so you _can_ (and there
is) a wealth of Freedomware (open standards, open source) for it, in
addition to Standardware and Commerceware (closed standards, closed
source).

Furthermore, I would make the argument that Vendor Lockin protection
varies.  Standardware platforms are far better than Commerceware
platforms, and Commerceware platforms are better than Hostageware (_no_
standards, closed source).

- Vendor lock-in or mitigating risk (to data)?

Which leads me to my final point.  To me, the religion of it all is
facinating, but I have to break it down to "mitigating risk."  The
discontinuation of any platform is a risk, even if the data can be
extracted.  In fact, in the case of a Linux PDA v. PalmOS PDA, there's
really no difference in my ability to extract my data.

So in going with the PalmOS over Linux in a PDA, I am no less mitigating
the risk to my data by going with the former over the latter.  And since
the former has had better synchronization tools for both Linux desktops
and even network-based synchronization, I would argue that PalmOS gives
me lower TCO as well as "as good" (or better) mitigation of risk.

Focus on risk, not religion, that is what keeps my, and the companies I
consult for, data alive and usable.

- Vendor lock-in is limited to Hostageware and some Commerceware

The vendor lock-in is an excellent argument against Hostageware vendors
(e.g., Microsoft, Autodesk, etc...), but it loses weight when you have a
vendor who cares about their consumer.  Perfect example:  Corel.

WordPerfect, clearly a Commerceware application (not even Standardware)
can read nearly any of its own formats backwards and forwards. 
Furthermore, according to eWeek tests, it is the best application at
reading a Hostageware format, MS Word -- not only better than any 3rd
party application, but even MS Word itself.  I.e., Corel WordPerfect
v11+ can read and near-verbatim render MS Word 97 and 2000 documents
than MS Word XP and 2003, respectively, because Microsoft uses the
Hostageware strategy of "only one version back."

- Hard to predict the future, but StarOffice users "lucked out"

Furthermore, I starting using StarOffice, previously a Commerceware
application, in the mid-'90s largely because of StarImpress.  When my
company forced me to move from 1-2-3 and AmiPro (a desktop publish
application, _not_ a word processor), I adopted StarOffice instead of MS
Office personally (and was able to push for it increasingly in my
professional use too).  Now I was running a risk with my data, but it
ended up that StarOffice because a Standardware platform starting with
version 6 (OpenOffice XML based).  It's nice to be able to read all my
documents all the way back to when I started using it, StarOffice 3.0,
as well as exchange with people who are using OpenOffice.org.

- Lesser known applications:  Desktop Publishing

And to throw another set of applications into the wrench, with the death
of Lotus AmiPro in the mid-'90s (Lotus' "WordPro" alientated everyone,
as it was no longer a DTP), Sun/OOo, Microsoft, Corel and others do not
offer a complete DTP (MS' Publisher is a laughable DTP, because a
serious one would compete with MS Word).  So for serious (50+ pages)
documentation, I have had to move elsewhere.

Adobe FrameMaker has been my Commerceware staple of choice.  Adobe still
hasn't offered a Linux version other than a beta/test -- even though
they have an aging UNIX version for 2 flavors (NOTE to Adobe:  why not
bundle Linux with that version???).  But it's costly, and most companies
don't fork over the dough -- so I've only used it when they do,
typically because they product a lot of documentation standards
themselves.

- LaTeX:  The staple of technical documentation

But I adopted LaTeX-based LyX in 1998 and I'm now also glad I did.  Not
just because TeX, invented in '79 by Donald Kunnth (if you're a
CS/ECS/EE/ECE/CpE, you've probably had a book or two of his ;-), but
because LaTeX was used for the production of a majority of technical
books until the invention of DTP -- and still a sizeable number today
thanx to the American Mathematical Society (AMS) and the Institute of
Electrical and Electronics Engineers (IEEE).

Today, LaTeX conversion to OpenOffice XML is extremely well.  Not only
for headings, captions and formats, but most importantly, formulas. 
OpenOffice XML uses MathML for formulas (aka equations), which converts
seeminglessly to LaTeX and vice-versa.  So no longer to I use RTF
export/import from/to LaTeX, but I convert OpenOffice XML to/from
LaTeX.  And once I have OpenOffice XML, I can export/import from/to DOC
9.0-"97" (MS Word 97) fairly well.

Some use DocBook, which started as a subset of IBM's '65+ SGML and now
has a full XML compliant schema set, which that's nice for less
feature-rich documentation.  I won't bash it, but it's not the same as
LaTeX.  And there is no way Star/OpenWriter, let alone MS Word (not even
XP/2003), can handle the sheer size of some of my LaTeX/LyX or
FrameMaker documents.  As one on-site Microsoft paid applications
support person told me at a Fortune 20 company:  For your usage (50+
page technical documentation), we recommend Adobe FrameMaker, it is what
we use at Microsoft to write our MS Office manuals.

-- 
Bryan J. Smith                                  b.j.smith@ieee.org 
------------------------------------------------------------------ 
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.