To write for us, please review and follow this guide. We welcome article ideas or drafts from Open Source technology users and subject matter experts. Learn more about how to be a part of our community.
All content is licensed under a Creative Commons BY-SA license unless otherwise noted.
Get started
Audience
Opensource.net accepts articles about software, hardware and topics related to open culture and open knowledge.
Readers of Opensource.net are technical and non-technical. Many are Open Source and/or Linux enthusiasts and users. They come from many different geographical regions, backgrounds and fields of study.
If the primary purpose of your submission is to provide a backlink to your company or product, we’re not the right publication for your article.We focus on stories about Open Source projects, technologies, and communities – not products. Although a product pitch isn’t a good fit for us, there may be a great story about how you’re using or giving back to Open Source at your organization that we’d love to help you tell.
The final word: Keep it simple, focused and timely.
Article types
A few general guidelines:
- 500-600 words: Around 500 words might suffice for a project update, to announce a new conference or share other timely Open Source news.
- 600-800 words: This is a good range for a regular feature article, column submission, interview or roundup. Consider adding a sub-head or two to break up the text and walk readers through sections of the article.
- 800-1,300 words: How-tos, get-started guides, tutorials and more thorough roundups that go a little more in-depth tend to be longer than feature articles.
- 1,300+ words: If your article is much longer than 1,300 words, consider breaking the story up into multiple parts.
Style guide
Our editorial team aims for correctness and consistency. We follow Associated Press style, in line with the Open Source Initiative.
Make it easy to say “yes!” to your article by following some basics:
- Write out numbers below 10 (nine, eight and seven)
- Format dates as December 1, 2014 (not December 1st, 2014)
- Place periods and commas inside quotation marks (except in code samples)
- Capitalize the first letter of Opensource.net
- Upper case and do not hyphenate Open Source (not open source, opensource, or open-source tools)
Grammar and spelling
Our editorial team reviews each article for grammar, spelling, formatting, style and more. To streamline the publishing process, please proofread your draft and adhere to proper grammar and American spelling conventions.
Jargon watch
You may know your LBaaS from your VPNaaS, but never assume the reader does. The momentum from emerging tech comes from people new to it—don’t push them away with the acronym-of-the-nanosecond.
Spell out acronyms on first reference, especially those specific to the technology or community. A new reader shouldn’t wonder whether a PTL is a project technical lead or one of the other 58 meanings on acronymfinder.com.
Links
All stories need links, so please submit your story with some. Make sure they point to useful information. If the highlighted portion for the link is a working breakfast session at a conference, link to that specific session or a write-up of the session – not the main conference page.
A few more examples:
- Include links to Open Source projects mentioned in the article or to a Wikipedia page describing the project on first mention.
- Explain or link to other Open Source licenses, organizations, standards, etc.
- Include links to technical ideas and terms that may not be known by a non-technical audience.
Formatting
Subheads: If your article is longer than 500 words, consider adding subheads to break up the text and make it easier to read. Use <h2> and/or <h3> headers. If your article is longer than 1,300 words, we might consider breaking the article into a longer series.
Interviews: Use bold for the questions and regular formatting for the answers.
Code formatting: If your article contains code, please delineate it with the <code> tag and our editorial team will confirm the proper formatting before publication. If it’s a short piece of code, the name of the function, or some other small snippet, leave it in-line within a paragraph, but longer chunks should be broken onto new lines. Do not use blockquotes or the <pre> tag for code samples.
Avoid using phrases like “in the code below” or “in the code above,” because layout is never guaranteed. Instead, follow a consistent pattern: introduce a block of code by identifying what it does, then show the reader the code. If necessary, provide additional explanation for complex or confusing parts. When writing multiple code samples, introduce each one separately.
Tables: HTML tables don’t resize to fit screens, making them difficult to read on mobile devices. Use bullet lists instead.
Images
Every article published on Opensource.net has a lead image. If you’d like to suggest a one, be sure to include image attribution and licensing details.
Inline images: Inline images and screenshots add visual interest, may help to illustrate your article and break up the text. If you include images, be sure that they match the license for your article (our default is Creative Commons BY-SA 4.0), or let us know what the license is and that you have permission to share on our site.
- Attribution: Include image credits and license details when you submit your draft and images.
- Format: Submit images as files, attached to your pitch or draft. Do not place images inside the draft.
- Size: No larger than 1920×1080.
- Label images: Label images so editors can easily tell where each image should be used within an article (mylinux.webp).
- Add captions (if applicable): Be sure to reference in your article text where your image should go and what the caption should read. (For example: [mylinux.webp] Caption: This is a screenshot of my Linux desktop.)
- Avoid using screenshots of text as images. Screen readers used by the blind can’t “see” text embedded within an image, so if what you’re trying to demonstrate in a screenshot can be better expressed as a code block, use text instead.
- If you provide images, use descriptive terms when naming image files and include the file name in the article draft where you want the image placed. Send image attribution information for each file.
Submission guide
Original content
If your article (or a version of your article) has already been published on another site, please let us know. Generally, we publish original articles, but we’ll consider reprinting articles or running a revised version. In any case, we need to know upfront whether your submission has or will also appear elsewhere.
Document format
You can submit articles as .odt, .txt, .docx file attachments. If you send a link to an Etherpad or Google document, do not revise the document after you submit. We download and edit what you send us, so we won’t see your changes.
Review process
Send your draft or pitch by using this form. Include the license for your work. Our default is Creative Commons BY-SA 4.0 but we’ll consider other licensing options on a case-by-case basis. To register for an account, fill out this form. Be sure to add a bio and photo, then save.
The editorial team will review your submission and respond with next steps. If we’re interested in your idea, we’ll get back to you as soon as possible. Unfortunately, we’re not able to respond to everyone.
Publishing timeline
Our editorial team carefully reviews, edits, and prepares articles before publishing them. If your submission is approved for publication, revisions may be requested. The editorial team will make copy edits and more in-depth suggestions if needed.
Typically, we publish articles in two to three weeks after the final revision is approved by the author. If you have specific expectations about the publication date of an article, or if it contains embargoed information, let us know when you pitch or submit it.
