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

Introduction

Linux Journal publishes articles about Linux and adjacent topics. People read Linux Journal to learn how to do things on Linux they couldn't do before. And, since Linux supports everything from watches to data centers and rockets in space, the range of possibilities rounds to infinite.

We're also tough editors. We want only the most interesting, accurate and well-written pieces. For news, we want reports that are not just timely, but more authoritative and deep than readers are likely to find elsewhere. For features, we want the same, but without a near-term expiration date on reader interest—in other words, pieces that are still fresh six months or a year from now.

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.

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. Query letter should include a brief write-up or outline describing what your article will cover. Please also indicate when you think you'll be able to complete the article (in other words, will you need a couple days, weeks, a month or more?). Send your query letter to us here.
If we like your article idea, we will send you a deadline and an assignment letter, which will include all the submission information.
Submit the article to us here. We will let you know as soon as we can whether the article has been accepted.

Contract and Copyright

All writing is done on speculation. By submitting your article, you agree to these terms. 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.

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

You can't use your article for other publications or for your website.

Article Types and Lengths

Feature/In-Depth: This is a how-to, success story, essay or in-depth/comparative review that includes some or all of these: sample code, screenshots and photos. Features and in-depth articles are typically 2000-3500 words.
Shorter Pieces: Brief reviews (real-life evaluations of a Linux-related product or book), introductions to new Linux and FOSS projects, news commentary, tech tips and mini-how-tos. Typically 500-1000 words.

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 in the article or in code, 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 70 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.

Image Formats

Send images as PNGs or JPEGs. Be sure to include a caption for each image.

Items to Include with Your Article

Each article should include a brief 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. Please also include Twitter and/or Facebook handles so we can promote you.

We also need your mailing address, which is not published, in order to send your payment.

Be sure to include two "teasers" for each article--brief descriptions that summarize what the article is about and entice readers.

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

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.

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.

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.

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 a column for you?

If you're interested in becoming a regular contributor, please contact us. 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.

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?

We have a team of reviewers that votes right before layout on which articles will be used in the digital magazine. We don't know for certain which ones will be chosen until right before layout. Sometimes we do have a good idea of what will go in an issue ahead of time, and sometimes we will assign articles on timely topics and we will do everything we can to get those articles published quickly.

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 your personal website or a website other than the LJ site. However, if you have an informative website 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.

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 too "markety".

This article doesn't sufficiently cover what makes this topic/product/what-have-you compelling.

This article isn't appropriate for LJ's audience.

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 OSes: If you're trying to be an effective Linux advocate, it's much more effective to ignore other OSes--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.

Alternate Titles: If you can't decide on a title, include more than one.
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 a previous screenshot.
Image Suggestions: Please include suggestions on what sort of image would go well with your article (see the main page of our website to see how each article is accompanied by an image.