Social Aspects of Open Source Contribution

Lately I've been helping out on a piece of software that has a reasonably wide circulation, and I must say the experience has been interesting. My role in that project is to not only think about wider issues and write code for them, but also to help out with community contribution.

While the technical side of this is interesting, a lot of time is spent on the social side - and I wanted to talk about my experiences, my deficiencies and various gripes from both contributors and "merge-masters" specifically around code contribution. I'm an absolutely crap social person (all my ex-girlfriends think I'm a bastard), and recent discussions with a friend/colleague made me think of writing this article and the struggles with being sociable in this arena in an effort to get myself and others thinking about it more.

Talking Terse

Although its hard not to, its unavoidable in this game that emotion becomes involved. I get a lot of commits that come through, and sometimes I'm not the best at appearing to be "nice". If you've seen me do this - its not even that I'm trying to be nasty - but my choice of language is short because I'm in a rush and I haven't taken the time to think about how people might interpret it.

I think its easy for an external committer to take personal pride in his submission - and so he should. My terseness or brevity isn't a reflection on this, in fact I think every community commit is a piece of awesomeness. But like everyone we have limited time and can't always display that emotion all the time. Like my wife says: "You are an insensitive guy after all".

When you have a good relationship with a committer that kind of social thing isn't necessary, but even then I find I need to sit up and just be a person again - not a code testing machine. I think the trick here is that we have to be "nice" no matter what. But more importantly, if you are nasty - say sorry :-).

Differences of Opinion

Sometimes you get into arguments as well differences of opinion and sometimes all out slinging matches (although I've had very little of these). I've found stepping back and trying to put myself in the submitters shoes is the best thing. I have once or twice sparked off emotionally and said 'no we'll never do that'. Only later to realise I was being an arse. The thing is, people are raising these issues because they feel its important to them - the fact that someone has submitted any amount of code shows it matters. So I try to always consider their perspective, but I'm not always successful.

Its easy to be myopic as well about an issue, and I've tried recently to purposely give up on arguments when I new the consequences of letting a change through aren't really going to affect the overall product anyway. I'm a terribly myopic individual at times, but dealing with other people in this case is starting to loosen that up.

Processes

My company has a semi-strict processes for code (although not as bad as others I've seen). Broken builds must be fixed quickly, and all commits if possible should have tests. All code must be peer reviewed, and must have a ticket. It can be painful - but in our defence we're asking these things because we have found over time this is the simplest path to quality. Yes - all processes can be argued and not every process fits every problem. But for us we find its the best path to success, and we (my org that is) generally all agree on this.

Not everyone gets this though, sometimes its because they are new. Sometimes they have their own process and this is just an annoying distraction. Sometimes they can't see the benefit for them in following the process.

So I try hard to help out. For example - writing tests for code is actually generally harder then writing the code itself, but it stops regression and increases the chances that the code was well thought through. Yes its a hassle, but we can't compromise since we want our product to be high quality and have as little technology debt going forward. I find showing people examples helps, so if I write tests I try to make them readable and reproducible.

For Git based workflow problems (which happen when committers are new) - I will actually spend more time helping them get through the process then if it took me to just write the code. A lot of people ask me why I bother. My attitude is that if I help people out, they contribute more. I want their contribution experience to be a nice one (despite sometimes me ruining it  :-).

Some people bitch to me about the process. I hear them loud and clear, I hated the process myself when I first started. Now I need the process. I need to know when a ticket needs to be merged (so change the status). I need to have clear commit messages (so I can see what that change was all about after all). I need the ticket in the commit message (so I can go back and read the back-story behind the change). From my perspective all the various pending changes appear as a stream of tasks I must complete ... and without some semblance of order my brain explodes :-).

Having said that, I want the process to be easier for everyones sake. Always questioning the process if there is a perception it is wrong is the key to this I believe. As a contributor you should also be questioning but more importantly suggesting alternatives. Most projects aren't doing something because they are trying to cause pain, finding the reasoning behind a process and suggesting an alternative I'm sure for most project members would be more welcome then 'your process sucks'.

For the common good

Sometimes people want their change to go through, but don't want to think about how this affects the product as a whole. I always have to think about the product as a whole. Its my curse and well - my job.

I try as much as I can to get people to think about use-cases beyond their own. Sometimes this doesn't work and I probably come across as difficult. But while I'm being difficult to that person, its in reality being nice to everyone else trying to use it. Does that make sense? Its a bit existential I know :-).

I think the answer sometimes is to provide a plugin system where peoples ideas can be tested on an audience without making it into core. This is certainly a valuable test, as the numbers and the popularity of a solution then speak for themselves.

Anticipating problems

I've seen the effect of when a bad change comes through, then the follow up tickets where people bitch about it being broken. I hate that, so I'm pedantic at times. Why? Because I don't want those follow up tickets - not a single one. I want it right every single bloody time.

But this is not always realistic. Sometimes I have my doubts and let the fates decide, but when I know its a bad idea I dig my heals in. My biggest problem is I have trouble getting my point across as to why I think its a bad problem. Sometimes its just a feeling and hard to quantify. I think my biggest problem as a technical person is my ability to explain an issue via a text based format, and something I need to work on.

Great idea, bad timing

And finally there is the ticket that is awesome and cool, but we want to wait because it needs a big change somewhere else. I like these tickets, they confirm that our thinking is right. But as usual we need to consider the blocking change from all perspectives, not just from a 1-bug perspective. Its a pain, and its slow and excruciating and if I could I would love to work on big architecture changes all day long to make the minor functional changes as easy as pie.

But I think these things turn people off. Ultimately there is a perception that these big changes need some staff member or senior to execute it. This in part is true, its much easier to get what you want done when you work near the top of a project (either as part of the company sponsoring it or you are in the upper ranks). This most certainly is something I feel is a big problem, and needs more thought as to its resolution.

But the people are awesome

And this is so true. I've met many awesome individuals while doing this kind of work. Sometimes they are short-term relationships, and others I consider to be friends.

Whats awesome about this aspect of the community, is that your working with this people as if they were colleagues - but its all volunteer and without as much constraint. No bosses, no contracts, no business plan, no strict HR - just human beings getting along, writing code and working for the greater good. And this is what I think makes Open Source totally awesome :-).