Thought experiment: design an open source new-hire process.

Little thought experiment today (pedagogy class is really getting to my brain): if I were creating a new-hire process for employees being assigned to work on an open source project, what would it look like? Here's a first pass; it's randomly improvised and not particularly well-thought-out, but fun anyhow; it's partially based on what I've (unconsciously) come to find myself doing each time I've launched into a new open source project over the past few years.

You spend your first week as a remotee, no matter who you are or where you'll end up working. You have exactly the same access to the tools and processes that a community member would have; no internal mailing lists, no magical "you're hired therefore you get the root password" shortcuts. If you want privs, you need to earn them the same way as any community member (or in some cases, when the hire is from the community, they'll have earned them already). During this week...

• You have constant access to orientation staff -- hopefully in-person, but at the very least via a remote medium you're already comfortable in. This is important; they're your culture/tools coaches, and their encouragement will help you buffer the inevitable frustration you're going to hit (new hires will be told ahead of time that it's going to be frustrating).
• You'll get training in remote collaboration tools if you don't already know them. Your project's IRC channels, bugtracker, wiki, version control system, etc... you're going to learn to use them. By the end of the week, you'll be lurking on your project's IRC channel(s), your blog will be feeding into Planet (and you'll have posted on it), you'll have introduced yourself on mailing lists, edited the wiki, triaged bugs... This is a lot like the material we teach in POSSE (actually, you could remix POSSE into this portion of such an orientation).
• Ditto the above to open source culture. Things like "release early, release often," "default to open," open source business models, "ask forgiveness not permission," and so forth will be brought up by your coaches.

The main point is that you're going to try to start doing your job without any sort of magical special "I'm an employee" powers (other than the fact that you're paid to work on this, which is a privilege that shouldn't be discounted). Inevitably, you'll run into issues; outdated documentation, discussions you can't overhear because they happened inside an office and someone forgot to send notes to a mailing list, information trapped inside the heads of your coworkers. Since you want to get stuff done, you're going to start poking your teammates to get documentation out there, to talk on IRC, to better practice the open source way and enable you to work as a "community contributor" -- and if they do, they're not just enabling you, they're enabling the entire community.

And that's your deliverable for the first week. You're going to try to get work done, and it's great if you can, but you're probably going to end up with a list of "things I can't access from the community world and need in order to do my job." Some of the things on this list may be legitimately internal; I'm willing to bet a bunch of them will be externalizable. It's going to be frustrating, but again, that's the point; you're going to experience exactly the same pain community members face, so that you'll know firsthand why it's so important to open them up once you do get "inside."

Oh. And you'll get through the normal new-hire paperwork and training (finance/payroll, legal, company history/vision/mission, etc) because some of that is stuff companies are legally obligated to do (I think).

You'll actually be allowed inside the office at the start of your second week, but only for 4 days a week. You can join internal mailing lists now, see private documents, that sort of thing. But you're still considered to be in training. Here's what that means.

• You'll still get ongoing modules on the culture/tools/practices of the open source way. Maybe you'll run an IRC meeting and get feedback on your meeting-running skills. Maybe you'll shadow a "community-experienced" coworker to see how he/she handles certain kinds of interactions and tools. Maybe you read a little writeup on the feature selection process in your open source community and then blog about it.
• When you learn something, you'll document it as a record of your learning. Publicly when possible, on a shared internal wiki (or something) when not.
• That one day a week you're not allowed in the office? That's your "community shift." You spend that shift helping community members get their stuff done. That list of "stuff I needed access to during my first week that wasn't out in the open"? Fix it. Hang out on IRC and answer questions. Review patches. Reply to mailing list posts. Triage bugs and thank reporters. Do some wiki gardening. Go to an open source event. Screencast a tutorial. You get to expense lunch, and you have to write a blog post (that will go to your project's Planet) about what you (and your team) have been up to for the week -- the stuff you can talk about publicly, that is.

Practicing the open source way is something that takes time and experience because it's a paradigm shift; it's about how you see the world, the subtleties of how you interact with it, and its effects are usually not immediately apparent. That's what you'll learn here -- it's easy to tell you, but in order to observe it, you need to live it.

You'll learn that "but I have nothing to contribute!" isn't true (remember, this is for all new hires, not just engineers). You'll learn that your beginner's mind is sometimes your most valuable asset. You'll learn how your work with the community can bring a lot of subtle little long-term leverage to your employer (and some not-so-subtle, huge, short-term wins, if you're lucky). You'll learn what it's like to welcome new people to the community in turn, and how quickly even a newcomer can become an even newer newcomer's "old hand" and mentor. You'll learn how much energy can be unlocked when you release a blocker and enable community folks to do stuff they're already rarin' to do.

This phase lasts for... some defined period of time. 3 months, 6 months, "until the release cycle you joined during is finished," whatever makes sense for that project. But at that point, you get your first review...

Your performance review is based on your public record. If it ain't public, it don't count. The things you'll bring before your boss are things like your git commits, meetbot IRC logs, wiki edits, list threads... your public portfolio of open source participation. If you don't have enough of a public record (where "enough" is some standard we define somehow -- I told you this was off the top of my head) then you remain in "trainee" mode for another round.

Once you "graduate" from new-hire training, you're no longer mandated to do "the open source way" training modules (or at least not constantly), and you'll be allowed in the office anytime. Maybe your "community shift" will shorten (half a day instead of a full day every week?) or maybe, depending on your role, it might vanish (although I would love to see, for instance, the new lawyer or accountant continue to lurk in IRC, comment on mailing lists, and so forth). Maybe on-site workers will still be required to take one "remotee week" a year in order to remind them; remotees are already typically expected to make trips to headquarters to meet folks in person at least that often, so why not reverse it?

Again, raw thoughtdump. Plenty of holes, I'm sure. I'm curious what people think - especially people who have careers in open source, or want them. Is this an orientation you'd sign up for? Is this an orientation you'd like your coworkers to have?