Published: Sep 21, 2024 by Richard Sezov
My blindness to the difference between creating at the keyboard and formatting a document came from all the business writing I was doing. In 1997, I’d made a career change from server administration to software development. I’d begun coding, first on Lotus Notes platforms, and then on Java. By the turn of the century I’d switched jobs and was lead developer at a Fortune 500 company. One of my first assignments was writing an RFP, or Request for Proposal.
An RFP is a document that describes a business problem the company wants to solve, and potentially the platforms and/or tools it wants to use to solve it. This document is then sent to outside consulting firms who compete by sending their proposals for solving the problem along with how much it will cost. The company then picks one of them to do the job for the price quoted. Business writing had been my thing for a while, and an RFP was an easy first assignment.
Here’s the thing: companies tend to have templates for everything, and this RFP was no different. I didn’t have to create anything from scratch; the template already had all the sections I needed to complete. In other words, the creating was inexorably mixed with the formatting. Logos, headings, and sections were already in place; I only needed to replace the placeholders with my own text. I fired up Microsoft Word (the company standard, of course), opened the template, described the problem in the proper sections, outlined possible solutions and the tools we wanted to use to create them, and completed the document.
I was surprised and pleased; my supervisor said it was the best RFP he’d ever seen. Of course, as a writer, that isn’t saying much—an RFP is hardly a challenging document. But it was the latest example in a pattern I’d been following for years, a pattern that did not lend itself well to my original dream of creative writing.
This pattern led me to reject the idea of text processing and find my next word processor, on Linux: StarWriter, part of the StarOffice suite. A German company, probably frustrated (like everyone else) at trying to release the stranglehold Microsoft Office had on the industry, decided to give their office suite away and sell support only. The company was purchased by Sun Microsystems (according to Wikipedia, for less than the cost of licensing Microsoft Office for all their desktops) and became an open source office suite, first called OpenOffice, and now called LibreOffice.
StarWriter (now just Writer) had everything I’d been accustomed to: WYSIWYG editing, scalable fonts, layout features, and more. There was nothing I couldn’t do in Writer that I could do in any other word processor I’d used, including Microsoft Word. My wife wrote her dissertation on it, formatted precisely to specifications.
I had my Linux-based word processor.
Over the next decade, I switched jobs a few more times. At each job I was forced to use both Windows and Microsoft Word, but at home I could use Linux with my KDE desktop. I was a Java developer, writing more code than text. I used my word processor as both a place to put words and as a page layout program, like everybody else. My desktop had given way to my first laptop at home, and I didn’t need to tinker much with hardware anymore.
In 2007, everything changed again. I got a job for an Internet startup, an open source company called Liferay. I’d been hired to do their documentation, full-time. Finally, I’d gotten the opportunity to combine my writing skills with my technical knowledge. I was employee number 47. Now I would be working with the software and writing about it every day. It was a daunting task; Liferay is a huge piece of enterprise software, capable of running websites for the largest of companies, and chock full of features.
Naturally, I turned to my writing tool of choice: LibreOffice Writer. I’d decided I’d write books, and since I was the only person doing this, I could use what I wanted. I wrote three editions of the documentation and did the layout with only LibreOffice Writer as my tool.
At some point, of course, books and PDFs weren’t enough. Liferay needed fully indexed and searchable documentation on the web, not in a book. Not only that, but I now had a team, and we did more than just documentation; we were also responsible for developing the training material. For both the documentation and the training material, we used LibreOffice. The training slides were created in Impress, and the documentation in Writer.
It was (and still is) difficult to create an editorial process of multiple writers collaborating with each other and sending final edits to an editor (me) in LibreOffice. I wanted to see the history of the articles, what was changed, and who changed it. I wanted to compare the old version of an article with the new version. We needed new tools to do that, and our own company showed the way.
Liferay was in the middle of migrating its source code repository from Subversion to Git. Git was revolutionary at the time, and it started to get very popular. Where other source control systems placed roadblocks on developers by locking files, overwriting changes, or forcing crazy merges, Git freed developers to work. It could make many merges automatically; everybody had the complete history of the source, and it was nearly impossible to overwrite the history.
I realized that Git offered everything I wanted in an editorial process: I could see the whole history, all the changes, who made them, and the delta between an old version of a document and a new one. We could work together easily and merge the changes. The only problem?
We would have to switch to plain text.
More on that in the next part.
Part 1 of this series is here.
Part 2 of this series is here.
Part 3 of this series is here.
Part 4 of this series is here.
Part 5 of this series is here.