I don't claim to be the world's best interviewer: Most of the interviews I do are your basic information gathering sessions to fill in the gaps for a feature or news piece that I'm writing. If that's the kind of interview you're gearing up for, then the primary thing is to make sure you have a set of clear questions that will get the answers you need and to do the interview in whatever way will produce the most clear answers. (I prefer email for this sort of thing.)

But if you're trying to get the sense of a person, and convey more than some basic stats about them, you need to do a few things:

• Do your homework.
• Do your homework.
• DO YOUR HOMEWORK.

Too many folks show up for interviews with a set of cursory questions and hope that the the interviewee will just magically open up and provide a great interview. If you're doing an interview that you hope will matter, spend some time researching the person (or persons) you'll be talking to. Read their previous interviews if you can. Find out what they're usually asked and what they haven't been asked.

• Don't ask the same tired old questions that they've been asked before hundreds of times.
• Ask the interviewee what they want to talk about. You shouldn't be restricted to this, of course, but sometimes you might find out something interesting that no one else has touched on.
• If doing a phone interview or in person: Give the person plenty of time to respond, and don't jump in to fill every gap in the conversation.
• Have ample time to do the interview. This may not be entirely up to you -- if you're interviewing Mark Shuttleworth around Ubuntu release time, for instance, you'll probably have 15 minutes and then done. So make the most of it.
• Talk to other people, ask what they would want to know about the interviewee.
• Avoid leading questions. All too often interviewers come into the discussion knowing what story they'd like to write, and customize the questions to fit.
• Practice. If you've never done an interview or are just getting started, spend some time interviewing people you know. Write up a set of questions beforehand and do it "officially." Then look at what you have after the interview and ask yourself how that reflects the person you know. You might find your "stock" questions don't do enough to find out anything real about your subject.

Finally, put yourself in the interviewee's seat. One of the best tools to learn about interviewing is to be interviewed. I spent a lot of time doing interviews via email, phone, and in person while with Novell. Most of the interviews were the same question over and over. But a few of the interviewees were actually very on the ball and asked insightful questions and seemed to care about the answers. Those were the interviews that were most enjoyable and produced the best results, in my opinion.

Respect the interviewee's time, and that of your audience. If you go in with that at top of mind, you should do a great job whether it's your first interview or one thousandth.

                          

Please give me a shout if you'd like to help run the GNOME booth. Travel sponsorship may be available.

                          

Increasingly, projects like GNOME or openSUSE are in mainstream news, but finding someone to "speak for" those projects can be a challenge. This is doubly true when a site has no contact information for project "leadership" or stale information for the project.

As an example, I just pinged all the addresses on the GNOME Press Resources page -- and they're in a pitiful state right now. At an outside guess, I'd say that the page is at least three years old and probably older than that, and the bounces I just received reflect that. Luckily, I'm not on deadline or anything -- I'm just trying to get information and clean the page so that we have good contacts for any press who are researching stories about GNOME.

A reporter on deadline might not get a great impression about the project if they pinged some of these contacts because they'd either get a "recipient failed" note from everyone's favorite contact "Mail Delivery Subsystem," or they'd get (even worse) a "subscription required to post to this list" in some cases.

This is not the way to receive glowing press coverage. Hell, it's not necessarily the way to receive any press coverage at all.

If you're participating in a FLOSS project, make sure there's a prominent contact page where reporters, bloggers, etc., can find someone to talk to and get information from on very short notice. Some reporters are savvy and persistent enough to  hunt developers down in IRC if needed or stalk mailing lists to find the contact info -- but most won't, and the best you'll be able to hope for is "project could not be reached by deadline."

This also highlights the importance of attracting non-developer contributors to projects. Maintaining this sort of information and putting together PR plans is something that a few developers are good at and enjoy, but not very many -- and it's rarely a good use of their time in any event.

                          

The first step: Deciding if you really do want to be a professional writer. Let's start with a series of questions that you should ask yourself before considering writing as a professional activity:

1. Do you like to write, or do you need to write?
2. Can you write 2,500 to 3,500 publishable words a day, every day? (Or more?)
3. Can you generate topics quickly that you can write about quickly?
4. Can you hit deadlines reliably?
5. Really?
6. Do you like having your writing criticized or changed by others?
7. Are you good at marketing yourself?
8. Are you ready to run a small business?
9. Do you want to work in a field with intense competition and not enough work for everybody?

If the answer to question one was "I like to write," then game over and thanks for playing. No, really. People don't succeed as writers long-term because it's something they sort of enjoy doing -- for the same reason people who enjoy drawing or painting don't become famous artists, people who just sort of enjoy playing guitar don't become Eric Clapton. I promise you that if you don't need to write, you'll go from sort of enjoying writing to hating writing.

Take a weekend and see if you can do 2,500 to 3,500 words on Saturday and Sunday, each. Yes, while everyone else is out having fun. Repeat that for a couple of weekends. In a row. If you can generate 10,000 words of publishable work in a month, you might be a candidate to be a professional writer.

Topics -- if you're born to write, or have had it beaten into you somehow, you're going to see topics literally everywhere. If you're a subject matter expert in one or more areas, you'll be able to nail down topic ideas from the basics to the more subtle areas of your expertise. If you're a generalist, you ought to be able to think of topics you'd send to everybody from Reader's Digest to Make Magazine. (Maybe not those specifically, but if you're going to be a generalist freelance writer, you have to have a very wide net.)

This isn't a problem for tech authors, necessarily -- if you're lucky enough to be on staff as a tech writer, the topics will be assigned to you, but I don't know many folks who've landed tech writing jobs without a portfolio.

Deadlines: Can you hit them?

Criticism: Can you take it? This is something I see trip up a lot of first-timers. If you don't have a really thick skin, or if you feel that your writing is so special that it just can't be changed... you are not a candidate to be a professional writer. Editors will change your work. Sometimes for the better, sometimes for the worse, and sometimes just because they need to whack 200 words to squeeze your manuscript into a space. (Assuming you write for print...)

There's a word for writers who don't accept changes well: Unemployed. The editor assigning the story and the client writing the check get final say, and you should have very little ego about this.

That doesn't mean that authors have to accept every change or allow their work to be published under their byline if it's not something they'd be proud to put their name on. If an editor changes something and the result is a piece that's factually incorrect or something you'd be embarrassed to put your name on, stand your ground. But too many authors huff and puff because of trivial changes or because the "voice" of the piece has been changed a bit.

If you're lucky enough to work with an editor that does provide feedback, accept it gracefully and gratefully.

Next -- are you good at marketing yourself? Unless you are very, very lucky, building a decent client list requires aggressive marketing and pitching to publications and clients. If you're not good at this, you don't get work.

And are you ready to run your own small business? Because that's what freelance writing is -- running a business. You need to do the whole thing: Pitch the work, make the sale, close the deal, actually do the writing, do customer service with clients, have meetings, be the accountant, do the invoicing, handle collections if you're unfortunate enough to have clients who are slow to pay, and so on. You have to read contracts and decide how much you need to make per hour to make a living -- factoring in that you'll only be able to bill for time you're actually writing. Spending 40 hours a week working isn't the same as billing 40 hours per week.

Good rule of thumb: Expect to see checks roll in 30 to 45 days after the work is done. Sometimes even more slowly. This means you need to have a decent cushion for clients who don't pay quickly. If you're about to go into freelancing, I recommend a cushion of no less than three months, and six months is actually a better idea. You want a long runway if you don't land a lot of work right away.

Finally, realize that it's a very, very competitive field. A lot of people want to write for a living, and you're going to be pitching for the same publications and clients as a lot of other writers. And there are outfits like Demand Media that are consistently lowering the bar on quality and pay, making it that much more difficult to eke out a living when many clients and publications will settle for a low-quality content-like substance.

It might sound like I'm trying to discourage people from freelancing. Mainly, I just want to give a realistic view of what writing for a living entails. It's nowhere near as easy as most people think it is. It does come easily or naturally to some people, but it doesn't to most. Simply being a decent writer isn't the same thing as being ready to be a professional writer. If it's not something that you are fully committed to, you'll probably fail, and you'll certainly hate it.

                          

Traditional journalists might look down on this, as journalism programs really focus hot and heavy on front-line reporting roles and editing roles. J-schools don't focus on roles that look at existing information and putting that into context for readers, even though that's what a lot of publications are focusing on at the moment -- original and investigative reporting being rather expensive.

It might be a hard sell at first, since that's not prestigious work and probably not what a lot of people want to get into journalism for.

But making news accessible and ensuring that things are verified and in context... that's deeply important, too. Looking at it just from my beat -- the IT industry and open source community in particular -- a lot of projects are sort of self-reporting. Information is available from thousands of sources (seriously... my Google Reader feeds prove that...) that are far too disperse for most readers to see things firsthand. There's quite a bit of value in curating the news, when it's done well. Some sites already do this, to varying degrees of success. And it's certainly true that someone in a pure curator role is not looked at as a journalist in the strictest sense -- but maybe they should be.

A good example of this would be Groklaw. The Groklaw folks do some original reporting and investigation, but the site is primarily about curating the SCO case and related information. It's obviously proven valuable for a large audience. And I'd argue that it's journalism working just as it should. If Groklaw's not being taught in J-schools now as a case study for the future of media, it ought to be: maybe it isn't a model of for-profit publishing, but it's showing what can be done with new tools and a community of interested contributors with a few curators at the helm.

A bad example of this... well, I don't like to point fingers. But there are plenty of linkroll sites where the editors / moderators don't practice any verification or use reasonable judgment in publishing links or stories. Sites that pose as gatekeepers should have moderators that actually do some vetting of stories and be more responsible about what they link to. I see too many sites that play up any "controversy" or give a very loud soapbox to people who really don't know what the hell they're talking about.

It might be difficult to get the public as fired up about other important topics as Groklaw's audience is, but it'd be interesting to try.

I do disagree with Mike Masnick's conclusion that "if a newsroom were set up with a focus on these three roles... I doubt we'd see newspapers struggling as much as they are today."

Maybe newspapers would be struggling a tiny, little bit less. But the problems newspapers face are not simply due to changing roles in the newsroom -- the financial system that has supported newspapers has collapsed. Sites like Craigslist have devastated the revenue model for some papers. Advertisers are less interested in supporting traditional media.

But the reporter, columnist, editor, curator newsroom has some promise. I hope that this idea catches on.

                          

Not-so Classy App Store Apps

Just read that Apple has tightened its restrictions on all the crap "boob, babe, and bikini" apps in the App Store. What took so long?

I get sick of seeing all the crap apps in the App Store, especially when Apple restricts legitimate but "competing" applications. If Apple is going to play gatekeeper, then they should exercise a bit of quality control and block these skeezy and useless apps from the phone. A few examples are to the left. OK, the iBearSoft application and iPlummet Free apps don't look too offensive. I'm not really sure what they do but they don't look offensive.

"Asian Hot Sexy Girls," and "How to KISS DIRTY!" apps, however, do. According to this eWeek story, Apple's SDK says no to any apps with "obscene, pornographic, offensive or defamatory content or materials of any kind." The apps here probably don't rate as obscene or pornographic, but they're definitely offensive.

But Apple hasn't been enforcing this policy consistently. Apple's SDK policy isn't new, and these apps have been allowed in the App Store for a long time. I think these apps are scuzzy, but it's also unreasonable to allow the apps into the store and then bump them back out again later because of a change in the wind in Cupertino. Techcrunch has a link to a list of items which will, suddenly, be off-limits. No boobs, no babes (well, no uncovered ones), and no bikinis.

As far as I'm concerned, that's hunky dory: But Apple should have communicated this sooner. It doesn't seem reasonable to me that Apple would accept these for so long and then suddenly do a 180. It's not as if one or two lone apps have slipped through: The App Store is rife with this kind of thing. Do a search for "sexy" or "strip," for example -- you'll see plenty of adult-oriented content that's obviously adult-oriented. It's not like these slipped through: So what's with the sudden change?

I've said it before, and I'll say it again: If I were an app developer, I'd be very wary of basing my business on the iPhone. Technically, it's a great platform. Apple has done a really good job of showing people what's possible on mobile computers. Unfortunately, the company has also shown that it's unpredictable to do business with.

                          

Keep It Tidy

Webmasters are often asked to look after HTML documents that were produced by other folks using WYSIWYG editors or word processors like Microsoft Word. Although the use of such editors and word processors simplifies production for many people, the HTML produced by these programs is usually pretty ugly. It might be acceptable in a browser, but it's downright unpleasant to maintain.

In my case, I use DocBook for a lot of documents and SGML&Tools to render HTML from DocBook markup and then tweak it slightly. Although the HTML looks just fine in a browser, it's kind of ugly when you open it up in Vim. Running the output through HTML Tidy makes it easier to read and leaves you with "valid" 4.01 HTML.

Here's a short before and after example of HTML Tidy's handiwork:

DissociatedPress.net


DissociatedPress.net

Site Guide

...

< !DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN">











DissociatedPress.net

...

Cleaning up after WYSIWYG programs and conversion tools isn't the only thing HTML Tidy is good for, of course. Tidy will also validate your files and correct them, if necessary. You can also tell Tidy to simply check for errors without making any corrections.

Using Tidy

Obviously, the first thing to do is obtain HTML Tidy. It's available from SourceForge and also should be packaged for most Linux distros. SourceForge.net hosts binaries for several flavors of Windows, and for Mac OS X. The site includes links to Tidy binaries for platforms as diverse as Amiga and Atari. (Is anyone still using Atari?) You can also find Windows executables and Linux RPMs.

You can also compile Tidy from source, which is what I usually do when installing Tidy on a new box. It's available under an Open Source license, so if you want to pass it on to your friends, tweak it, or include parts of it in a larger program, you're free to do so, as long as you follow the license.

Running Tidy on a UNIX-type OS is as easy as:

tidy file.html output_file.html

If you want to modify the file "in place" -- that is, write the modified HTML to the same file -- then you'll use the modify (-m) option:

tidy -m file

However, Tidy has many options that you may want to take advantage of. You can pass arguments to tidy on the command line, or you can set up a config file. If you're going to set up a config file -- which I recommend if you're going to use Tidy frequently -- you can either specify the filename on the command line:

tidy -config myconfig.txt file.html output_file.html

Another way to do it is to set the HTML_TIDY environment variable with the name of your configuration file, like this:

export HTML_TIDY=htmltidyconfig.txt

Alternately, you can put it in your .bashrc (if you use bash) to set the variable every time you log in. Here's my config file. It's fairly short, and I'm happy with HTML Tidy's defaults for the most part.

//Zonker's HTML Tidy Configuration File
// I set wrap to 0 because I don't like to wrap HTML.
// The default is 66, you can set this to whatever value you want.
wrap: 0
indent: auto
indent-spaces: 2
wrap-php: no
clean: yes
drop-empty-paras: yes
enclose-text: yes
// This puts any "orphaned" text inside the paragraph element.
// Prevents massive ugliness when using stylesheets.

If you're using these options on the command line, it would look like this:

tidy -c --wrap 0 --indent auto --indent-spaces 2 --wrap-php no --drop-empty-paras yes --enclose-text yes

From Windows to the Web

Tidy has several options that are designed to take files created in Word, or other Windows programs, and clean them up for the Web. One of those options is the "char-encoding" option. By setting the option to "ascii" or "latin1," Tidy will convert characters to entities that will display correctly in all browsers. For instance, when set to "char-encoding: ascii" (the default), Tidy converts any characters above 127 to entities. When set to "char-encoding: latin1" Tidy converts characters above 255 to entities. This is a good way to get rid of characters -- like the alleged "smart quotes" -- that won't display properly on *nix systems and replace them with entities that the browser will understand.

Tidy also has a "word-2000" option that can strip out the fluff from HTML documents generated in Word 2000. This is particularly handy when you're getting documents from marketing that need to be cleaned up and put on the Web. The folks in marketing can write in a tool they're familiar and comfortable with, and you can translate that document to valid HTML quickly and easily. Everybody's happy.

Much of this content was originally part of a Tool of the Month column for UnixReview.com. Since the content is only available from Archive.org at this point, I've cleaned it up a bit and reposted to keep it available.

                          

Who? When? Why? What? Where? How? If you don't answer those questions, why bother blogging at all?

The "Five W's" as they're often called (and one H) are drilled into every journalism student as crucial for news-writing. Who is involved? When did it happen? Where did it happen? How and why did it happen? And, for all that's holy, what happened.

Every news story should answer these questions. So should every post on your blog. This doesn't mean that posts need to be boring, inverted-pyramid style jobs with just the facts. Use your own voice. Ramble if you like. Show us a few cat pictures with funny text. Bury the lede if you need, and write about whatever strikes your fancy. But for the love of $DEITY, tell us what happened, to who, why, when, how, and where.

I skim a lot of "Planet" Web sites for FLOSS projects from Debian to openSUSE looking for things to write about. Presumably, each blogger wants to convey some information to the rest of the world. Yet so many leave so much out.

A common sin is writing about a project update without bothering to give even a one-liner explaining what the hell the project is or does. Yes, I've even been guilty of this myself. Just today, I've run across at least three posts that discuss updates to this or that package, but utterly fail to say what the package is or does excepting the name. Now, if the assumption is that I follow that developer's blog religiously, then I would obviously know what that package is and the information would be unnecessary.

Don't assume that people will be reading your blog in the context of the project or be even slightly familiar with you or the project you're writing about. Like me, they may have come in via the planet feed for the first time and this is your first (and perhaps only) chance to catch that user's attention. Maybe they've come into your blog via a Google search result, or a link off of Twitter. They could come from anywhere, and you have this one chance to connect with the reader. Don't blow it by failing to explain what you're talking about. Every reader that says "oh, that's lovely, foo was updated. Wish I knew WTF foo did in the first place, but I'm a busy person and don't have time to dig into this. The developer obviously didn't care enough to explain, so it can't be all that inclusive a project" is a lost user.

For open source developers that write about something frequently, consider writing up some boilerplate text to stick in each entry about an update or new feature. Again, it doesn't have to be pretty. You don't need to be a fancy wordsmith to do the job: Just make sure that the reader knows who, what, where, when, why, and how. Consider just tacking something like this onto posts:

Project Foo is a widget that provides X, Y, and Z features for users of Bar. It's open source, and source is available over here, packages are there. The home site contains (link) documentation (link).

It would take less than five minutes to write up something like that, but it might just make the difference between losing or gaining a user -- and ultimately, a contributor.

                          

If you appreciate talented guitarists, classical music, and/or the works of J.S. Bach, you really ought to give this one a listen. Really good music to have on while working, reading a book, or just to listen to.

As with all things Magnatune, you can have a listen before buying. Grab one of the streams from the Magnatune page or just give it a listen right here in the Flash (sorry) player.

JS Bach on 8 string guitar, vol 1 by Daniel Estrem

                          

Mozilla Messaging is looking forward to a big year in 2010 including Thunderbird 3.1 and figuring out how to make the project financially sustainable. Making Thunderbird better is the easier part. Figuring out how to make money as a project is another story entirely.

No doubt the next release of Thunderbird, currently code-named Lanikai, will do a lot to win users. Lanikai will focus on making the upgrade from Thunderbird 2 more gradual, and improving on the Thunderbird 3 platform. This means fixes for IMAP, stability and memory improvements, interface enhancements, and improvements to message filters and Smart Folders. The 3.1 release is avoiding disruptive changes and the team is shooting for a May release. The bigger challenge ahead for Moz Messaging is how to pay for itself.

Read the rest on OStatic...