open source

Before you write a patch, write an email

April 27, 2012 Open source 7 comments , , ,

I often get surprise patches in my projects from people I’ve never heard from.  I’m not talking about things like fixing typos, or fixing a bug in the bug tracker.  I’m talking about new features, handed over fully-formed. Unfortunately, it’s sometimes the case that the patch doesn’t fit the project, or where the project is going.  I feel bad turning down these changes, but it’s what I have to do.

Sometimes it feels like they’re trying to do their best to make the patch a surprise, sort of like working hard to buy your mom an awesome birthday present without her knowing about it. But in the case of contributing to a project, surprise isn’t a good thing. Talking to the project first doesn’t take away from the value of what you’re trying to do. This talking up front may even turn up a better way to do what you want.

There’s nothing wrong with collaborating with others to plan work to be done. In our day-to-day jobs, when management, clients and users push us to start construction of a project before requirements are complete, it’s called WISCY, or Why Isn’t Someone Coding Yet? As programmers, it’s our job to push back against this tendency to avoid wasted work. Sometimes this means pushing back against users, and sometimes it means pushing back against ourselves.

I’m not suggesting that would-be contributors go through some sort of annoying process, filling out online forms to justify their wants.  I’m just talking about a simple email. I know that we want to get to the fun part of coding, but it makes sense to spend a few minutes to drop a quick note: “Hey, I love project Foo, and I was thinking about adding a switch to do X.”  You’re sure to get back a “Sounds great! Love to have it!” or a “No, thanks, we’ve thought about that and decided not to do that”.  Maybe you’ll find that what you’re suggesting is already done and ready for the next release. Or maybe you’ll get no reply to your email at all, which tells you your work will probably be ignored anyway.

I’m not suggesting that you shouldn’t modify code for your own purposes.  That’s part of the beauty of using open source. If you need to add a feature for yourself, go ahead. But if your goal is to contribute to the project as well as scratching your own itch, it only makes sense to start with communication.

Communication starts with understanding how the project works. The docs probably include something about the development process the project uses. While you’re at it, join the project’s mailing list and read the last few dozen messages in the archive.  I can’t tell you how many times I’ve answered a question or patch from someone when I’ve said the same thing to someone else a week earlier.

Next time you have an idea to contribute a change to an open source project, let someone know what you’re thinking first. Find out if your patch is something the project wants. Find out what the preferred process for submitting changes is. Save yourself from wasted time.

We want your collaboration! We want you your help! Just talk to us first.

Open source is improv, so say “Yes and”

January 23, 2012 Communication, Open source, People 4 comments , , , , ,

In her fantastic book Bossypants, Tina Fey has a sidebar about how improvisational comedy has changed her life, and given her a new worldview. We in open source would do well to adapt these ideas to how we conduct our projects as well.

Improv and open source share many characteristics. A group of people come together to create something without a plan, and the result is greater than any one person could have created on his own. Everyone has a wellspring of ideas, and adds to the work created by others. In improv, the people make a scene or a sketch. In open source, they make software, or a body of knowledge, or a community, or a gathering.

From her book:

The first rule of improvisation is AGREE. Always agree and SAY YES. When you’re improvising, this means you are required to agree with whatever your partner has created. So if we’re improvising and I say, “Freeze, I have a gun,” and you say, “That’s not a gun. It’s your finger. You’re pointing your finger at me,” our improvised scene has ground to a halt. But if I say, “Freeze, I have a gun!” and you say, “The gun I gave you for Christmas! You bastard!” then we have started a scene because we have AGREED that my finger is in fact a Christmas gun.

Now, obviously in real life you’re not always going to agree with everything everyone says. But the Rule of Agreement reminds you to “respect what your partner has created” and to at least start from an open-minded place. Start with a YES and see where that takes you.

As an improviser, I always find it jarring when I meet someone in real life whose first answer is no. “No, we can’t do that.” “No, that’s not in the budget.” “No, I will not hold your hand for a dollar.” What kind of way is that to live?

The second rule of improvisation is not only to say yes, but YES, AND. You are supposed to agree and then add something of your own. If I start a scene with “I can’t believe it’s so hot in here,” and you just say, “Yeah…” we’re kind of at a standstill. But if I say, “I can’t believe it’s so hot in here,” and you say, “What did you expect? We’re in hell.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “Yes, this can’t be good for the wax figures.” Or if I say, “I can’t believe it’s so hot in here,” and you say, “I told you we shouldn’t have crawled into this dog’s mouth,” now we’re getting somewhere.

To me YES, AND means don’t be afraid to contribute. It’s your responsibility to contribute. Always make sure you’re adding something to the discussion. Your initiations are worthwhile.

Too often in open source, we do the opposite. We quickly say no, without regard to its effects. In improv, “no” kills a scene. In open source, it can drive away a contributor or kill an improvement to a project. It doesn’t need to be the word “no”, but any negativity towards a fresh idea.

Consider this exchange, all too common in mailing lists and IRC channels right now.

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “Language Y is a pain in the ass.”

In one quick bit of snark, Bob has taken a giant crap on Al’s idea, even though his only disagreement was in the implementation. Chances are Al will lose enthusiasm for the probject. In many cases, Al’s reaction might just be “Screw it, I don’t need this.”

Consider this alternative response from Bob:

Al: “I’m thinking about writing a tool to do X in language Y.”

Bob: “That sounds like a cool idea. I bet a lot of people could use X. I have some concerns about writing it in Y if you’re interested in hearing them.”

This is not “sugar coating the truth” or “being politically correct.” It’s being polite. It’s being a human who understands that other people have feelings, and that those feelings drive behavior.

I’m certain that some reading this will say “If Al gives up based on that, Al needs to toughen up. If someone doesn’t like something I’m doing, I’ll still do it anyway.” That’s great for you, Mr. Self-Esteem. Not everyone is as highly advanced as you are.

The “suck it up and take rude criticism” attitude might make sense if your project can be picky enough to only take contributions from those with your level of self-esteem. No project that I’m on is so overflowing with contributors and code that it makes sense to drive away those who want to help. It’s my job in my communities to help bring in more contributions, and I suggest it’s yours, too.

Open source is not standup comedy. It’s never one star on stage, doing it all himself. It’s a worldwide improv ensemble. Try saying “YES, AND” and see what can come out of it.

I’ll be presenting “Just Enough C for Open Source Projects” July 19th at Software Craftsmanship McHenry

July 1, 2011 Open source, Programming 2 comments ,

For programmers raised on high-level languages like Perl, Java and PHP, working on a C project can be daunting. Still, many open source projects work at a low-level in C to take advantage of the power and speed of working close to the machine. Whether it’s Perl, Postgres or Linux, C is what makes it run.

This session will provide a high-level overview of C, aimed specifically at the programmer wanting to get involved in a C-based open source project. We’ll cover:

  • Nothing in C is DWIM (“Do what I mean”)
  • Numeric types, strings and structures
  • Memory management: the heap, the stack, and pointers
  • Using the preprocessor
  • Understanding compiler warnings
  • Memory checking with valgrind
  • How to navigate a large C-based open source project (ctags, etc)
  • Security, or, how the Bad Guys smash the stack

Sign up at mchenry.softwarecraftsmanship.org.

How to show open source experience in your job hunt

November 1, 2009 Job hunting No comments

You’re out looking for a job, and you want an edge over the rest
of the candidates out there. Your experience in open source should
count for something, right? It just might, but the key is how you
sell it to the person who reads your resume, and to the interviewer
in an interview.

First, think of each project as a freelance job that you’ve worked
on. Just as different freelance gigs have varying sizes and scope,
so too does each project to which you contribute. The key is to
not lump all your projects under one “open source work” heading.

Explain in your resume the contributions you’ve given to each
project. Don’t assume that someone will understand what your project
is, or immediately grasp the importance of what you’ve done. For
example, on my resume I might have:

Perl programming language (www.perl.org)

Created the prove command line testing tool. prove allows
the programmer to interactively and selectively run tests in a test
suite without a Makefile, making test-first development much easier.
I wrote prove in 2005, and it was immediately embraced by the
Perl testing community. It has been part of the core Perl distribution
since 2006.

As with anything you put on your resume, explain what you did and
why it was good that you did it. The only difference between
project work and a “real” company is that instead of explaining the
value to the company, you’re explaining the value to the project
or to the users.

Wags familiar with prove may say “But all you did was write a
couple hundred lines of code around the standard Test::Harness
module.” The key to someone looking to hire me isn’t what I did,
but why I did it, and that I took the initiative to do it at all.
I saw a need for a tool, created it, and released it to the world,
to much appreciation.

So what have you done to contribute to help open source projects?
It doesn’t have to be as big as a deal as you might think. Submitted a code patch? Explain the bug, how you fixed it, and
what you did to get the patch into the system.

As with any project, make sure you explain what the project if
there’s any chance someone reading might not be familiar with it.

(Thanks to Esther Schindler for asking for comments in her article “What To Include In Your Open Source Resume”, which prompted this posting.)

How to boost your career by contributing to open source projects

August 13, 2009 Ask Andy, Career 2 comments

I’ve been hanging out at JavaRanch.com lately, after I was the guest forum contributor a few weeks ago. The Java market seems to be glutted with programmers from what I read, and there’s a lot of interest in using open source to boost one’s résumé. One poster asked for specifics of how he could use open source projects to help his career change to one of programmer. Here’s what I told him (with some minor edits):

The key to getting into open source isn’t to find a project to contribute to. What you want to do is contribute to a project you already use.

What open source projects do you take advantage of every day? I’m no Java expert, but it seems like half of what the Apache Foundation is driving these days is Java-based. Do you use Ant? Struts? Jakarta?

How about non-Java projects that you use? Do you use SpamAssassin? It’s in Perl, so would give you a reason to also learn Perl. Any Apache modules you use? You could learn some C.

How can you contribute to those projects? It doesn’t have to be just contributing code at first. Hang out on the mailing lists and provide answers. Update support wikis or contribute documentation. I know that on the Parrot project, a large amount of contributor time goes just to maintaining the tickets in the bug system. Anything you can do to pitch in, do it.

Start with joining the appropriate mailing list for the project, or monitoring forums. Hang out in appropriate IRC channels. Listen to what people are saying. Make yourself known as being someone who is willing to pitch in. And then do the work people are saying needs to be done.

Go into it with the goal of contributing to the project, and not of improving your career. When you take care of the first part, the second part will come naturally.

Good luck!

Any other suggestions? I’d like to turn this into a sort of standard page that I can point people to when this question comes up.