Secret <emphasis>Linux Journal</emphasis> Editors' Guide

You didn't think I'd leave without revealing the
secret of how to edit this thing, did you?
There's already an
author's guide
for this magazine, but here, in my own humble opinion, is how to
edit it.

First of all, on the Internet, every movement
looks like a big argument. So don't make a big
deal out of on-line debates, such as the infamous
“GNOME vs. KDE” thread. Generally around here,
for every dumb conflict story there's a real story.
For every “GNOME vs. KDE” story, there's a freedesktop.org
story trying to get out. Make the extra effort to
get the real point—in this case, what the real
developers are doing to make desktop apps compatible,
not what random people are arguing about. Judge the
tree by its fruit. If it's worth running, it helps
the reader get something done that he or she couldn't
do before reading it. You feel better and smarter
after reading the good articles.

Keep running the weird articles. Most readers aren't
going to navigate to the North Pole under the ice cap,
put a Beowulf cluster in space, drive a Mars rover or
and control devices with their brain waves. But,
a good magazine gives you a kick in the behind every
so often. Maybe I should be writing my next Web
application in C or using a compression tool other
than the venerable zlib, but I never would have
thought to search for it.
When readers live inside the Googlemind, there's
little value to running the big obvious subjects.
More and more, if it's something they already know
they want, they've already gone out and gotten it.

Have helpful questions for authors who sound
promising but don't have a sound article proposal yet.
If you ask the right question, an author can turn an
unworkable security proposal into a thought-provoking
article on what not to do and why not or turn a general “how to use
Linux in your business” proposal into a solid system
administration article. Sometimes if you ask a really
hard question, an author sneaks away for a while and
comes back with something great.

You have a printing press at your disposal, so
don't fear the infamous Digital Millennium Copyright
Act (DMCA). You can see several articles in back
issues that would have brought down a storm of lawyer
letters if they had been on the Web. But not even
an entertainment industry lawyer will walk into a
courtroom and ask a judge to burn a book. Don't make
too big of a deal out of the digital-freedom-enabling
articles, but don't miss a chance to do one.

Make the authors do unconscionable amounts
of work. Linux Journal
authors will code and test sample applications, shoot photos, build
circuits and even review other authors' proposals
and articles. There's a lot of goodwill in the
world for Linux Journal, so
use it. One good point about working with authors
is Linux Journal's secret
weapon: an author contract that lets them keep
the copyright to their work and use it however
they like after initial publication.

Don't be afraid to be “too hard” or
“too technical”. If a reader is motivated, he
or she will catch up. If not, an article that
describes an excellent result—something new
and different—could be a great motivation.
Show me a magazine that just covers how to get the
same results on Linux as you had been getting on
a proprietary OS, and I'll show you readers who
are getting asked to make a painful switch for no
benefit.

Every so often, you will run into a reader who tells
you, “I didn't get my magazine.” Have a couple of
extra copies on you, and make sure you know how to get
into the subscription system and give the person a
bonus month. In some companies, everyone is in sales,
but when it's a magazine people really miss when they
don't get it, everyone is in reader services. But
the occasional complaint about
a missed issue is a good sign. When you stop hearing
complaints when people miss an issue, you're being too boring. Have a
good time.

Don Marti is still editor in chief of Linux Journal for
a little while.