The story of writing the JRuby book together, with lessons for freelancers, telecommuters, and remote collaborators everywhere. Speaker notes from Open Source Bridge 2011.

1. How 5 Authors
How Five Authors With Four Day Jobs
in Three Time Zones Enjoyed Two
Years Writing One Book
This is the story of a big collaborative writing project. I’m telling it for selfish
reasons—not just the obvious ones like drawing attention to the book, but also for
the less obvious, more therapeutic reasons. This thing took over our lives for two
years; after something that big, having a bit of a verbal catharsis can help bring life
back to normal.
Of course, this hour we have together needs to be worth your while as well. So
as the story unfolds, I hope you’ll feel some of the joy I felt collaborating with these
really talented people. I hope you’ll be entertained at our setbacks—an appropriate
response, especially considering there was no harm done and it all worked out in
the end.
If you’re a freelancer, a project manager, a telecommuter, or a member of a
remote team, you may find the arc of this project familiar. Perhaps some of the tools
and techniques we used along the way will be helpful to you as well.
By the Numbers
What do those numbers in the title mean? The five authors are:
1. Charles Nutter, one of the two co-leads of the JRuby project;
2. Nick Sieger, a core contributor to JRuby and many of its libraries (such as
Rails integration);
3. Tom Enebo, contributor to JRuby since 2003 and co-lead of the project;
4. Ola Bini, a prolific polyglot programmer; and
5. Me (Ian Dees), a happy JRuby user and the only non-core team member in
the group.
1

2. How 5 Authors
The four day jobs are:
1. Sun Microsystems (Charlie, Nick, and Tom),
2. Engine Yard (Charlie, Nick, and Tom),
3. ThoughtWorks (Ola), and
4. Tektronix (me).
The three time zones are:
1. PST (me),
2. CST (Charlie, Nick, and Tom), and
3. CET (Ola).
The two years (plus): June 2008 through October 2010
The one book: Using JRuby
2

3. How 5 Authors
Before I get to the story, let me tell you about my awesome collaborators.
Dramatis Personae
Even though most of us knew one another, this was the first time this specific
group of five people had undertaken a project together. Each author’s personality is
of course the same across projects (one hopes), but each person’s role in this
particular project might be something unique.
My own role in this process was “the guy who talks to the editor, deals with
technical reviewers, keeps the voice consistent across chapters, and merges
everyone’s contributions into the work.” My first mistake in this project was not
recognizing that this was as much a project management role as it was a writing
role. So when you hear me saying things later on like, “We were spinning our
wheels,” what that really means is, “I screwed up.”
3

4. How 5 Authors
The other authors’ roles emerged from their writing styles. For a chapter
introducing a broad technology, you can pair a theoretician (who has all the
answers) with a newcomer (who knows what questions to ask). For a survey of
several related software packages, you can send a lone wolf into the wilderness to
explore them all and bring back some insights.
So, here’s a tongue-in-cheek take on the roles my collaborators played in this
project.
Ola—The Prospector
Hand him a map that says something like, “Explore the Shoulda basin near the
end of Testing canyon.” He’ll disappear into the wilderness for, like, two weeks.
He’ll then come back with a twelve-pound chunk of gold, plunk it down in the
mining camp, and say, “Smelt that, baby.” Ola was off and running when the rest of
us were still tying our shoes. When things were bleakest, we’d still see the glint of
his pickaxe swinging in the darkness.
Tom—The Analyst
He prefers to tackle a large problem in steps: walking around it, considering
every angle, learning by writing code, and finding all the gotchas. Once that’s in
place, he’ll weave a compelling narrative around it. Tom doesn’t finch when
presented with a daunting charge like, “Find out everything there is to know about
user interfaces in JRuby.”
Charlie—The Professor
He has a library of code examples at his fingertips, ready to demonstrate any
nuance of the subject. His writing style is a smooth alternation between idea and
demonstration. “You may encounter obstacle X. For instance, consider the
following example. The solution is to do Y, as in the code below….” Charlie’s
greatest gift to the book was his sensibility. He has a great feel for when it’s time to
stop explaining some complex facet of JRuby and instead just fix JRuby to remove
that complexity.
Nick—The Conversationalist
4

5. How 5 Authors
He leads you through the text, and connects ideas back to previous concepts.
He checks in to make sure you’re still with us. He challenges you with questions
about what you’ve read. It makes for a smooth, engaging flow. This kind of writer is
invaluable for noticing what’s missing, anticipating what the reader will ask, and
filling in gaps.
Ian—The Yak Shaver
I’d love to write that half chapter on the compiler. But first, I’ll need to come up
with some examples—which I’ll try to compile. It won’t work quite right, because
I’ve stumbled onto an edge case that isn’t implemented yet. I’ll dive into the JRuby
source and create a patch… and so on. When you have one of these on your team,
sic ‘em on all those miscellaneous tasks that you don’t want to fall through the
floor: wrangling the schedule, poring over the results of copy edits, etc.
Now that you have a feel for the people behind this project, let’s talk about how
it all happened.
The Startup Curve
It makes sense to tell this story chronologically. You get to experience the project
trajectory with us in some sense, for better or worse. I’d like to refer to an image
that really captures the feel of this trajectory.
5

6. How 5 Authors
This is the famous “Startup Curve” that stood on a whiteboard at Y Combinator
for a few years. Paul Graham drew it, and Trevor Blackwell added the whimsical
annotations. People have reposted it and reacted to it over the years because it
captures so heartbreakingly the arc of starting a company—or at least perceptions
of starting a company.
Here’s a little more legible version:
6

7. How 5 Authors
The Process Upside of
Buyer
Acquisition
Wearing Off of Liquidity
TechCrunch
of Novelty
of Initiation
Wiggles of
False Hope
The Promised
Trough of Land!
Sorrow
Releases Crash of
of Improvement Ineptitude
I stumbled across this graph near the end of our project. It was a punch in the
gut. Here was something that captured, immediately and viscerally, the heartburn
and triumph of a big endeavor. If we imagine the Y axis to be something like morale
or velocity or mojo (instead of web traffic) and rejigger the labels a bit, we get
something like this:
7

8. How 5 Authors
The Process
Release!
Conservation
Harshness of Momentum
Euphoria of Reality
of Kickoff
Wiggles of
False Hope
Establishment
Trough of of Rhythm
Sorrow
Nagging of
Stakeholders Abandonment?
This is such a descriptive arc for our project that I’m going to refer to it
throughout this talk.
8

9. How 5 Authors
How It All Began
Let’s start off with the story of how it all began.
Harshness
Euphoria of Reality
of Kickoff
In 2007 or so, the JRuby project was gaining enough momentum and
popularity that it was time to ask, “Shouldn’t the core team write an official book
on the subject?” They decided the time was right, and began (I’m waving my hands
here) planning and outlining. This was before I joined the project, so the history
here is vague by necessity.
Ola and I had met previously at FOSCON (the predecessor to Open Source
Bridge!), and he was kind enough to do a technical review of one of my other
projects a few months later. That’s probably how my name came up when they
were looking for a co-conspirator on this book. In any case, the five of us sat down
together for the first time during RailsConf in June 2008, at the awesome Doug Fir
lounge.
The goal: figure out what this thing was that we’d be making.
9

10. How 5 Authors
The Definitive Book
The team wanted to write the definitive JRuby book. What does that mean? Is it
an exhaustive reference? A tutorial? Does it cover the internals? Who’s it for—Java
people or Ruby people?
One approach to writing a definitive work is to be exhaustive—to cover every
facet of the project. Indeed, an early draft of the table of contents explored that
approach:
I. Introduction
1. Introduction
II. JRuby and Java
2. Ruby 101
3. Java from Ruby
4. Ruby from Java
III. JRuby and its Environment
5. Standard Libraries/Yaml
6. Configuring / Running JRuby and components
7. Inside JRuby
a. JRuby architecture overview
b. The JRuby Interpreter
c. The JRuby Compiler
d. Java Integration
e. The JRuby API
f. Extending JRuby
IV. Working with Data
8. JRuby and JDBC
9. Working with XML
a. REXML / JREXML
10. Web Services / SOAP
a. RSS / Atom
b. XML Builders
V. JRuby and Rails
11. Rails Overview / Brief Tutorial
12. Rails and JDBC
13. Deploying JRuby on Rails
VI. Testing in JRuby
14. Junit, Test::Unit, Mocking / Stubbing
10

11. How 5 Authors
15. Using RSpec
16. Benchmarking, Debugging
VII. Other topics
17. JRuby and Security
a. JRuby Security Overview
b. OpenSSL
c. JavaSand
18. Working with Application Servers and Frameworks
19. Creating Swing applications
20. Tools
There’s nothing wrong with this outline in the absolute sense; it would have
made for a perfectly fine book—just not the book we were going to be able to
write. What forced us to narrow the scope was that all five of us were supremely
busy with our day jobs.
The scope of the book was the major source of discussion at our dinner table
that evening. I still have the notes I took as Charlie and the gang answered my n00b
questions like, “Who’s this book for?” “What kind of book do they need?”
11

12. How 5 Authors
Here’s a cleaner version of the first page:
12

13. How 5 Authors
… and the second:
13

14. How 5 Authors
Here’s what that looks like when we condense it to an outline:
I. JRuby
⁃ Basics / Installation
⁃ Java from Ruby
⁃ Ruby from Java
⁃ Compiler
II. Libraries
⁃ Rails
⁃ Hibernate
⁃ Rake
⁃ Swing
⁃ JMX
⁃ JMS
III. Appendices
⁃ Ruby 101
⁃ Contributing
14

15. How 5 Authors
Here’s what the finished book looks like (minus a couple of obvious things like
the bibliography):
I. JRuby
⁃ Basics / Installation
⁃ Java from Ruby
⁃ Ruby from Java
⁃ Compiler
II. Libraries
⁃ Rails
⁃ Hibernate + Databases
⁃ Rake + Deployment
⁃ Testing
⁃ Swing
III. Reference
⁃ Ruby 101
⁃ Configuration
⁃ C Code
⁃ JMX + Sysadmins
It’s amazing what having a simple rallying cry did for morale. With a clear idea
in our heads, we were ready to get to work.
Work vs. “Work”
The original discussion wasn’t just about chapter ideas. We also decided on a
few tools, based on how we expected to work together. This should have been a
yellow flag: “how we expected to work together.” This was the first time this
particular group of five had taken on a project—how on Earth could we have been
able to predict what exactly collaboration would look like for us? Not surprisingly,
not everything on this list stayed in our toolbox for the duration of the project.
The conversation went something like this: “What communication medium do
you use the most?” “IRC, probably.” “Okay, let’s set up a channel just for us.” “I can
do that.” “What about logging and searching? If someone makes an offhand remark
that turns out to be important, it’d be nice to be able to remember and find it later.”
“Yeah, I can set up a bot for that.” “What about large files?” “How about Google
15

16. How 5 Authors
Groups?” “Yeah, we should have one of those. I’ll set it up.”
And so on.
Has anyone ever seen or been part of an open source project that’s gone like
this? “My project is: I’m going to write a brand new operating system. Step 1:
register a GitHub project. Step 2: get a Lighthouse account for bug tracking. Step 3:
set up the wiki. Step 4: create a mailing list….”
All of these things feel like work, but none of them are work! The lesson here is
know what you need your tools for before you choose your tools. Otherwise…
well, I’ll tell you.
Tools, and How to Throw Them Away
Over the two-year course of this effort, we tried a lot of different technologies
for collaborating. Some of them served us well from beginning to end. Others got
set up and then abandoned. (That’s not necessarily a bad thing. An experiment that
proves a result you didn’t expect is still a successful experiment.) Still other tools
didn’t really prove useful until we changed how we were using them.
Here are a few of the things we tried in the beginning.
IRC
IRC has been a great medium for the JRuby core team to answer coders’
questions. Since everyone was so comfortable in IRC, and since it was a place
where the core authors were very likely to be at any given moment, we figured it’d
be a natural fit.
There are some differences between using IRC as a help forum and using it as a
coordination tool for writers, though. For one thing, with only five people using the
room there’s never a critical mass of voices to keep the conversation going. For
another thing, we had troubles with logging and searchability—if someone said
something crucial in the heat of discussion a month ago, anyone who didn’t
happen to be in the room out of time was out of luck.
It turned out that e-mail did a much better job at searchability and “what’d I
miss?” recovery. Sounds obvious in retrospect, doesn’t it? What can I say, we were
16

17. How 5 Authors
new at this.
Google Groups
We had high hopes for big collaborative tools like Google Groups. We got the
bright idea that we needed a place for stuff that was temporary (unlike source code)
but needed a home (unlike e-mail). Think chapter/author assignments, audio files,
etc. We had an initial flurry of migrating stuff here from e-mail attachments, and
then total neglect. We were just too small a group of people to get much use out of
this. And as for chapter/author assignments? Reality was much more fluid than a
spreadsheet could capture.
Skype
The hardest part about getting started with the book was deciding what we were
going to write. The one guy with the most writing time (for the moment) was the
one who knew the least about the subject matter. Fine for writing the introduction
and a few chapters on specific technologies, but when an obscure question came
up on Java method overloading—we needed to talk.
E-mail has slow turnaround time. With IRC, we’d have to compete with the
dozens of people in the #jruby chat room next door who needed help right now.
We hadn’t discovered iChat yet (no idea why). We figured out that Skype had the
immediacy we needed, and kept people focused on the current conversation.
The initial plan was:
1. Have occasional lengthy Skype calls on demand.
2. Record them with Audio Hijack.
3. Post them to Amazon Web Services (they were too unwieldy for Google
Groups).
4. Listen later to transcribe or just get answers during the writing process.
The way it actually worked out was:
4. Never listen to the calls again, but find that talking helped us (momentarily)
get unblocked.
This fact went unnoticed at the time, but came in very handy later.
Harshness of Reality
17

18. How 5 Authors
Here’s where we are on the timeline at this point. After our first meeting at the
beginning of June, it took about a month and a half to get physical contracts mailed
around to everyone and signed, and get everyone commit access to the source
repository for the book. (As an aside, the Prags use a coder-friendly markup
language for their writing system—authors check their text and their code examples
into the same repository.) So the work in earnest began in mid-July.
During July and August, we toyed around with IRC. In September and October,
we had those lengthy Skype calls and tried to figure out what to do with the result.
Ola wrote the database chapter, and during a four-hour train ride to Seattle I wrote
the introduction.
The pessimist would look at this process and say, “These guys are spinning their
wheels.” The optimist would say, “They’re just learning each other’s styles and how
to work together.” I’ve thought one or the other or both of these things several
times. At any rate, at this part of the story the initial rush of enthusiasm has passed,
and we’re entering the Trough of Sorrow.
18

19. How 5 Authors
The Trough of Sorrow
As you’ll recall from the Startup Curve, the Trough of Sorrow is the long slog in
the middle of a big project when it’s difficult to see progress—either because there
isn’t any, or because the goal still feels so far away.
Wiggles of
False Hope
Trough of
Sorrow
Nagging of
Stakeholders Abandonment?
The way that this feels can best be told through the conversations among the
authors, or between the authors and Jackie, our patient editor.
Conversations
One of the recurring themes throughout this endeavor has been the “what’s
going on?” conversations.
July
Jackie (our editor): What’s happening with JRuby?
19

20. How 5 Authors
Ian: Nothing. I have no authors. Couldn’t track anyone down....
Jackie: Can you try again this weekend? Don’t get discouraged just
yet.
Of course, that’s before we even had contracts or commit access, so not much
progress was expected yet. Even so, it’s clear I hadn’t yet learned that, as they say at
Apple, “reasons stop mattering” when you’re supposed to be the one coordinating
the project.
August
Jackie: Anything happening with JRuby?
Ian: Good news from Sweden. Ola’s starting the chapter on
Hibernate....
Even in the dark times, we were still making progress. It was tough to remember
it sometimes. In the fall of 2008, Ola wrote two pretty hefty chapters, and I wrote
material that ended up in the introduction and other places.
September
Jackie: BTW, if nothing is happening, we should talk about it soon.
Ian: Ola just released a bunch of code... following up to see if he’s
ready to write about it.... I’ve just proposed a “bookfest” where... we
sit and do nothing but write....
So, starting a chapter isn’t the same thing as writing a chapter. Even so, the stuff
that has to happen (code examples) is happening. It’s just not visible in the PDF yet.
This is also the first time we talked about writing together in person, though it
would be the better part of a year before we actually did it.
October
Ola: It seems that the book will take a long time to get finished...,
and I really want to get going....
Ian: It's just been difficult [for the team] to justify writing about
JRuby when they could either be hacking JRuby or helping someone.... On
20

21. How 5 Authors
the other hand, a phone call gives us a solid block of time with each
other, where we have (nearly) 100% of one another's attention.
If there were a theme to describe all of our difficulties—mine included—it
would be “divided attention.” We all had day jobs, and even aside from that, all of
the core team members had JRuby to maintain and users to help. It’s so, so easy to
sit down to write a paragraph on feature X, realize that feature X doesn’t yet do
what you want it to, and dive into the code.
The thing that helped a bit here was a phrase that kept coming up during our
initial visit: “JRuby as it will be.” It’s okay to write about things that are coming in
the next version. Don’t stop the writing to add the feature (yet), we told one
another. Just document it, and put a tag in the text that says, “Note: the following
technique won’t work until feature X makes it into the code (expected in v1.n).”
We would later call this technique “Book-Driven Development.”
November and December passed with the same trickle of progress. We spent
time shoving words around the page, but not enough time writing new ones. Then,
in January, a new chapter landed!
February
Jackie: Is [Ola’s testing chapter] ready for me to review? .... This
looks really good!
A wiggle of hope! New material and improvements visible to the reader! But
fast-forward to April….
April
Jackie: How is it coming along?
Ian: I feel a bit stalled..., and now things just seem... slow.
Jackie: How can I help you get back on track? Are you getting
discouraged?
This is the low point on the curve, the flirtation with abandonment. Normally
author teams are a little more together by now and don’t need the development
editor step in and to get people talking.
21

22. How 5 Authors
The offer to help could be a motivational technique. Or it could just be
frustration. In either case, Jackie’s been a great sport this whole time.
Don’t Give Up
Here’s the message I’d like to have sent back in time to my summer 2008 self.
Don’t know that I’d have believed it, but it would have been worth a try.
There are times in a multi-person project when you’re going to feel utterly,
utterly alone. You’re going to log into Skype and no one’s going to be there. You’re
going to send out e-mails that don’t get a reply. Don’t give up, don’t despair, and
don’t give up.
There’s an easy kind of reaction to have here: “I’m terrible at this, might as well
forget it.” This is kind of a perverse backward narcissism—focusing on the self
instead of the project. What an easy cop-out; what a convenient excuse. Nobody
would blame a terrible writer for not writing.
Acknowledge these feelings and push past them. At this point in the project,
there was enough critical mass of text where I could do something. Even if it’s just
another editing pass through a chapter, or a new appendix, or something.
As it turns out, there was something small and simple we could all do that
would make all the difference to the project.
22

23. How 5 Authors
Establishment of Rhythm
We’re now in the third and final phase of the startup curve: the establishment of
rhythm. I’m speaking both metaphorically in the sense of a group operating
harmoniously, and literally in the sense of finding a heartbeat for the project.
Release!
Conservation
of Momentum
Establishment
of Rhythm
Actually, “heartbeat” is quite a telling term if you think of its medical
implications. With the patient going so long without a pulse, it’s no wonder we
entertained thoughts of giving up and calling the coroner.
A Personal Inflection Point
For me, there was a personal inflection point in this curve in the summer of
2009. JRuby saved my butt with a deployment at work. I’d always seen JRuby as this
neat alternative Ruby that you’d use if you needed Java interoperability. What I’d
missed was that JRuby was becoming a first-class Ruby implementation in its own
right. For certain uses (including my own), it could out-Ruby Ruby.
At that point, JRuby became my preferred Ruby. Don’t get me wrong; like any
23

24. How 5 Authors
irredeemable tinkerer, I’ve got a stable of Ruby implementations sitting around on
any given computer, and love them all. But JRuby became the one I reach for first.
During this process, I started finding (and occasionally, fixing) bugs specific to
the older platforms I was using: Windows XP, Mac OS X Tiger, the PowerPC
instruction set, and so on. I started to be able to write with some limited authority
on the subjects I was meant to be covering. It makes a huge difference to go from “I
will research this, and then write about it,” to “I remember this because I learned it
the hard way, and I can write about it now.”
In addition to this turning point that was kind of personal for me, we enjoyed a
big turnaround together as a team. There were three main components to this
welcome change: finding the project heartbeat, working together in person, and
keeping the momentum going once we were apart again.
The Project Heartbeat
We made three little leaps forward in the summer of 2009, right after we got the
big wakeup call. The first thing we did was to establish a regular rhythm for the
project—a literal week-to-week rhythm.
In June, we started using Pivotal Tracker to keep a backlog of our work. This is a
web-based project tracking tool that encourages your team to break remaining
work down into small pieces—writing a single section of the book or revising one
chapter, for instance. In Tracker parlance, each piece is called a story, and we
found it helpful to phrase our stories as statements of fact. For example, rather than
“Write section on Maven,” we might say, “Section on Maven describes Rake
integration” or “Section on Maven incorporates editor feedback.”
You don’t give time estimates in hours. Instead, you work in relative terms; e.g.,
“this story is twice the size of that one.” (See McConnell on software estimation for
evidence that people are much better at these kinds of estimates). You arrange the
tasks in the order that they need to be done, and start working. After a few weeks,
the software has an idea of when all your tasks are going to be done.
24

25. How 5 Authors
It’s a good way to find out early in the project whether or not you’re going to
miss your deadline. We sure could have used this earlier on, because the only
deadlines we were even remotely good at meeting were ones we planned with this
tool. Before then, we’d say things like, “I dunno, the new chapter will probably be
ready in a month or so.” At least we were vague, but still—that kind of estimate was
laughable.
Why should the publishers ever believe us after we went so long without
meeting any commitments? Because we finally showed evidence that we could
deliver.
There are a couple of ways to keep the information up to date in a tool like this.
You can watch your project’s files for changes, talk to your teammates about what
they’re working on, and update the data yourself. Or your collaborators can log in
and update their own statuses individually. We used a little of each approach, and
honestly there wasn’t much difference. The hard part isn’t entering the data, it’s
figuring out what everyone’s supposed to be doing.
Having each person’s commitments spelled out in one place that we actually
used was a huge help for us. It made us look like we were really on top of things
25

26. How 5 Authors
when our editor came to us a month or two after we’d been doing this and said,
“How about delivering work in iterations?” Now, when she asked “how’s it going?”
every couple of weeks, we had concrete answers, as well as plans for the next
week. Not every week went according to plan, but this was still a huge step
forward.
After we’d been tracking our work for a few weeks in this manner, it was time
for the next productivity boost: meeting in person.
Writefest!
We’d been loosely entertaining the idea of having a “writefest” for nearly a year.
We never made any concrete plans until a few things came together in the summer
of 2009. A few of us simultaneously found a little breathing room in our day jobs /
conference schedules. We’d observed enough momentum in Pivotal Tracker that we
felt we’d have something concrete to accomplish together.
On July 6, I flew to Minneapolis and spent a few days writing with Nick and
Charlie at dining room tables, coffee shops, bars, and restaurants all over the Twin
Cities. Sometimes their families tagged along, and sometimes we soloed in quiet
isolation. But man, did we turn out text.
At this stage, we needed to write using a tool that would let us all see what we
were working on. Google Docs fit the bill. It has simple formatting controls, so we
didn’t waste time fiddling. When one person makes a change, the rest see it just a
few seconds later.
26

27. How 5 Authors
In this screenshot, you can see echoes of our “JRuby as it will be” sentiment. We
wrote a few sections like these, where we didn’t quite realize what JRuby needed to
do until we got ourselves into tangles expressing behavior that needed to be
simplified.
We wrote the bulk of the “Driving Java from Ruby” chapter one night over beers
in a Minneapolis restaurant, jumping from concept to concept. That information is
one of the first thing someone new to JRuby needs, and it’s really fitting that nearly
all of us had a hand in that chapter.
Google Docs served us well for a few of the other collaborative parts of the
book. The chapters on embedding JRuby and on the compiler were each two-man
jobs. The web browser was the place in our computers where a lot of us were
“living,” and therefore the shortest path from “I have an idea” to “Wow, I’ve just
written ten pages.”
Once a chapter had stabilized, I’d save it as HTML and use a few macros in my
text editor to convert them to the markup language used by the publishing system.
After the writefest was done, how could we preserve and protect this
momentum we had built up? By meeting regularly via conference call.
27

28. How 5 Authors
Remote Standups
As you’ll recall, we used Skype early on in the writing process. We’d record the
calls with the best of intentions, but we wouldn’t do much with those recordings
afterwards. It was time to look at what we thought we were getting out of voice
chat vs. what we were really getting out of it.
We had thought that Skype was going to be a tool for generating content.
Record, transcribe, edit, release. It turns out that transcribing is a huge time sink,
and we seldom did so. Not only that, but the act of having the call—not the
recorded talking—was the thing that got us writing again.
What Skype really was for us was a tool for maintaining the project rhythm. The
first Monday morning after the writefest, we established regular Monday/
Wednesday/Friday morning conference calls. They were a little bit like the standup
meetings some agile software teams use. We’d talk about what tasks we could mark
as complete in Pivotal Tracker. We planned work. We talked about places where we
were stuck. We vented.
The meetings became a habit, but not an obligation. We never felt compelled to
meet just for the purpose of going through the motions. And indeed, we did cancel
a few meetings when there was nothing new to say and it would have gotten in the
way of working on the task at hand. But those cancellations stand out as rare
exceptions. (I can still remember the feeling of being logged in all alone—but our
time in the trough of sorrow taught me that these feelings are temporary.)
Because we weren’t attached too much to form, we experimented a little with
the tools we used. If the Central Time Zone folks had to be somewhere loud, we’d
meet in iChat or Skype text chat instead of having a conference call. These only
worked because we’d built up a history of talking to one another, and could now
safely undertake the much more distraction-prone activity of text chat without too
much risk of the conversation dying.
We kept up the meetings up until June of 2010; that’s nearly a year of talking
regularly. It was seldom all five of us on one call, but most weeks everyone made it
into at least one call. We had a few remote meetings sporadically after that, but
really didn’t need them any more. The writing was nearly done, and now it was
down to the million little tasks that get lumped in as “editing.”
28

29. How 5 Authors
Release!
Four months after we pulled back from the brink of abandonment, we had built
up enough momentum to where we knew we were going to finish this thing. So
with the publisher’s blessing, Charlie stood up in November 2009 at the first ever
JRubyConf and announced publicly that we were all writing the official JRuby book
together. No backing out now!
By March 2010, we had enough material to release a beta version of the book
as a PDF. This stage was crucial for us. Even though we ran all the code in the book
ourselves on a regular basis (mostly with the help of automation, thank goodness!),
our early readers still found a few examples we needed to tweak.
More importantly, early readers identified concepts they wanted to see covered,
and they did so at a time in the project where we still had time to do something
about it! For instance, in the database chapter, we added installation instructions for
some of the software our readers would require. In the testing chapter, we were
able to add a section on the Webrat testing tool.
When the beta came out, the book was about half done. Every few weeks, we’d
release a new beta while we wrote new material. Finally, in August 2010, I sent this
tweet:
The final chapter is in our editor's hands. The book is written.
Tonight, I'll try this "sleep" thing I've heard about.
So at JRubyConf 2010, we could truthfully announce that the book was done,
and would be going to press in December or January. In the meantime, we still had
a couple months of editing to do: first with our development editor Jackie, then
with our second round of tech reviewers, and then finally with the copy editor.
It was a long march, but it was worth it all in January when we got those boxes
in the mail and held those real books in our hands.
Lessons Learned
29

30. How 5 Authors
I’ve been scattering little asides throughout this talk to describe instances when
reality stood up and gave us a smack of the truth. Here are those nuggets of hard-
earned knowledge, gathered into one place for convenience. Please keep in mind
that these won’t apply to every project or team, and indeed might not all apply if
the five of us got together tomorrow and started a new project.
It may look like a book, but it’s actually a software project.
It may feel like writing, but it’s actually project management.
Focus your efforts around a simple rallying cry (“Using Ruby from Java, Using
Java from Ruby”).
Don’t choose your tools before you know what you need them for. It wasn’t so
much that using a specific tool caused us to suddenly make forward progress. It
was more like we had finally created a way to work together, and we found the
tools that were right for us at that time.
An experiment that proves a result you didn’t expect is still a successful
experiment.
Self-doubt is a form of narcissism.
Eat your own dog food. For me, progress really improved when I started using
JRuby all the time.
Meet in person at least once.
Have a project heartbeat.
Form good habits, not empty obligations.
You are not alone. It will feel like it sometimes, though.
I hope you’ve come away with this talk informed about long-running,
geographically widespread collaborative projects—or at least entertained by our
struggles to complete one. Even more importantly, I hope you feel encouraged to
write about the technologies you’re building and bring your knowledge to new
people. Because there’s one more lesson learned that I hope is really clear after all
this:
If the five of us can write a book, you certainly can.
30

31. How 5 Authors
31