Linux Journal Author's Guide

This document exists because we want to make sure all authors, and people who want to be authors, get our best answers to common questions--not because we want you to read the FAQ instead of asking questions. If you do have questions about writing for Linux Journal, please contact Jill Franklin at <ljeditor@linuxjournal.com>.

PR-related questions and answers are now a separate Guide to Linux Journal for PR Professionals

Please send comments on this document to Jill Franklin, Executive Editor: <ljeditor@linuxjournal.com>.

Introduction

Linux Journal publishes articles about developing and using Linux and related software. People read Linux Journal to learn how to do things on Linux they couldn't do before.

Article Topics

We try to run articles about all categories of software that run on Linux and articles for readers at all skill levels. We try to run articles that will appeal to as many readers as possible.

The Article Process

Articles generally go through something like the following process.

  1. Initial query letter from author. We prefer query letters sent as e-mail, in the body of a plain-text message, not as an attachment. If you are not sure if your e-mail client is configured to send plain text, please check it before writing to us. Send your query letter to ljeditor@linuxjournal.com.
  2. Do not use a challenge-response email system on the From: or Reply-To: address in your query letter. Your reply will come from a different address, not from ljeditor@linuxjournal.com, and we do not comply with challenges.
  3. Outline and deadline. If we like your article idea, we will ask you to send an outline of the information to be covered in the article and a date by which you could commit to having the article finished. For a proposed article series, you can write one outline for the entire series, but please include a deadline date for each article.
  4. Assignment letter. We send you this letter, which includes information on formatting and how to check and submit your article.
  5. Submit the article to ljeditor@linuxjournal.com.
  6. Editing and markup. We do these steps in-house.
  7. Our final proofreading and publication.

Contract and Copyright

All writing is done on speculation. If we decide to use the work, we purchase first rights, compilation rights and translation rights to the article. However, we are under no obligation to publish it. We do not pay kill fees.

Once your article is submitted, it is in the publication queue and therefore cannot be submitted elsewhere, unless 1) Linux Journal rejects the article or 2) the author notifies Linux Journal of his/her intent to withdraw the article and Linux Journal agrees to release the article. The only circumstance under which we will not release an article is if it already is scheduled for publication and it's too late to pull.

Our author contract allows us to use your article in an unlimited number of compilations and translations in any medium. After your article appears in Linux Journal, you are free to use it for any purpose, because you keep the copyright. If your article documents how to use a free software program, we encourage you to contribute it to the project under a free software license, so it can be distributed with the software you discussed.

If your article appears in the monthly digital edition or both in the monthly digital edition and on the Linux Journal Web site, you are free to use it for other purposes beginning the first day of the month after the cover date of the issue in which it appears. For example, if your article appears in the May 2007 issue, you can use it for other purposes starting on June 1, 2007.

If your article appears on our Web site only and not in the monthly digital edition, you can use it for other purposes one month after it first appears on our site.

You can't use your article for other publications or for your Web site while it is in the publication queue or in the current issue of Linux Journal.

Article Types and Lengths

Feature/In-Depth
This is a how-to or success story article that includes some or all of these: sample code, screenshots and photos.
Product Review
A fair, real-life evaluation of a Linux-related product. Includes a product screenshot or photo.
Article Type     Length
Feature/In-Depth     2200-2800 words
Product Review     1500-2000 words

Article lengths include sidebar text, but not code.

Article Format

Articles must be sent as plain ASCII text, either in the body of an e-mail or as an attachment. Images and other items can be included in a tar archive with the main article or as separate attachments.

In the text of your article, notes or formatting information can be included within [square brackets], as needed. Put only one space after sentences, a blank line between paragraphs and don't indent paragraphs. Do not use any TAB characters, use spaces instead. Do not use any word processor special characters, such as "smart quotes". Use -- for an em dash. (—)

Feel free to include any other instructions for the editors, such as indications of superscript or subscript text, within [square brackets]. If the material you are writing contains equations or requires special formatting, contact your editor to determine a format that fits your needs.

Any sample code within an article should be 52 characters wide or less. If you number your lines, the line number and following space count as part of the line width. In general, we prefer that you use code excerpts that are short enough to make line numbers unnecessary. Use spaces instead of TAB characters to preserve formatting.

Send tables as plain ASCII text. We will lay them out.

Don't include URLs in the text of the article. Put them in a separate Resources section at the end.

Image Formats

First of all, if your image is line art that you can send as EPS, please do so.

You can also send an image as a PDF file, if it meets these criteria:

  • fonts need to be embedded in the document
  • Color mode: CMYK or Grayscale
  • no Adobe Acrobat 6 or 7 PDFs. Acrobat 5 or earlier is fine, as are free software tools for creating PDFs.
Known good Free Software PDF-creating tools:
  • GNU Lilypond

Otherwise, send the largest available version of the image as a PNG or TIFF, if possible, or a JPEG if that's the original format your digital camera uses. Please do not send images that have been pre-processed for the Web; send the original image from the digital camera or scanner.

Converting to GIF or JPEG represents a loss of information--JPEGs lose pixels, GIFs lose colors. Converting to GIF or JPEG is a traditional final step before putting an image on the Web, but is not high-quality. Send the big image with the information intact. For example, if your digital camera shoots JPEGs, and you want to crop one before sending, convert it to TIFF or PNG, do the work and leave it as TIFF or PNG--don't convert back to JPEG.

For each photo, please include the name of the photographer and a caption. If people appear in the photo, your caption should identify all the recognizable people in the photo.

Items to Include with Your Article

Each article should include a two or three sentence biographical statement, for example, "Joe Author has been a UNIX systems administrator for ten years. He keeps ducks and freshwater shrimp for a hobby and welcomes your comments sent to joe@ducksnshrimp.org." The bio can be serious or humorous.

We also need your mailing address, which is not published, in order to send you an author contract, payment and a complimentary edition of Linux Journal.

Some optional items that you may choose to include with your article are:

Alternate Titles
If you can't decide on a title, include more than one.
Sidebars
Consider including short standalone blocks of text that explain useful tools and techniques relevant to the subject of the article. For example, if you're writing an article that mentions using diff(1) to show differences in C files, you might want to include a short sidebar on indent(1) to help the readers separate minor differences in format from meaningful changes. Sidebar text counts as part of the article length.
Screenshots
Screenshots really help readers understand GUI programs. Use screenshots to illustrate major steps or concepts. Don't use an extra screenshot when it's easy for the reader to visualize it based on an previous screenshot.
Teaser or Summary Text
We include a short description of each article at the top of the first page of the article and in the table of contents page. Look at a recent issue of Linux Journal for ideas, and consider sending us some text to help sell your article.

Writing Style

  • Pick a topic you care about.
  • Be conversational. Directly address the reader. Use imperatives.
  • Write as though you were chatting with an intelligent friend who may not be familiar with the specifics of what you are covering. Never talk down to the reader.
  • Use short sentences. It helps.
  • Use short words, unless the exact word you need happens to be long.
  • Be careful with humor. Sarcasm and irony are misread easily and can be offensive. Many readers have English as a second language and may not be familiar with your culture's running jokes and topical matters.
  • If you realize you cannot meet a deadline, please let your editor know as soon as possible.
  • Please have a technically competent colleague look over your work, especially any code, before submitting it.

Passive Voice Should Never Be Used by You

Read that section title again. Isn't it terribly awkward to read? Ask yourself, would you honestly ever say this to someone? The problem with this title is it is written in passive voice. It is a joke to get a point across. NEVER use passive voice unless it is absolutely necessary (and it is almost NEVER absolutely necessary).

I will expound on the importance of using active voice in a moment. But William Zinnser says it best in fewer words in his book On Writing Well (emphasis mine):

Use active verbs unless there is no comfortable way to get around using a passive verb. The difference between an active-verb style and a passive-verb style -- in clarity and vigor -- IS THE DIFFERENCE BETWEEN LIFE AND DEATH FOR A WRITER.

"Joe saw him" is strong. "He was seen by Joe" is weak" The first is short and precise; it leaves no doubt about who did what. The second is necessarily longer and it has an insipid quality: something was done by somebody to someone else. It's also ambiguous. How often was he seen by Joe? Once? Every day? Once a week? A style that consists of passive constructions will sap the reader's energy."

You are unlikely to write "Joe saw him" in an article for Linux Journal. Here are some examples that may be more relevant to you:

Active voice:

Click the Color button to change the color of the text.

Passive voice:

Text colors are changed by pressing the Color button.

Why is the difference so important?

Linux Journal is a magazine. It is not a reference manual. You can get away with passive voice in a technical manual. You will lose a magazine reader's attention with passive voice. As Zinnser points out, it takes too much effort to unwind a sentence in passive voice in order to understand what it is you are trying to say.

Why is the difference so important to YOU?

Read any good book on how to get published. Every book will tell you that the best way to get published (especially regularly) is to make the editor's job as easy as possible.

You make our jobs much harder when you write in passive voice. We change passive voice to active voice in every article until we burn out from doing it. If you include a lot of passive voice in your article, that makes us expend a LOT of tedious effort. We prefer to spend our time checking the accuracy of your content or making the content more clear and presentable.

Why do we burn out?

We get many articles that are written almost entirely in passive voice. We spend hours replacing your passive text to active. We are always inclined to reject these articles because they require too much work. We fight that temptation but our first inclination is to toss it and move on to an article that isn't as difficult to edit.

You may respond, "Yes, but I've seen passive voice in Linux Journal." This is true. Sometimes we publish articles with passive voice because the content is too good to pass up. We let the passive voice slip through because we have burned out from having edited out the passive voice in the past six articles.

But do you really want to take the chance that your article is too good to pass up? Sometimes we will toss an excellent article because it is written entirely in passive voice. We understand that the rejection letter will be disappointing to you, especially if you know your article had great content. But sometimes we reach the end of our rope and simply cannot endure another passive-to-active editing session. So don't risk putting a lot of work into an article only to have it rejected because it was too much work for us to edit it.

Tips on How to Recognize You Are Using Passive Voice

It is hard to break the habit. We know. Most of us started out just like you. We wrote everything in passive voice. Our editors corrected us again and again until we broke the habit.

Here are a few tips you can use to help you recognize when you are slipping back into the habit of using passive voice.

1. You start a sentence with an "...ing" word.

"Changing the text color is as simple as..."

2. Your sentence has one or more "...ing" words in it.

"The text color is changed as simply as CLICKING on the Color button and SELECTING the color."

"Setup is accomplished by EDITING the configuration file, INSTALLING the Java Virtual Machine, and RUNNING the program."

Watch what happens to the "...ing" words when I change these examples to active voice:

"Click on the Color button to change the text color."

"Here is how to setup the software. Edit the configuration file. Then install the Java Virtual machine. Finally, run the program."

Where did the "...ing" words go? They're gone, because I changed the text from passive to active voice. Notice also that I broke up the passive sentence into shorter, clearer, more concise sentences. This leads to another bit of advice to writers: Avoid run-on sentences. I will save that lecture for a future addition to our guidelines.

3. Your sentence has "is by".

"Setup IS ACCOMPLISHED BY..."

Note also that an above example started with "The text color is changed as simply as..." This is functionally equivalent to "is changed by". The writer added a few words to show that it is simple. This does not change the fact that it is passive.

Final Words

There are many other ways to recognize passive voice. If you are serious about being published on a regular basis, get yourself a copy of On Writing Well by William Zinsser or any of several books on writing style.

FAQs about Communicating with Linux Journal

Will you read this attachment in a word processor format?

Please send your mail as plain text. Thank you.

I'm using a challenge-response email system and didn't receive an answer.

Turn off challenge-response and try again. We do not answer challenges.

hey can u read my 31337 artical idea?!?

Linux Journal is looking for articles that use standard English grammar, punctuation, capitalization and spelling. Please use them in your email.

Why did you ask me to contact another Linux Journal staff person directly, instead of just forwarding my mail?

More often than you might expect, there's some kind of spam-filtering system, on your end or ours, that keeps you and the other LJ staff member from communicating. We need to find that out as early as possible, not if we have a question on your article later.

Our authors use a surprisingly diverse collection of spam-filtering systems, and the Linux Journal IT department has its own.

Can I write an article for you?

We're always interested in article proposals. The best thing to cover for a first article is something that

  • has never been done before
  • there's no documentation for anywhere
  • runs on all architectures
  • is based on universally available software or a short program included with the article
  • helps all Linux users
  • produces measurable performance improvements
  • makes a cool photo

You probably can't do all of these in one article, but the more of these you can do the better. If you are interested in several topics, select the one you feel you know best for your first article.

Please see the article process above.

Can I write an column for you?

We're not looking for columnists now. We are accepting proposals for individual articles, for hot topics and for series of two or three articles. Any future columnists will be selected from among the people who have written good articles.

What are the different email addresses for?

ljeditor@linuxjournal.com is the address for initial proposals and final submissions. The final version of your article must be sent to ljeditor@linuxjournal.com, NOT to any staff member's address. Staff members travel, but the ljeditor@linuxjournal.com address always is covered.

FAQs about the Article Process

Can I make corrections to my article after you publish it but before it is used in translation or in a compilation?

Contact us if you discover errors in your article after publication. We will make errata available and make an effort to incorporate corrections for later uses.

If you assign me a deadline date that corresponds to a future issue, does that mean the article will appear in that issue?

Unfortunately, we can't say for sure. We don't know for sure ourselves until the last minute.

Can I submit the same article elsewhere?

No. See Contract and copyright.

Can I submit a different article about the same subject elsewhere?

If you've written a similar article on the same subject for a different publication, you should let us know when you propose the article. After your article appears, we encourage you to re-purpose it, after the cover date of the issue in which it appears. It's a good idea to tell the editor of the other publication about it.

What about copyright?

The copyright is yours to keep. See Contract and copyright.

Why can't you say when my article will be published?

The size of Linux Journal is determined by how many pages of advertising the advertisers buy. For any given magazine title, the ratio of advertising to content is constant, within a few pages. So, the more ads, the more content. That means that we don't know, until we go to layout, how many pages will be available for content. If we plan and assign articles based on a thin LJ and the advertisers make it thick, we're in trouble. If we plan and assign for a thick LJ and the advertisers make it thin, we're safe. That means we have to keep a lot of good authors in suspense. But we're not fickle, just your conduit to the emergent fickleness of the advertisers and, in a sense, of the global economy as a whole.

FAQs about Article Content

Do you run articles that have appeared elsewhere?

No. The one exception is that we occasionally run excerpts of books, but this is rare. We do not run articles that have already appeared on a Web site. However, if you have an informative Web site about a topic, you could write an article about that topic.

What are your top reasons for rejecting article ideas?

This is a very general idea and not really suitable for Linux Journal. It would be better aimed at a publication for a non-Linux audience to give them an overview of the possibilities of Linux.

This idea is very similar to content covered in a large number of existing on-line resources and popular Linux books. We prefer to cover ideas that haven't been extensively covered elsewhere.

Binary-only device drivers or other kernel modules are a recipe for trouble. Linus Torvalds wrote:

There are no good excuses for binary modules. Some of them may be technically legal (by virtue of not being derived works) and allowed, but even when they are legal they are a major pain in the ass, and always horribly buggy.

I occasionally get a few complaints from vendors over my non-interest in even trying to help binary modules. Tough. It's a two-way street: if you don't help me, I don't help you. Binary-only modules do not help Linux, quite the reverse. As such, we should have no incentives to help make them any more common than they already are.

In general, Linux Journal is not interested in proposals for articles on binary-only kernel code or on hardware whose only driver is in the form of a binary-only kernel module.

The article has distribution-specific instructions for something that isn't or shouldn't be distribution-dependent.

There are no performance measurements to compare the solutions listed and justify your performance improvement claims.

We recently ran an article on this subject.

We can't accept articles that have appeared previously on the Web or in print.

This seems to be too close to product documentation or what should be in the product documentation.

This article idea is not sufficiently Linux-related.

This article is applicable to Java on any platform, not Linux. You may do better in placing this article with a Java developer publication.

We don't use "free software developers should do this" articles--there are way too many of these and people aren't going to pay $5 to read your rant about why the system you used in college had a feature that Linux doesn't and somebody should write it or Linux is doomed. Describe ongoing projects in important areas such as standardization, security auditing, accessibility and user interface design, and include what works. Show, don't tell.

Best of luck in submitting it elsewhere.

Please keep Linux Journal in mind for future article proposals.

In the future, it is better to send a proposal and outline before writing the finished article.

I have a great idea for an article on using (really common thing) with (really common thing to use it with)

That has been done very extensively already. For example, using PHP to access a MySQL database is a common subject for articles. You would have to bring something new to the topic to get this into Linux Journal. Perhaps combining those two technologies on an Esperanto-speaking giant robot that shoots laser beams out of its eyes?

What do I have to do to get you to run an article on my favorite language?

Most of the code examples in Linux Journal are written in C, C++, Perl or Python. However, we do run articles that introduce new languages. If we wanted to, we could fill up Linux Journal with articles that introduce some new language. So we have to be selective about which ones we run. In general we prefer to use an introduction to a new languages only if the article has powerful and understandable sample code that shows a compelling advantage of the language.

Here are the factors that help us decide whether or not to run language introduction articles that cover a different language.

  1. Is the language or toolkit used for one or more useful Free Software applications which readers would be interested in running and adapting to their own purposes?
  2. Does the language offer some functionality that makes it particularly suitable for use on Linux, or does it offer easy access to libraries that implement functionality of interest to Linux developers?
  3. Does the sample program presented in the article illustrate some capability of the language that is not present in our commonly used languages: C, C++, Perl and Python?
  4. Is the sample code in the article both useful and instructive?

What's the bug report rule?

Bugs are a fact of life, and we want to be fair and give software maintainers good reports to help fix them. It's the least we can do. If you mention a bug in software for which a public online bug tracking system exists, you must include a URL for a relevant bug report in the Resources section of your article. Submit the bug report yourself before submitting the article if necessary.

What should I use for example hostnames, e-mail addresses and IP addresses?

You may use unqualified hostnames, domain names that you control or, if you want to use a fully qualified domain name, use a domain name from RFC2606.  For example, ping -f mail and ping -f mail.example.com are fine, but ping -f mail.linuxjournal.com is not. Never use an unregistered domain in an example. Someone might register it before the article gets published.  Many contributors use their own domains in examples, and that's fine.  But commonly used examples such as foo.com and company.com are real domains, and we don't want to get our readers in trouble for port scanning if they type in an example literally, which is way too easy to do if the sun is coming up and you're still troubleshooting the mail server.

For example e-mail addresses, you can use local addresses (without the @) or addresses where the part after the @ is an allowable hostname.

If you include an example IP address in an article, use addresses listed in RFC1918.

The one exception is that you may use www.linuxjournal.com as the server in an HTTP example where the client is well-behaved, as long as you don't include the IP address, which is subject to change.

What are some confusing expressions to avoid?

acronyms
When introducing a new acronym, spell it out the first time, with the acronym in parentheses. You don't need to expand common acronyms on first use. Some of the common acronyms are: ATA, CD, CDROM, DVD, HTTP, IP (when used to mean Internet Protocol), SCSI, SMTP, RAM, TCP, WWW.
bashing legacy OSs
If you're trying to be an effective Linux advocate, it's much more effective to ignore other OSs--they're obsolete, after all--than to make a big deal out of the things you don't like about them. When you have to do something special to interoperate with a legacy non-Linux OS, be matter-of-fact about it and let the reader draw his or her own conclusions.
commercial
Do not use to mean proprietary. Often, a program can be both commercial and free--commercially supported as a business, but free to modify and redistribute.
compile, how to
Don't include lengthy explanations of compiling and installing programs. Usually people either can install from a package or follow the README file. A short mention of how to compile and install is fine to include in an article, but if you are writing about a program that is difficult to compile and install, please volunteer to fix it or write a better README instead of making the article a workaround for something that doesn't have to be difficult.
Free software
Do not use this term to refer to proprietary software that is available at no charge.
footnotes
We don't use footnotes. Please put the information in the body text, and put citations in a Resources section at the end of the article.
Hacker
Developers in /usr/src/linux/CREDITS and elsewhere identify themselves as "hackers" -- don't use the term to mean "computer criminals".
Latin
We don't use Latin abbreviations such as e.g. and i.e. Please use regular words. Don't use etc. to end a list of examples. Use "such as" and a comma.
links
Please put Web URLs in a separate Resources section at the end of your article, not in the article text.
Names of programs
Please include both the company or organization name, if applicable, and the program name on first reference. Say "Alias|Wavefront Maya" not just "Maya" and "Ximian Evolution" not just "Evolution."

What are you looking for in cover photos?

Vertical orientation is generally preferred. The magazine logo is placed over the upper 1/3 of the cover, so the central focus should be in the middle 1/3 of the image vertically.

It's also nice if some areas of the image are fairly simple so there are places for the cover copy to go without it having to compete with the background for visibility. We tend to have a fair amount of text on the bottom right of the cover, and the main headline and taglines are usually on the left side under the logo, though it depends on the image. Centered images can work well, but it's sometimes better if the main focus of the image is more to one side, with a less "active" area on the other side for the headline.

Ideally the image file would be around 300dpi at 100% (which for our covers is roughly 8.25"W x 10.25"H). We prefer TIFF files for covers, but PNG, or JPEG with little compression (maximum quality) is fine.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix