# Writing with open source

Writing is one of primary ways we communicate, and I think it's endlessly fascinating to see how different writers work.
I can hardly imagine writing before computers, or the ability to instantly edit and rearrange the words I've typed onto a screen.
Likewise, I wonder whether someone who started writing on a typewriter processes their thoughts differently even on a modern word processor, or whether their workflow has changed and adapted because of these new tools.

We asked some of our correspondents how they get their thoughts into comprehensible words, and what open source tools they prefer.
As you might expect, we got a different answer from everyone who answered.


## Text editors and word processors

Many of our authors prefer text editors.
Then again, opensource.com works a lot with [Markdown](https://opensource.com/article/19/9/introduction-markdown) during pre-production, so there could be some bias.
Text editors are popular choices, though, probably in part because of their relative minimalism and in part because of the separation between style and content.

Word processors are popular, too, because they enable authors to keep all their work in one file.
For instance, an ``.odt`` file is actually just a ZIP file containing XML documents and metadata.

### Matthew Broberg

I use VSCodium (or VS Code) with this amazing extension that gives shortcuts for Markdown behaviors I keep a folder on my laptop called writing where I keep articles in progress in GitLab.

Write, iterate, git commit, and back up to GitLab.

Alternatively, when I want to keep everything in a cloud-based solution, I keep my work in [Hackmd.io](https://hackmd.io) or [Etherpad](https://pad.riseup.net).

### Jason van Gumster

I keep myself tied to the terminal when writing.

Writing happens in [vim](https://opensource.com/resources/what-vim), with a handful of plugins (my base ``.vimrc`` [lives here](https://github.com/Fweeb/.vim)).

For version control, I use Mercurial.
I’ve used Git before for writing, but Mercurial just tastes better to me for creative work.

I use ``wdiff`` for seeing word-level differences between versions.

When writing away from the desk (doesn’t happen much these days), I write on my phone with a bluetooth keyboard. Using [Termux](LINK TO MY TERMUX ARTICLE) on Android, I can get a full terminal and still have access to vim and Mercurial with all my command line toys.
When interfacing with book editors, who still predominantly rely on a DOC-based workflow, I have to convert to DOC/DOCX (using Pandoc), and then work in LibreOffice to reconcile their notes.


### Seth Kenlon

I use [Emacs](https://opensource.com/article/20/3/getting-started-emacs) and write mostly in [Docbook](https://opensource.com/article/17/9/docbook).
I use [Git for version control](https://opensource.com/article/19/4/write-git).
I maintain a custom stylesheet in XSL along with custom Makefiles to transform my Docbook source into plain text, HTML, EPUB, and PDF.
When writing for Opensource.com, I often write in [Commonmark](commonmark.org/) for its simplicity, but for text I myself have to maintain, then I keep the source in Docbook.

### Joshua Allen Holm

It varies slightly depending upon what, and for whom, I am writing.
The basics look this this:

* Research gets organized in [Zotero](http://zotero.org), where I keep full-text copies of the PDFs and websites I need to reference.
* Writing is done either in [LibreOffice](http://libreoffice.org) for academic stuff, where I need to include citations, or [gedit](https://wiki.gnome.org/Apps/Gedit) when I write Markdown (for Opensource.com articles and the like).
* My works in progress are stored in a ``Writing`` directory, which is organized into subdirectories based on what the writing is (for example, ``Writing/DistroWatch/Fedora 32 Review`` or ``Writing/Opensource.com/Summer Reading List``).
* An in-progress directory is version controlled with ``Git`` and also copied to a flash drive that I store in a fireproof case at least once a week.
* I make a PDF copy of every web-based article I write using the finished, published article and attach it to my bibliography in Zotero. Ditto for things that are not web-based, but the process is less tedious. I export from LibreOffice to PDF, or else I just take the publisher’s final PDF, whenever possible.

## Planning tools

One of the most effective ways to write something with a predictable outcome is to outline first.
Not everyone does outline first, and yet the end result is often just as good.
The trade-off, however, is that writing with an outline often gets completed sooner.
With an outline, the logical flow of an article or paper gets determined while input is still minimal.
You don't have to sort through paragraphs and paragraphs of information, you only have to move headings.
As you fill in the gaps between headings, the flow of the article becomes clear, and you can adjust immediately as needed.

There are many open source tools for working on an outline.

### Kevin Sonney

My workflow is almost all in Joplin. Research, Notes, todos, etc all using the built-in functionality, with sync to all my devices.
I write in Markdown, and submit that as a stand-alone document.
Screenshots use the built-in OS screenshot tools generally, and editing of those happens in [Gimp](http://gimp.org).

### Seth Kenlon

I use [org-mode](https://opensource.com/article/20/4/emacs-org-mode) for outlines, because they're so easy to rearrange both in terms of their order and inheritance.
I've been experimenting with writing in org-mode entirely, but because so much of the content I write ends up going to Markdown in the end, it seems silly to introduce any unnecessary conversion steps.

### Jason van Gumster

Thoughts and brainstorming in mindmaps with [vym](https://sourceforge.net/projects/vym).
It's not terminal-based, which is unusual in my writing workflow, but it's quite handy for organizing and planning.


## Stay flexible

In all the answers we got about how people write, one common theme kept emerging: a willingness to experiment.
Unsurprisingly, it seems that our writers are eager to try out new technology and new systems, even if it means having to temporarily slow down personal productivity to learn something new.
Sometimes, the net benefits are worth it.
And when they're not, the worst thing that's happened is that you've learned a new tool.

This is important for writers and also for computerists in general.
Technology changes.
Linux and open source do amazingly well to ensure backward compatibility and the ability to opt out of change, but eventually we all have to grow.

Not only does this ensure that you're up to date on the latest tech developments, but it just may inspire you to [write your own article](https://opensource.com/how-submit-article) for opensource.com.
Here's how correspondent Kevin Sonney sees it:

> Honestly, my workflow is pretty ad-hoc.
> Something looks interesting? I make a note that I might want to write an article on it some day.
> When I have time, I do so.

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.