Insisting on FOSS Doesn't Mean Annoying Others

When we are enthusiastic about something, it's easy to get religion about it and evangelize to anyone in sight. You may not go so far as to stop people on the street to tell them they ought to migrate to your beloved operating system or preferred open source application (though I did volunteer time demonstrating OS/2 2.0 at my local CompUSA during my Team OS/2 days and I arranged a few InstallFests). However, when you're trying to get others to buy into your message (such as convincing the boss to adopt an open source application), there's one important lesson to learn: make it easy for them. Don't foist your choice upon others. Or at the very least, find out what business colleagues need or want before you deliver something in a non-standard way (such as anything other than the proprietary format expected).

A recent experience brought this issue to mind, with me as the wounded party. (Fortunately it was a very small wound. Just a little scrape, really.) The incident highlighted a lesson that I wish more people in the open source community would grasp. I'm obviously an open source fan, but if I weren't one, this guy's behavior might have made me a little less willing to accept it.

[ See also: Convincing the Boss to Accept FOSS ]

I'm an editor (elsewhere) as well as a writer and blogger (here). A technology expert wrote a brilliant article (yay) for me at one of those other sites, which he sent in HTML. The author (who obviously is an open-source-only guy) did more than use <em>s and P-tags (which can be helpful). He went much further: His HTML article had pretty formatting and a navigation bar and links and such. Really, it was a well-designed webpage which would have made Steve Krug proud.

However, getting an article in HTML did me no good at all. My editorial process usually includes at least one round of author review. That is, I edit the draft, doing everything from correcting grammar to tightening prose to asking questions. In this case, I had to spend an hour cleaning up the HTML and putting it into Word so that I could use Word's revision marking. Yes, Word. Among book and magazine editors (non-fiction and fiction), Word is the traditional tool (on the Mac, for me), though I do know some editors who use open source word processors. (Remember how Sodom and Gomorrah might have been saved had they had just ten non-sinners? I sometimes think that God did not smite Redmond long ago because Word's revision marking is such a well-implemented product feature. Yes, other word processors, including open source ones, have revision marking. As someone who lives-and-dies by the editing process, I can say firmly that none implement it so well.)

I'm sure that my author thought he was doing the right thing by sending the article in HTML; he's written elsewhere about his methods for writing books using open source software. (You note that I'm not identifying the person; my purpose isn't to embarrass him, especially since I think he's a brilliant guy, but to make a point about open source acceptance to you.)

In my author's view, what matters is the final product that the customer receives. Software is distributed as a CD or DVD, perhaps downloaded for installation on a server. (Web developers will agree with this, since what matters to a client is working software that gets the job done, not the tool used to create it, making open source an ideal solution.) For a book, he wrote, the final product is delivering a manuscript to the publisher, "perhaps in a format such as HTML or PDF."

But be careful about your assumptions of "the final product." My author didn't take into account that while he may think PDF or HTML are useful formats, I do not. The article he sends isn't the final product. I need something that I can edit with a user interface that can highlight the changes I suggest (where I delete meaningless phrases like "the leading software solution for the new century" anytime I see them), and I need a way to comment on his text ("Did you mean to say 'scum sucking bottom feeders' here? Would 'lawyer' be more clear?"). I usually give an author a chance to fix my inaccurate corrections. The author review process highlights the queries and lets the writer accept or reject my revisions. (See, I am a kind editor; I remember it's the author's byline and not mine.)

Plus the pretty formatting is a waste of time, since when I post articles I use rather plain HTML and the CSS that the site supplies. Any time he spent choosing fonts truly is wasted because I'm responsible for formatting, not him.

I'm not suggesting that the author should acquire Word. But if he's going to use something that's non-standard, he should (a) ask if I can read the file (a surprising number of authors assume that I can read OpenOffice), at least one day before the article deadline or (b) supply it in a format that he's pretty sure I can use (some have sent me Google Docs, which is workable — but I still bring it into Word to highlight revisions). Most word processors can save in RTF (rich text format), an established standard that, among other things, does a good (or at least adequate) job at maintaining and working with revision markings. There's nothing wrong with an author using an open source tool and saving it in a format that is easy for me, and I'm glad to send a file back in RTF if that's what he's able to use.

The lesson here is that while you might appreciate open source, and you might be willing to go a little out of your way to use it, you should never assume that your customer or client or boss is willing to make the same compromise. In this case, the customer is me, and I am a kind and gentle soul who would never damage a writer's ego intentionally. (And if you disagree with my self-assessment, I'll beat you up.) Or if you don't want to believe in my essential goodness, at least consider that my workflow lets me write back and quibble over formats. Instead of getting cranky at my author, I wrote a blog post. Others — such as those with whom you do business or for whom you work — may not be quite as understanding.

You probably should follow me on Twitter. Because, y'know, you just should.