Contributors have always been a vital component to The New Stack. Since the site’s inception in 2014, we have had an open door policy for those who wanted to share their own views in a contributed post about what is happening in their corner of the tech community — be they a Fortune 500 company or a single hacker feverishly working on the weekends.

People like TNS because it analyzes and explains technology, with a voice that is positive, forward-thinking and cuts through the nonsense. We don’t talk down to the reader; we know our readers are intelligent.

Contributed stories are, at heart, an exercise in mutual exploitation. We want stories that offer our readers a little something for their time. Busy people, they are. They’re CTOs, project managers, developers, administrators and other technically-inclined IT pros who do not appreciate having their time frittered away on artfully-disguised marketing copy.

To clarify, we are NOT interested in generic “unbiased” thought-leadership posts, crafted by your marketing department. There are other outlets for those pieces. We expect you to biased about your own work — why wouldn’t you be? — as long as what you write is accurate as well.

We are primarily looking for three different types of contributed posts, with each format accentuating the contributor’s own specific expertise:

Tell us about your technology: Every creator of any open source project was originally inspired to fix a problem that was causing some sort of headache. In general, readers are more interested in first reading about the problem, rather than the solution. We want to hear from creators, in lurid detail, what that headache was, and then how their technology is uniquely suited to solve that problem. See, for instance, this contributed post of how the startup Iterative harnessed the open source git version control system in a heretofore novel way to speed up machine learning operations.

Tell us how someone else is successfully using your technology. Everybody enjoys a good case study. If you have a customer or user who would be willing to share some of the technical details about how your technology helped their operations run more efficiently, then that would be a story that many of our readers may find worthy. As an example, check out Couchbase’s post on how its mobile database software helped the Starlink global satellite bring broadband to remote places in the world.

Provide singular insight into a bit of recent news: When Amazon Web Services suffered from a severe outage in its Tokyo-based P-Northeast-1 region, it affected business across all sectors, and while it would be some time before AWS would issue a post-mortem, technical executives were all abuzz about the incident. Network resilience services provider Gremlin strapped in with a smart analysis of the situation that drew from the company’s own considerable expertise of knocking systems over and figuring out how to keep them running. It was a win-win, both for curious readers and for Gremlin itself.

If you are a standards group or an open source project, we want to hear what you’re doing. If you’re company with a unique technical perspective on the market, explain it to us in an elucidated, compelling way. If you’ve sussed out a better technique for getting your job done, we want to hear about it.

A contributed piece doesn’t have to be 3,000 words of heavy teaching. It can be 500 words outlining a technical epiphany, a handy technique, or a small lesson learned of some sort. Code snippets are fine, as are visualizations, and stats and metrics are always appreciated.

Please note: ALL post images/illustrations/charts must not be larger than 620 pixels wide (the size of the page) or 350 pixels tall. This includes feature images. If any images are larger in either dimension they must be reduced to either 620 or 350 pixels, whichever is the highest value. This change is to ensure faster web page load times.

We do accept tutorials with embedded code. Due to the limits of the WordPress platform, however, we have a set of rules for what we can and cannot support with embedded programming code:

• Code can not be colored, nor have any additional formatting.
• Only ASCII characters — not smart quotes.
• No HTML or any other code with an open or closed brackets.
• Code block space (i.e. tabs) is done on a best-effort basis: We can make no guarantees that code will remain in the structure provided This is especially true with tabbed code (We’re looking at you, Python).
• NO markdown.
• We encourage the use of third-party plug-ins where applicable, such as Asciinema, or dynamic gifs.

Please note that all contributed content we run must be original. We do not run posts that have already appeared somewhere else on the Internet. We also require a two-week window when we have exclusive rights to run that content. We ask this to ensure the material gets the highest visibility with our readers and with the search engines. After this time period, contributors are free to run the material elsewhere, such as on their own sites or on Medium.

Please also note that we can only accept contributions from a company or individual once every three months. We encourage those who wish to submit more frequently to chat with our sales department to find the sponsorship that is right for them.

So if you have questions, or want to submit something, hit us up here.