james mckay dot net

because there are few things that are less logical than business logic
04
Sep

Send patchbombs to the mailing list, not pull requests to the project lead

I sent a pull request to the lead developer of an open source project that I’m starting to contribute to. This is the default that both github and bitbucket give you, and the first thing that newbie open source contributors on those sites will think of doing.

I got this response from him:

I’d *massively* prefer patch submission via patchbomb to the … list – that’s generally where they come in, and sometimes people other than me find potential problems in the patch. Can you do that?

D’oh! My bad! It’s the same kind of thing as the rule that you should ask the whole community, not just one of its members. Admittedly I had noticed the existence of the mailing list, but only after I sent off the pull request, so his response did not surprise me.

Moral of the story: if you want to contribute to an open source project, look for a mailing list before you do anything else. And if there is one, use it.

20
Apr

Some thoughts on the role of open source experience in recruitment

Jeff Atwood wrote an interesting post the other day where he asked the question, Is Open Source Experience Overrated? He quoted an anonymous developer who had lamented not being able to find a job despite being the architect of a couple of open source projects:

One company seemed impressed with my enthusiasm for the job but it was part of their policy to provide coding tests. This seemed perfectly reasonable and I did it by using the first solution I thought about. When I got to the phone interview, the guy spent about five minutes telling me how inefficient my coding solution was and that they were not very impressed. Then I asked whether he had looked at the open source projects I mentioned. He said no – but it seems his impression was already set based on my performance in the coding test. The coding test did not indicate what criteria they were using for evaluation but my solution seemed to kill the interview.

I must confess that I was a little bit incredulous when I read this. It seems the correspondent was expecting the recruiter to consider his open source contributions as a substitute for his poor performance in the coding test — and it would be an irresponsible recruiter who did that.

The problem with open source contributions is that they don’t necessarily tell a recruiter what they need to know about you. They indicate passion and enthusiasm for programming, which is a plus, but they don’t necessarily indicate competence — and passion is no substitute for competence. In fact, some open source projects, such as this example cited by Ayende the other week, are very badly written and do not reflect well on the developer. And in the recruitment process, it’s competence that a responsible recruiter will be looking for first and foremost. That’s why it’s so important to have a coding test. The team needs to have a certain baseline standard, and that standard needs to be treated as a “must have” — failing the technical test should be an automatic “no hire,” regardless of passion or experience. Yes, they should take a look at your open source contributions, but they only really become relevant in the later stages of the recruitment process, once they have carried out the technical screening and are getting into the final round of interviews.

Here are some examples of things that a recruiter may want to know about your abilities that he or she is unlikely to find in a typical open source project:

  • How quickly you can write code
  • How quickly you can troubleshoot code
  • How quickly you can learn new technologies
  • The extent of your understanding of the company’s core technologies (how much you have committed to memory, and how much you need to refer to the documentation)
  • How well you can understand and implement customer requirements
  • How clean you can keep your code when working to tight deadlines
  • Whether you can grok recursion
  • Whether you understand Big O Notation and its implications for performance
  • How well you can integrate with the rest of the team

Different companies also have different attitudes towards open source. The ones that are most likely to be interested will advertise job openings in the open source community itself — they reason that that way they have a generally richer pool of talent to draw on than the hordes of unqualified and mediocre people that you get in places like monster.com and recruitment agencies. Larger organisations, on the other hand, are only likely to take notice if your contributions are to a project that they’re actually using, such as NHibernate or Tomcat, and some companies actually have a prejudice against it, so it pays to do some research and bear in mind that YMMV.

One other thing. If you want to pitch your open source contributions to your prospective employer, you need to make sure that your code is the best quality that you can give it. You might find that they take it into account in ways that you hadn’t expected, and if you’re doing stupid things such as silently swallowing exceptions, or writing thousand-line, hundred-parameter, multi-responsibility, copy-and-paste methods, or giving them names like DoIt(), or if your code formatting is sloppy and difficult to follow with inconsistent indentation, it may work to your disadvantage if they ask a technical reviewer to look at it. Open source coding isn’t like coding for work or profit: you have no deadlines, so you can afford to give it a lot more tender loving care.

04
Jun

The Church needs Creative Commons

If you’ve ever had anything to do with modern church music, chances are you’ll have come across an organisation called Christian Copyright Licensing International. Their website has the strap line “encouraging the spirit of worship” and the idea is that rather than paying royalties to individual songwriters and their agents, you just pay one licence fee and that lets you sing whatever you like as often as you like in your church for a whole year. It helps with administration and makes it easier for your church to operate in righteousness, so it saves some time and hassle, though maybe not money. It’s a vast improvement over what we had in the early 80s with songbooks like this one that had a dozen or so entries that said “This song has been omitted for copyright reasons.”

However, it only covers church services, so if you are organising evangelistic events, or conventions like Faith Camp, or making your own worship album, or streaming your meetings live over the Internet, or making a mashup for something or other, or even playing tracks from your favourite Christian albums in a coffee shop, you need to go through the rigmarole of getting whatever other additional licences you need. And of course, all this costs more in terms of both money and time, and what might otherwise only take a couple of days can end up taking several weeks or even months while you’re waiting for permission to come through — if it comes through at all.

Now compare this “Christian” approach to copyright with the concepts that developers and geeks have come up with. I am talking, of course, about open source and Creative Commons.

If you’ve never heard of Creative Commons, you may want to take a look at this video, which explains it very simply and clearly:

The idea is for copyright owners to allow greater freedom and flexibility in what is done with their own intellectual property. Take my blog for example. I could put a notice on it saying you’re not allowed to copy it without paying me a fat fee, period, but I have deliberately chosen not to do so. Instead, I’ve released it under a licence that lets you reproduce it wherever you like as long as you aren’t doing so for profit, you acknowledge me as the original author, and if you make a derivative work, you grant others the same rights. You don’t even have to ask me — though it would of course be nice to know. The Creative Commons website allows you to choose a licence tailored to your needs from several different options.

The entire concept could have been lifted straight out of the New Testament, yet Christianity has had little involvement in it. It is a practical outworking of Jesus’ words, “Freely you have received, freely give” — indeed, in recent years, Bram Cohen, who is pretty much a poster child of the whole free content movement, made “Give and ye shall receive” the slogan for Bittorrent. It is a slight rewording of Luke 6:38.

Or what about Paul’s words in 2 Corinthians 2:17? “Unlike so many, we do not peddle the word of God for profit. On the contrary, in Christ we speak before God with sincerity, like men sent from God.”

So where on earth is the Body of Christ in all of this? Why are we dragging our heels when we should be forging ahead?

Worship leaders, church musicians and Christian authors have a lot in common with software developers such as myself. We tend to be very creative individuals, and what we do is often very much a labour of love. We write songs, books, blogs or computer code even if we’re not getting paid for it, and while it is nice to earn something from it, that is only a secondary consideration.

Yet while there are some people producing resources such as books, Bible studies and worship songs who have taken the concept of Creative Commons on board, they are very much on the fringes. Most, if not all, widely used Christian resources — including most modern translations of the Bible and nearly all songs that have a circulation beyond the songwriter’s home church — are only made available under restrictive commercial licences.

Is this encouraging the spirit of worship, or the spirit of mammon?

I would love to see some notable Christian songwriters distributing their compositions under licences similar to Creative Commons. I would love to see major ministries jumping on board, open sourcing their Bible study resources, and actively encouraging others to do the same.

I simply can’t accept the excuses that “it can’t be done” or “it’s impractical” or “worship leaders have to make money somehow.” The whole open source movement blows these claims completely out of the water. Some open source software packages have taken far longer to write than all the time that Graham Kendrick, Martin Smith, Tim Hughes, Matt Redman and the entire Hillsongs crowd have spent on all their songs put together — yet they are still made available for free, despite being mature and stable enough to power business critical servers. If software developers can do it, why can’t the Church?