Taking the leap: Deciding to do a first open source contribution

I’d like to share with you my summary of a lengthy discussion I had at the GeeCON 2013 Open Spaces sessions. I hope it will be interesting not only for people who consider a first contribution but also for developers who are already active in the open source community.

First, if you’ve never attended one of those sessions here’s a short run down of how it went: About 30 people met in the morning (some of them later because of a certain party ) and everyone who had a topic to discuss or do would write it on a sticky note and attach it to the wall. Attendees then self-organized those topics into clusters (as some were really closely related) and fit them into the schedule, which had room for three one-hour sessions during the day, with three tracks running in parallel.

I wanted to talk a bit about “gender diversity in open source”, because after a discussion panel on minorities in IT two days before I wondered if there were any special barriers that prevented women from contributing to open source other than the reasons for not pursuing a career in computer science in the first place. It turned out though, that when it comes to a first open source contribution, gender does not seem to be an issue, or at least it’s not the important one. The much more pressing issue we seem to be facing is fear.

My card was clustered with two other open source related cards, and one of them was on how to get into open source. So a little while later I found myself in a conference room with about half a dozen other developers, two of them women and kicked off the session by asking the participants to briefly introduce themselves and tell their open source story: Whether they are a user, have their own projects, contribute to some project, etc. Most of the attendees told me that they actually wanted to get into open source but were afraid of it. They were afraid of open sourcing and being ridiculed for their code.

At first I thought that was a bit of an irrational fear but they told me the story of Heather Arthur who found herself on the not-so-funny side of a shitstorm broken loose by arrogant software craftsmen making fun of her code on twitter. She later got apologies and reassurance and is still an active part of the open source community, so this story seems to have ended better than it could have. But that could be because she already made much better experiences before and was already employed by Mozilla, so she obviously had a higher “open source self-esteem” than the people who were in the session with me. So Heather asks an important question:

Can you imagine if one of these new open sourcerers took my advice [to open source something they find useful] and got this response, without the support I had. Can you imagine?

Yes I can, and I also realize how incredibly lucky I have been. When I started working on open source, I pretty much was the textbook nerd with nearly no friends, super-low self-esteem, always being picked on, that kind of guy. If I had that gotten that reaction to my first contributions, I might be in a sanatorium or six feet under today (exaggerating here, don’t worry Mum!) but I’d certainly not be going to conferences to meet awesome people and talk about the things I’m passionate about.

So they have every reason to be afraid of having their self-esteem destroyed by people who might be real assholes or are usually friendly people who tend to turn into arrogant pricks on the internet (sadly, I once was a member of the latter group and dearly regret this but hope I collected enough karma points by now to make up for it). And some of them even have stuff they would like to open source in private repos. I might get nightmares tonight about all the potential pearls that may well be hidden in private bitbuckets because of this.

When I started working on open source, there were no twitter shitstorms because twitter wasn’t even around (okay, now I’m just talking like an old person but what the heck, it’s true: we had usenet flame wars ). The first real contribution I can remember was implementing a feature I wanted in Gajim, an instant messaging client. This was way before I got a “proper” university-style computer science education, before I became a “professional” software engineer and I’m sure I wrote some pretty bad code back then. But when I mentioned to the project members that I wanted to implement something, they were kind enough to mentor me: They explained how and why I should implement it and showed me the flaws in my attempts until I reached a level of quality that met their standards. I can’t remember any of them ever being rude to me.

So if you are a young developer and are reluctant to start doing open source work I’d like you to encourage you to take the leap and do it! Your effort is appreciated. You will meet a lot of awesome people and learn from them. Yes, if you’re unlucky you might meet a few assholes along the way but that’s no different from the rest of your life – after all developers are like any other group of humans: you just can’t avoid that there is an unfortunate amount of arrogant people as well as sexists, racists, homophobes and every other shade of asshole. Just get away from them and let their project rot in hell.

But what about those of us who already experienced the wonderful feeling of code being accepted into a favourite open source program? What can we do to help?

One thing that I know about that perfectly fits the theme are the Hackergarten events. They are evening-long get togethers with the intent of working together to create something that others can use. While I have never attended one (yet, but luckily I will have the chance to attend the Gr8Conf Hackergarten in Copenhagen tomorrow), I could imagine this as the perfect format for bringing together experienced open source hackers and newcomers. The Hackergartens could work as a safe space to take away the anxiety that comes with the possibility of public humiliation (well, it’s still public, but a dozen people instead of billions sounds like a good thing, right?). If you have any other ideas for things we could do, please let me know!

I’d also like to use this post to express the huge amount of gratitude and love I feel for the amazing people in the open source community – not only for producing some kick-ass software and giving it away for free but also for helping young talent to become better at what they do. And especially say thanks to the guys from the Gajim team – I’d really like to buy you a beer (or a brewery) some day.

Node.js: Custom error classes without the pain

Dustin Senos wrote a good article on using Custom Errors in Node.js, however I thought this was a lot of boilerplate code to write each time I needed to add a new Error class, so I opted to generate my error classes dynamically like this:

var util = require('util')
, errors;

// A list of error classes to generate.
errors = [ 'MyFirstError', 'MyOtherError' ];

// Abstract Error
function AbstractError(msg, constr) {
  Error.captureStackTrace(this, constr || this);
  this.message = msg || 'Error';
}
util.inherits(AbstractError, Error);
AbstractError.prototype.name = 'Abstract Error';

// Generate error classes based on AbstractError
errors.forEach(function (errorName) {
  var errorFn = exports[errorName] = function (msg) {
    errorFn.super_.call(this, msg, this.constructor);
  };
  util.inherits(errorFn, AbstractError);
  errorFn.prototype.name = errorName;
});

You can then just require the errors module and use any error class like this:

var error = require('./lib/error')
callback(new error.MyOtherError('async error!'), null);

Of course this does not allow for a hierarchy (like AbstractError -> IOError -> FileNotFoundError) but could probably be extended if the application grows big enough to require this. I’d be happy to hear about any improvements over Dustins approach, especially as his post has been around for a while and there might be new idioms on error handling, but right now this feels like a good way to handle errors in node apps.

Sharing from the new Google Reader to Google+ withouth a public +1

Quick tip of the day: With the Google Reader redesign, it got much easier to share stuff to friends on Google+. However, the functionality is hidden behind the +1 button, so you have to publicly +1 the item before you can share it privately. There is another way though: Just use the “Share” box on the right side of the top bar that is now common to all Google services – it will automatically share the item currently viewed in Reader.

Painless migration of WebDriver tests to Geb

Okay, so your Selenium test suite has grown over the years, you migrated to selenium 2.x/WebDriver and you constantly evolved your set of helper methods to work around the complicated Java Api. Your tests do what you want them to, but they are pretty ugly. They have CSS and XPath selectors scattered all over them and duplicated a dozen times. There is no separation between describing your page and your actual test. Then you stumble across Geb and fall in love, but you are afraid it won’t play well with your Tests and would take days to integrate into your complicated build process and CI system. Fear not, it will play along just fine.

We have a large set of JUnit4 Tests written in Groovy that all derive from a single base test class. All we really had to do to geb-enable our tests was to throw in two jar files, make the base class extend GebReportingTest (well, and remove/deprecate code that’s no longer needed because it’s provided by geb). It did not break anything and we can now start adding new Tests using the Geb DSL or rewrite existing ones. Next step will be to write new Tests as Spock specifications instead – this will probably only require us to modify some wildcards in our ant build.xml and/or Jenkins configuration to run *Spec as well.

My Thesis: Test-driven development of modern web applications

As promised in my talk at FrOSCon yesterday, here’s my thesis on test-driven development of modern web applications. It’s in German and licensed under CC-BY-SA. I hope it’s useful to some of you  guys.

Test262 JavaScript Test Suite

This looks interesting: Nearly 11.000 test cases to see how well Browsers implement the JavaScript specification – and they are open so you can verify the results yourself. I actually wonder how Opera get’s anything to work with only 65% of the tests passing…

HTTP for Humans

Things shouldn’t be this way. Not in Python.

 Documentation of the “Requests” module