Evan Phoenix (@evanphx), lead developer for Rubinius, spoke today at the Golden Gate Ruby Conference about how to effectively run or contribute to an open source project. Awesome talk with great information that is pretty slow to figure out by osmosis.

update: watch the video: “Being Your Best Asset and Not Your Worst Enemy”

Evan presented 4 guidelines:

1. Contributors are a privilege: sometimes they feel like a burden.  They are providing you with a service you couldn’t get on your own.
2. “No” is a respectable answer
3. Responsibility is power
4. Communicate.  A lot.  Open source projects live and die by how much they can communicate within the project and outside of it.

Be Nice. Sometimes contributors can be demanding and push your buttons.  Remember the contributors are doing you a favor by being there.

Case Study: the unwanted feature

• I added the ability to avoid flushing the toilet!
• You think “what an idiot!”
• Deep breathe.  Apply the laws.  Think of this as an invitation.

“Great!  I don’t think we’re ready for that.” … start a conversation: “Why do you want this feature?” explain why you don’t.  If you aren’t ready for them, what should they do.  When should you as a contributor or committer push for a fork.

What about Forking?
Fork for the right reasons.  Fork for love, not for hate.  Fork in public.
Pay attention to the fork.  Be a friend to the fork.  Talk to them.  Understand what they are doing.  See if you can move forward together.

Process?
avoid complicated setup and workflow
premature process is the root of all frustration
“These patches overlap with stuff we already wrote”
and they introduce 5 new dependencies, different test framework, different coding style… note:  this is a teachable
discuss - how for them to contribute more often so they don’t get out of date, how can you educate them about the architecture — docs are hard, but even the conversation is documentation, communicate that they need to adhere to the style
worst case: “I’m not willing to change for you”

answer: “sorry to hear that, have a nice life” (doesn’t need to be a big deal)

more typical is the best case scenario: “No problem, thanks, I’ll get right on that.”

Best way to start is with Easy Wins… just like TDD.  The simplest thing that could possibly work.  Simple goals and easy tasks.  Run this command and fix whatever is broken.  In Rubinous, a simple command will print every Ruby command that doesn’t pass.

“Easy wins are the gateway drug.”  Evan suggests that you should have no “core team.” By pushing out the idea that anyone    Trust is transformative.  Rubinious borrowed an ideas from Pugs: if you submit one patch you get commit privileges.  Responsibility is greater than privilege.  If someone fixes an error in the readme, give them the power (and responsibility) to fix any error in that area.  (Conflicts with saying “no?” If you communicate that is mitigated.  Advocate forks/branches for new features.)

As a committer. Don’t take it personally.  This project is just not ready for your awesome.

Closing notes:

• OSS is not about software — it is a social contract.
• Contributors want to succeed.
• Give respect <-> Get respect.
• We all just want to be loved.

Q: What communication channels work?

A: IRC is terrible, but it often the best answer.  Phone calls are great — offer to talk to them on the phone, people will feel honored and take you up on it.  Screen sharing/ facetime — whatever has the lowest latency.