"Copyleft" doesn't solve _our_ problems.

Subject: "Copyleft" doesn't solve _our_ problems.
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 15 Mar 2000 09:14:48 -0500

Tim Altom observed that <<The new GNU Free Documentation License is out. For
those of you not familiar with GNU or the Free Universe, GNU is an
organization that specializes in coordinating projects whose outputs are
free in both senses of the word...they're free for download, and freely open
to modification... This intrigues me, because most of the companies we work
for don't have good arguments for not distributing free doc, especially
online.>>

I really like the open-source movement for a variety of philosophical
reasons, of which the sense of community between the users and the
developers is one of the biggest. Microsoft and other software behemoths
could learn a lot from this. However, proposing an open-source model for
documentation ignores two crucial points about how commercial software
differs from open-source freeware:

1. First, technical support becomes a nightmare if everyone has a different
version of the documentation. As a developer, how can you take
responsibility for (say) my version of the manual, if it turns out I've made
several key conceptual errors in my rewritten version? This problem largely
vanishes if you move wholly to an open-source model for technical support,
because your technical support would then also follow the open-source
approach (distributed, and handled by the user community as a whole). But
that's a major organisational shift that goes far beyond making the
documentation available free. And think of it from a marketing standpoint:
"We offer no technical support or getting started information for our
product, but don't worry; you can find it online somewhere if you're
patient." I get 99%+ of my technical support online via techwr-l and other
lists, and many techwr-l readers are likely the same, but we're a distinct
minority.

2. Second--and speaking largely defensively--technical writers add an awful
lot of value to an organisation both in providing the docs themselves and in
fighting with the developers to fix interface and usability bugs. If the
documentation is no longer sold for a profit (or at least on a cost-recovery
basis) as part of the "sunk cost" of the overall product, who's going to pay
for those technical writers? It's often hard enough making the case for our
existence when we can be cost-justified, but when there's no quantifiable
payback from employing us, there's no reason to employ us. Again, the
open-source movement is a good example: I've heard nothing good about
open-source documentation in general, with the exception of that provided by
third parties (e.g., Red Hat, Corel) who package the products in a more
friendly manner. But these people are operating largely according to the
commercial software model again, not the open-source model: the reason you
pay them for software that you could download free is because of the
documentation and integration they provide.

<<the ready availability of freely downloadable and modifiable doc would
help a lot in those situations where the old doc has been lost or not
updated.>>

That's a particularly attractive proposition given that some key product
manuals have recently gone walking, and I'm going to have to order new
copies. I'm seeing a lot more documentation made available online, and
suspect that this trend will continue. But the model's not the same as with
the open-source movement, where the software is also free, and doesn't make
much sense in the context of commercial software. With commercial software,
there's no reason not to make the info. available online, since people have
already paid us for our product--but if they've paid for the product, then
they've already got the documentation, so why would they need it available
online?

I've been critical about your suggestion thus far, but I don't want to give
the impression that I dismiss it out of hand. There's lots of good meat
there, and lots of things that I can easily see happening to us as a
profession over time; for example, the whole notion of distributed technical
support (based on the techwr-l model) is a uniquely attractive one,
particularly if technical writers are paid to participate and paid to
develop the documentation. But the issues you've raised involve far more
than just making the documentation "copylefted".

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

Hofstadter's Law: The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sponsored by Weisner Associates Inc., Online Information Services
Training & consulting for RoboHELP, Dreamweaver, HTML, and HTML-Based Help.
More info at http://www.weisner.com/train/ or mailto:training -at- weisner -dot- com -dot-

Your web site in 32 languages? Maybe not now, but sooner than you think.
Contact ForeignExchange for the FREE paper, "3 steps to successful
translation management" (http://www.fxtrans.com/3steps.html?tw).

---
You are currently subscribed to techwr-l as: jorgeprado -at- arnet -dot- com -dot- ar
To unsubscribe send a blank email to leave-techwr-l-29532C -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.




Previous by Author: Manuals without chapter numbers?
Next by Author: MS Word chokes while making PDF?
Previous by Thread: Re: "Copyleft" doesn't solve _our_ problems.
Next by Thread: Practical usability testing?


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads