All work-from-home gigs are not created equal. There is a vast ocean between being a member of a distributed team and just being a remote worker.

The groups of "remote worker" and "distributed team member" are neither a super-set nor a sub-set of one another. Insead, they can be represented as a typical Venn diagram.

Remote Worker

A remote worker is someone who simply isn't in the office. He's off on his own. Somewhere.

When you're a remote worker on a team, you might be the only remote worker on that team. If you've worked on a traditional team, but suddenly got moved to Montana to tend to your family's bison ranch, and your employer didn't want to let go of you, you're a remote worker.

The other 11 guys on the team are not remote workers. And you're not on a distributed team at all.

Distributed Team

A distributed team simply means that you and the vast majority of people you interact with are not near each other. No mention of "at home" is included in this definition.

If your company has 20 offices scattered across the globe, and your team has a member in each, you're a distributed team. You all might be sitting in your cubicle at each office, so you're not automatically remote.

But you might as well be.

Why it matters

When I joined Twine.com, my coworkers and I were all remote, every last one of us. That forced our team to be distributed. And it worked fantastically well.

After an injection of funding, offices were opened in San Francisco, and most of the team relocated. Except me.

I was suddenly just a remote worker.

When the team is distributed, all communication happens on an equal footing for all members. You use IRC, mailing lists, bug-trackers. You're forced to not rely on hallway conversations or lunch-break chatter.

Everyone can participate equally.

When you're a remote worker, on the other hand, you completely miss out on many communications channels. A dozen people are in a conference room scribbling on the whiteboard, and you're listening blind on the crappy speakerphone.

Not fun.

Adding more remote workers to a non-distributed team actually only increases problems and frustration. You simply have more people who feel alienated and isolated.

Breaking over to a majority of remote workers, though, forces the team to reformulate as a distributed team. They rework their habits, expectations and workflows. And ultimately, the team functions better for it.

Doing Distributed

Skills needed by distributed teams are the same skills developed by participants in open-source projects.

Communication occurs through "permanent" and "public" means (within some scope) such as mailing lists and IRC. These may be purely internal lists, but avoids much of the point-to-point communication between individuals.

I've found IRC invaluable to my team, in that it helps form that group atmosphere, even though we're hours apart. During the workday there's technical discussion, random chatter, jokes, and other interactions that help avoid isolation.

Distributed teams also need to select tooling that not only provides a technical function, but also one that they will actively use and can provide additional communications channels. A by-product of using a tool correctly is group memory and knowledge. For instance, notes attached to bug reports or issues in JIRA and messages in the commit logs all should contribute to institutional memory.

When a non-distributed team doesn't have to rely on these methods, substituting the water cooler instead, they actually lose this benefit in a severe way. Distributed teams end up functioning better because they must be better-organized if they wish to function at all.

Another upside to distributed teams is that there's always a back-channel.

A team of 10 meeting their boss or another stakeholder in a conference room have to communicate through facial expressions, nods, winks, hand gestures, and dramatic sighs.

Distributed teams just open another IRC channel for chatter, clarifications, objections and contributions amongst themselves, behind the boss's back.

Bottom line

Remoteness just adds problems. But distributeness solves a lot of problems, including that of being remote.

All teams could benefit from the same practices of distributed teams, but they're ultimately lazy and often don't.

Being a remote worker is not fun at all. Being a member of a distributed team is beyond awesome.

I've had a handful of discussions recently about working from home. Some conversations have centered around hiring people onto my own distributed team, others have revolved around the method one uses to land a work-from-home gig.

Here's a collection of my thoughts. I enjoy the conversations, but blogposts are more easily shared.

Don't apply for office jobs

The first question I get is "how do you get work-from-home jobs?" The easiest answer is that I apply for them. Conversely, I don't apply for jobs that require a particular location or presence in an office.

This actually makes the job of finding a job much easier. I can immediately discount pretty much everything on all the various job-boards normally used for technology positions.

Some folks would consider that a down-side, though, since you're limiting your options. There's 1000 jobs out there, but you find 997 of them distasteful because they require you to be in a certain place.

If you're going to be that picky, you've got to make sure you can win one of those rare few jobs that allows you to work from your back patio.

Don't apply for jobs near offices

If you live in San Francisco and apply for a Bay area job, it's truly difficult to maintain the "I only work from home" mentality. If you're capable of dropping into the office with ease, you'll probably be asked to.

Live in a rural area away from airports. It gives prospective employers more trouble asking you to come in for even one day each week.

Be able to work independently

If an employer is simply trying to turn a staff of 20 engineers into a staff of 21 engineers, to add some marginal capacity, you're screwed. They're looking for quantifiable "engineering resources ", The kind that don't have to work independently.

Assuming there is a spot that requires independent working, and the employer thinks you could fill it remotely, you need to be able to convince them you're capable of it.

The employer fears you'll wake at 11, work until 4, and take a 2-hour lunch. And that you'll not let them know the schedule is slipping until the deadline arrives.

Saying "No, really, I'm great at working from home" doesn't do all that much to reduce their fears.

Proving you can work independently on projects from home works a lot better. This can be done one of two ways:

1. You've done it before, at a previous job that lasted more than a year, and was more than one-day-a-week remote.

2. You've done it before, as a major contributor (or leader) of an open-source project.

This first option is the best, but presents a chicken-or-the-egg scenario.

The second, on the other hand, is completely within reach of every engineer with a pulse. I'd even venture to say that if you can't create and lead an open-source project, you'd probably have difficulty actually working from home.

If you want to show prospective employers you can maintain the discipline to work independently, from a remote location, nothing beats an open-source project.

If you have no project now, get started. In two years, you're going to be two years older anyhow. You could be sitting in an office, dreaming of working from home, or you could be working from home because of that project you started today.

Have the jobs find you

Since you're now the leader of a successful open-source project, you're no longer just "an engineering resource". You're that guy, you know, the one who leads that project.

Your interactions with your project now builds your network of people who know you, specifically. And they know your work, specifically.

Now, the thing is, chances are you'll never actually get paid to work on your open-source project. The goal is not to find someone to pay for your open-source work. The goal is to use your open-source work to find someone who will pay you to do whatever it is they need.

Don't get hung up on finding a "sponsor" for your project. Instead, you're hoping to find an employer who values and appreciates the work you've shown yourself capable of. They see you as a smart cookie, and they want to apply your smarts to their interesting problems.

The real point is to build your reputation and your network. Employers will decide that you're the guy they want, and they'll contact you.

Work open-source jobs

Since you're now an open-source zealot, there are plenty of gigs out there with companies centered around open-source. And these companies with open-source in their blood and in their culture are much more open to remote workers.

It's the cool thing, lately, for VCs to funnel millions of dollars into companies who pay engineers well to give software away for free. The economics might not always make sense, but it could be a good job, at least for a while.

Once again, your own open-source project may or may not fit into their portfolio. The goal is to work from home on interesting problems. Running your own open-source project is just a means to that end.

Be prepared to travel

Assuming you've successfully landed that work-from-home job, and you live hours away from any airport or office, prepare yourself for some moderate amount of travel.

I find it exceedingly difficult to insist on "work from home" and "no travel". Since you're a non-fungible person, not just a random "engineering resource," sometimes you specifically will need to be somewhere. Maybe you do have to fly to the office, or a client, or a conference every so often.

For me, that's a 90 minute drive and two airplanes, anytime I have to go somewhere. It takes its toll. It's a trade-off you do have to be willing to make.

But at least you lose the 90 minutes of commute every day.

My story

I started out contributing to open-source as a way to learn C++. I wrote a massively concurrent make-style build tool, as open-source, which landed me my first job.

I wrote a handful of open-source projects and created the Codehaus to collect them.

I created (along with Mark Proctor) the Drools open-source rule engine, and sold it to JBoss.

I worked for Twine.com based on my reputation in open-source.

I joined Red Hat based on my experience with Drools and open-source in general.

Now I do have the job where a company is "sponsoring" my open-source projects that I work on from my front porch, in a farm-town with 5 stop-lights.

I'm not a morning person by default. Life claims otherwise, though, so I've had to figure out how to wake up at a reasonable hour. Which is even more difficult when you throw in a little jet lag.

I play the typical games of setting my alarm 9, 18, or 27 minutes earlier than my target wake time. This gives me at least 1, 2 or 3 snooze cycles before having to drag my self out from the warm embrace of sleep.

Though, I'm amazed at how efficiently my sleep can adjust to a regular 9 minute interruption, and blow right on past my target wake time.

At best, I'm 9 minutes late. Sometimes it's more like 27.

I use my iPhone as my alarm clock, docked next to the bed. Thankfully, it allows for multiple alarms. I've now taken to setting my typical N-snooze alarm, to gently ease me towards getting up. But now I also set a secondary backup alarm a mere two minutes after I really want to be awake.

By breaking the 9 minute cycle, the quick secondary alarm is like your mother standing over you, not letting you sleep the day away.

When the 2-after alarm goes off, my mind registers that I'm "late" since it's after the target time, but I'm not panicked since I'm not that late. Yet.

This is what I do to most successfully get up around 7am.

Today I've relaunched (yet again) my blog.

I'm trying to retire my old fnokd.com domain, because it's hard to type, hard to spell, and doesn't really mean anything.

So, in trying to shuffled everything over to mcwhirter.org, I've now got the Fnokd! site ported over to Awestruct.

This includes some modifications to Awestruct to support cool stuff like tag clouds. Pretty happy with how dynamic a static site can be. Mix in IntenseDebate for comments, and a pile of static files works impressively well.

For those of you keeping track at home, that means you can find stuff I write here and at a variety of other places:

• http://cloudpress.org/
• http://torquebox.org/
• http://rubyunderground.org/
• http://awestruct.org/

I announced the TorqueBox project today.

It's the coolest platform for your Ruby applications, ever. Really.

Just a reminder, in case anyone didn't make the jump..

My Ruby/Rails/JBoss blogging is going on over at Odd Thesis these days.

That includes this announcement about the 1.0.0-Beta-2 release that just popped.

Over the summer, I relocated to a farming community in southwest Virginia. Around the middle of August, the Starbucks that'd been under construction finally opened, to much rejoicing. I've spent many a dollar and hour in that store, enjoying a lovely beverage and the fast internet.

Over the Thanksgiving holiday, we drank up all the ground coffee at the house. Heading into town to get more on Saturday night, we managed to show up 15 minutes after the store closed, just as the workers were about to leave. We'd assumed they were open until 11pm, not 10pm, on a Saturday. We were wrong.

Nonetheless, a worker named Thomas sent his coworkers on home, dragged me into the store, and insisted on grinding the 2 pounds of coffee I was in need of.

He gave them to me on an IOU, since the registers had been counted and closed. I returned the next morning to pay my coffee debt, after enjoying some of the fresh-ground joe.

Sure, it's sometimes fun to demonize the corporate coffee culture, but at least the Wytheville Starbucks feels like a local coffeeshop, populated with our neighbors on both sides of the counter.

I'd wanted to praise Thomas to the store manager, but I've missed him every time I've been in since Saturday. So I figure a blog would suffice, too.

Of course, this happened after we'd spent the holidays driving down to Georgia and back, stopping not once, but twice at Starbucks that had been shuttered. Billboards along the highway still proclaimed "Exit here, turn left!" But it turns out they were billboards of disappointment, as those stores had been downsized in September.

I was glad to return to my hometown, neighborhood Starbucks.

Just when I've trained my boss to read this blog to keep up with my status, I go and launch another blog, specifically for my workstuff. In addition to blogs about JBoss things, it'll include other documentation for building, installing and using the related projects. The projects are grouped into constellations based around theses. Hence the name:

In addition to being a new blog, it's also my attempt to eat my own dogfood and prove it all works in the Real World.

The Odd Thesis site runs entirely on the JBoss-Rails stack.

I'll still blog random crap here at fnokd, but if you're looking for my JBoss experiments, add the Odd Thesis feed to your reader. I've initially imported appropriate posts and comments from this blog.

I did the round-trip from the land of cows to Raleigh to attend the Raleigh RubyCamp over the weekend.

I think I heard about 80 folks showed up, but I'm not certain on that.

Mark (root@37s) and James did a very nice job of organizing it. They provided good coffee and donuts to start the morning right. Krispy Kreme is never a bad idea.

We gathered, and a handful of folks presented introductions about what they wanted to do a session on. We then figured out the slots, and got started.

Brenton Leanhardt talked about Genome and Cobbler, two emerging technologies at Red Hat. Cobbler helps to stitch together distributions, Kickstarts and repositories, while Genome helps manage the inventory of virtualization hardware and the guest instances running on them.

His use-case for the technologies is the fact that we've got Xen hosts running on machines scattered under desks and in closets, which have been donated to a virtual pool.

Where did you launch that instance last month? Where can you launch a new instance today? Genome helps answer those questions. Many of the Genome bits are Camping apps.

I presented my short slide-deck about JBoss-Rails.

Mark Imbriaco led an open discussion about Rails deployments. It ended up mostly being us asking how 37signals did things. He described their hosting environment, their occasional frustrations with Mongrel, along with some stories about running migrations against a 100gig database.

Sean Cribbs talked about his experience in joining and then leading open-source projects, particularly Radiant CMS. He discussed breaking up the core into many plugins and modules, and the uptick in community participation that followed.

Overall it was a great weekend, and I even got some nice t-shirts out of it. Not bad.

Thanks to the typical demo demons, I've been unable to get everything functioning perfect for instantaneous clustering on EC2 by tomorrow.

Oh well.

But here's the first draft of some slides I'm taking with me to the Raleigh RubyCamp.

It's a BarCamp style event, so I anticipate the slides probably changing throughout the day. I'll published updates if needed.