To write for us, please review and follow this guide. We welcome article ideas or drafts about Open Source software and hardware as well as open data, open science and open knowledge. 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, science, data and knowledge.
Readers of OpenSource.net are technical and non-technical. They come from many different geographical regions, backgrounds and fields of study.
If the main focus of your submission is to promote a product or your company, we’re not the right publication for your article. We focus on stories about open projects, technologies and communities – we do not endorse products. When we mention companies or products we generally link to Wikipedia entries, not the company or product page. 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 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.
OSNet editorial guidelines
We’re excited to work with you on stories for OSNet.
We cover Open Source software and hardware as well as open data, open science and open knowledge. Our goal is to tell engaging feature stories about these topics – and the people behind the projects.
Successful pitches answer these questions:
- Why this story?
- What’s the “open” angle?
- What’s important about this – and why now?
- What are we adding to the general knowledge base? We avoid repeating stories that have been done many times.
- What are you bringing to the story: Is it general knowledge of a project, professional expertise, or weekends of tinkering? Tell us why we should assign this story to you.
A special note about products: If the primary purpose is to provide a backlink or boost sales to your company or product, we’re not the right publication for your article.
Sample pitch that doesn’t work
Example: Top three markdown languages. This article aims to give an overview of Markdown-it, CommonMark and Pandoc and say a little about the strengths of each one.
A quick web search shows that the top results are click-baity:
And then results are a list of markdown editors, markdown guides, etc.
What are we adding to the community by publishing another one of these? Probably not much, given that OSNet’s objective is to be read by humans, rather than optimized for clicks. There’s also no information about why the person pitching would be a good fit to write it.
If you’re interested in writing about the software you use, we’re less interested in articles featuring content that should be in manuals. We want to know why you should use it, what are the advantages? What unique tricks have you discovered to solve a cool real-life problem?
For example, we want to know how you used LibreCalc to track temperature and humidity in your garden to maximize vegetable growth but we’re less interested in an instructional post on how to build simple charts in GNUplot.
If you want to run a series on spreadsheets, describe what readers will learn/be able to do by the end of it: Is the series contributing knowledge that’s already been widely covered? Most people don’t care that much about using only OSS when it’s often not as attractive/functional or easy/common if you’re collaborating with certain workplaces. And while most of our readers are pro-Open Source, it’s always preferable to think about how useful/interesting it is for a wider audience and in general.
A good pitch answers these questions, even briefly.
Sample pitches that work
Here are a couple of examples:
- How will the GDPR impact Open Source communities? Many organizations are scrambling to understand how changes in the law will impact their work. I’ll cover the main parts of the regulation that impact the Open Source community, such as consent, right to be forgotten, right to access and breach notification. With the law coming into effect in just a few weeks, this will be a timely primer for your readers. I’m a lawyer with three years experience in Open Source.
- Open source means a lot of things to a lot of people. That may be why it’s also one of the most misunderstood and misused terms in tech. We’re launching a podcast called “My Open Source Experience” and we’d like to write a post about what we’re doing and why. Ideally, the publication would coincide with the launch in two weeks. The hosts have a combined 25 years of experience in the Open Source community.
- In 2017, I started an Open Source project called OpenAvalanche to reduce deaths worldwide using machine learning to increase the accuracy of forecasts. I’m currently looking for community contributions with experience in ML and AI. Would you be interested in featuring the project? We could time it for this year’s International Day for Disaster Risk Reduction in October.
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)
- The publication is OpenSource.net or OSNet
- 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 the 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 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 .md, .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.
Editorial workflow
Incoming requests automatically have NEW status. The Editor-in-Chief reviews incoming tickets, changing the ticket status accordingly:
- NEEDS EVAL: the pitch requires review by another team member, an Agent (for example, an article that requires technical expertise)
- ON HOLD: the pitch needs further evaluation, the agent hasn’t decided how to respond but it has been read and the ticket shouldn’t be touched by anyone else but the Agent assigned
- COMMISSIONED: the pitch is accepted, accompanied by instructions on how to proceed
- REJECTED: the pitch is not acceptable. Process ends here.
- NEEDS INFO: the pitch requires more details or tweaks from the submitter
- EDITOR OK: the article submitted is ready for publication
- IN PRODUCTION: this status means the OK’d draft (and all associated images) needs to be moved into a post for editing
- SCHEDULED: the article has been edited and is ready for publication. Process ends here.
