Slides: Stories in Open Source

Yesterday at RUG::B I tried something I’d never done before: a more personal, story driven talk. And in order to adequately illustrate it and how different Open Source feel to me I also opted paint some very special drawings.

Open Source is something I’ve been doing for longer than people pay me to do programming. I’m immensely passionate about it and it felt like it was some kind of blind spot that I never gave a talk about it so far.

If you know of a conference this talk would be a good fit for, please let me know.

Anyhow, here are the slides to enjoy: Speaker Deck, SlideShare or PDF


What’s it like to work on Open Source projects? They’re all the same aren’t they? No, they’re not – the longer I worked on Open Source the more I realize how different the experience is for each one of them. Walk with me through some stories that happened to me in Open Source and let’s see what we can take away.

Open Source isn’t just about code – other ways in which you can contribute!

Talking to developers and reading about open source I often get the feeling that the general notion is that open source is just about code and commits. Put another way, “If you don’t make commits for a project you are not contributing to it”. Or so they say. That notion is far from the truth in my eyes. Let me tell you why.

Sure, code is what ultimately ships and has a direct impact on the users of an open source project, so yes commits and code are important. But it’s by no means the only way you may contribute to a project. Projects mostly are a whole eco system, which is about more than just code. Here are a couple of other ways you may contribute to a project.

Report issues

If maintainers don’t know about issues they can not fix them. Therefore, it is crucial that you report issues you encounter and not just abandon using the project or only build a workaround. Most projects are happy to receive issue reports. Don’t take reporting issues lightly either, often a substantial amount of time goes into writing a good issue report. Ideally an issue report contains code to reproduce the issue, information about the expected outcome and the actual outcome, system information, version information and maybe a stack trace or similar artifacts. I also like to include a little note of appreciation for the maintainers, but that’s optional. Keep in mind that issues don’t have to be about bugs – they may also be about possible improvements or desired features. Github even acknowledges the importance of issues by giving you contribution points for opened issues – yay!

Write Documentation

Documentation is extremely important but often lacking, as a lot of people really don’t enjoy writing it. It’s a great way to help a project out by making it easier for other people to get into. Also if you found it hard to get into a project, try improving the documentation so the next person will have it easier than you did. I actually have commits on ruby – they are all documentation commits 🙂

Improve the website

Many open source projects have their own websites. Sometimes the information is outdated and sometimes it’s just plain ugly. I remember the old shoes website – it was really ugly and looked dead (at least that were my thoughts when I first saw it). But look at it now! It looks nice and presentable. And most of it is thanks to wpp – he has never pushed a commit to shoes (that I am aware of), but this certainly was a great contribution for shoes.

Offer to help with art/design

A lot of projects would love to have their logo updated, get some illustrations for their website or similar thing. So if design or illustration is your thing, maybe go to your favorite project and ask them if they want some help with that? I know I’d be more than happy about that!

Trying out preview versions

Developers need feedback if their software works. Therefore, alpha, preview or release candidate releases are made often. Go grab one of those and try it out. If everything works – great, you just made sure it works on your system! If you find a bug – report it! That’s a great help for the project.

Weigh in on Discussions

Sometimes there are discussions about API changes or ways an implementation could be improved (among other things). Comments are very welcome there, maintainers want the input of their users. I once spent a whole day discussing some architectural issues I identified in a project. It was fun. Other work might be setting up a road map – Eric Watson did that for Shoes 4 one day. He’s a great coder, but that road map helped the project more than any code he could have written in a similar time frame. His road map went on to be a very helpful guidance and reference point.

Answer Questions

Questions about a project pop up all around the place. Be it stackoverflow or just the project’s issue tracker. By answering them you help other people to get a better experience with the project overall. Also don’t forget that a question might hint at a problem with the project. Maybe the documentation for this part could be improved or there is a common task that might be automated or deserves a better API? Maybe you could jump in to do this?

Give a presentation about a project

There are many great projects out there, but developers may only adopt them if they know about them! If you really like a project, consider giving a talk about it at a local user group or handing in a talk for a conference. This way the adoption of the project may be increased, bringing more people to the project making it a better and more stable product overall – benefiting everyone.


If you already have done any of the above: thank you! You contributed to open source. Keep doing that if you like, if not give it a shot. If you want to get started on contributing to open source, this post of mine might come in handy. Personally contributing to open source has been an amazing journey for me so far. I enjoy it very much and have made quite some friends that way :).

Shoes4 preview – the more personal release notes

As you might have noticed a big project I’ve been working on for almost 2 years got its first release on the 10th of May a bit more than 2 weeks ago. You can go read the official release announcement. This one is a bit more personal 😉


It’s been a long road from the 24th of May 2012 when the shoes community got together to concentrate efforts on the complete rewrite we call shoes4 now. That is a long time. It’s a time in which we made more than 2000 commits and closed nearly 600 issues.

Why did it take us so long? Well rewrites are difficult… there is an older piece of software in place which kind of does what you want but not really. Still if you release your new version has to be somewhat good enough. With this preview release we feel that all the major building blocks of the Shoes DSL itself are in place. Finally.

This release is really important to me. You know, it’s super hard to work on a project for so long without any release. Without any users. Other than your co-contributors there really aren’t many playing with what you build. Not many people to report bugs. Not many people to build something awesome. Not many people telling you that what you do actually matters. Sometimes this makes it a bit hard to motivate yourself. Therefore I want to thank everyone who during that time encouraged anyone of us, wrote an email saying that shoes is awesome or even grabbed a release straight from github and tried it out. Every time that happened it put a big smile on my face and motivated me to put in a couple of hours of extra work. I you!

Hackers gonna hack

Of course a release doesn’t mean that people are really using what you build. I tried to make a little effort writing the announcement blog post and sending out some announcement emails. So far we have a bit over 260 gem downloads, which is good I guess 🙂 There will hopefully be a wider coverage if we get a release out.

Of course, this is just  preview release. Nothing stable. We’re hard at work and already got some nice new bug fixes and improvements lined up. Stay tuned for the preview2 release and subsequent releases until we hit a release candidate!


Last but not least I want to thank everyone who ever contributed to shoes4 – not only code but reporting issues, just trying stuff out. Thank you really, your support means a lot! Also to whoever funds me or funded me on gittip – thank you!

More personalized thanks go out to Eric Watson and Jason R. Clark! Eric has probably been the most steady contributor to shoes4. He’s been there from the start, still is, still going strong. And hopefully will for a long time 🙂 Recently he’s been hard at work converting our specs to the rspec3 syntax. Jason on the other hand is a more recent addition to the team – his first commits date back to around September 2013. Nevertheless he’s been pretty hard at work solving vital issues and hard to crack bugs. Lately he’s been hunting down operating system handles we didn’t free up!

What impresses me most about the two of them is that they both have a family and a job but still find the time to work on open source. I hope I’ll be the same once I’m at that point in my life! I mean Eric even has 5 children! FIVE! I can’t even imagine what that’s like 🙂 . But that’s super fun too. I’ll never forget remote pair programming with him with one of his kids running around in the background and waiving. Or Jason attributing the first open source contribution of his daughter on shoes. All super fun memories.

So everybody, shoes is coming. Try the preview release. Or wait for the next one. Or the release candidate. No matter what. Shoes is coming!

Shoes on!


How to get started with contributing to open source

I often see people who really want to contribute to open source projects. And that’s great! But often it’s not easy to get started. “What project should I contribute to?”, “What can I do on that project?” and “How does contributing work?” are common questions. It can be scary. I found myself in the same place around 3 years ago. Since then I contributed to a variety of open source projects and am heavily involved in a few (including my own projects). This post is here to answer these questions, give you some help, guidance and share experience.

Step 1 – Find a project

“Where to start?” “Which project can I contribute to?” These are usual questions. The most important principle here is “Scratch your own itch!” – work on a project that you use and that matters to you. There is no point in investing energy into something you don’t care about. Even better if you have a specific issue with a project: some odd behavior, a bug that you work around, a sub optimal API, lack of documentation… you name it. If you use some projects you’ll find a couple of those. I guarantee it – nothing is perfect.

Also try to see if the project isn’t too far off your comfort zone – e.g. if you are a ruby programmer and don’t know much C then contributing to a gem which is primarily a C-extension is probably not the best idea.

Have a look at how active the project is. You’ll want to contribute to a project that is still actively developed and where the maintainers react to issues and pull requests. For this you can look at a couple of things: When was the latest commit made? Look at the recent pull requests and issues: Did anyone comment on them? Is there a crazy amount of open pull requests, some of them like half a year old without activity?

Another advice: Try not to contribute code to a really big project (think: rails) straight away, especially if you are a beginner. Those projects are… well… big. It’s often hard to find the right place where a fix should occur. Familiarizing yourself with the code base unfortunately takes a lot longer as well. Also due to their nature, they often have a lot more issues and pull requests that the maintainers have to take care of. Often that results in longer feedback cycles, somebody else trying to fix the same problem and it diminishes the chance of making “a real impact”. It’s not the ideal scenario for first time contributors in my opinion. With small to medium-sized projects I often experienced that maintainers are a lot happier to get contributions and faster to respond.

Step 2 – What to work on?

If you’ve got an itch you want to scratch you are already mostly ready to go. But first make sure that the problem persists even in the latest release of the software (even better on master). Then search the issue tracker of the project to check if the fault has already been reported. If not, report an issue (or feature request) to see if this actually is a problem/a wanted feature. In the best case you provide a small sample script demonstrating the error along with an expected behavior from your side. You can already mention that you’d like to work on this.

If you don’t have an itch to scratch but a project you’d love to help out: have a look at the issue tracker. Some projects feature tags/categories for newcomer friendly issues – check those out first. Otherwise look for something that seems appealing to you and not too complex.

I want to stress that contributions aren’t limited to fixing bugs and implementing new features. Helping out with documentation is very valuable, that’s how quite some contributors get started. Also writing tests to increase test coverage or refactoring code (hint: some projects use Code Climate – you can check out code smells there) to remove duplication/make it more readable is often very welcome. I especially recommend the latter two as to do this you have to understand the code and therefore get a good first view of the code base without having to add anything.

Make sure to have a look at the README of the project. It often highlights how to figure out what to work on and which kinds of contribution are welcome.

Step 3 – Get your changes in!

Mostly you should make sure that there is an issue for what you want to work on (exceptions include small refactorings). In that issue comment that you would like to work on the problem, maybe outline a strategy to solve it if you already have one and ask for pointers and advice how to go about that issue.

Also look at the README – a lot of projects mention how they’d like contributions to be handled. Also they might have references to style guides or guidelines such as “provide test cases that fail”. A lot of them will also have instructions like these (at least on the most popular platform these days, github):

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Forking is basically creating your own copy of the repository which you can write to. Creating a Pull Request is like saying: “Hey, I made these changes do you want to have them?” In a Pull Request the changes are discussed, commented  and it’s basically the way to get your changes in. I recommend opening pull requests early – as soon as the basing building blocks are standing. The feature doesn’t need to work yet. This way you can get valuable feedback about whether this is the right approach as well as hints and tips leading to the right solution.

Closing Notes

Have fun contributing to open source! There are a lot of nice people out there happy to get contributions of any form. And I can tell you – it’s a great feeling to know you made something better for a lot of people (including yourself!). You might have seen an occasional story about big discussions or fights in pull requests/issues. Please don’t let that scare you. I can tell you that from my experience these are the exception not the rule. Most people in open source are really nice and work together for a common goal. Two and a half years ago I started contributing to the Shoes project. To this day this is the nicest online community I ever met with a lot of really helpful and polite people around! I stayed with the project ever since – gradually increasing my contributions.

I hope this post helps you to get started on your journey into the open source world. If there is something missing or you got more questions please feel free to add a comment.

Accepted for Google Summer of Code working on Shoes

Hi everyone,

this is just a quick note that I’m accepted as a student of Google Summer of Code. I will be working on Shoes, more specifically Shoes4, and the JRuby organization accepted me! So this will be a very interesting path on my journey 🙂

But what does this mean? Well I will get paid to work on an open source project, that I love. Which means getting paid for my hobby, as I already am an active contributor to this project. Which also is your periodic reminder that dreams DO come true. I’m really psyched about this.

I will be working on implementing as many features as possible so that we can publish an alpha release or (hopefully) even a release candidate this year. Not promising anything though – you know what they say about software projects and release dates! 😉

I’ll also make sure to focus on features that will make Hackety Hack run on Shoes4. Hackety is the biggest Shoes project out there and I would love to see it run on a stable platform again so many people can get into programming with the help of hackety again.

I just want to take this opportunity to thank Google for running such an awesome project supporting open source. And I want to thank the JRuby team for selecting me.

Enjoy your summer, I know I will enjoy mine,


Meet 5 software projects making the world a better place logo

I was at an event two days ago where the topic was teaching programming. During this event attendees raised the problem, that there aren’t enough software developers. During the following discussion it was suggested that if you could show the positive social impact you can have through software development, it could be more attractive for people to get into. “If there were any such projects.”

There are tons of those projects and initiatives. Let’s meet five of them right now!

1. Ushahidi

A screen shot of the original Ushahidi web mashup taken form their about page.

Ushahidi means “testimony” in Swahili. It is a project that a group of programmers started in the aftermath of the 2007 presidential election in Kenia. There was a major outbreak of violence and it was simply too hard for bloggers and other people to report all the incidents of violence that eye witnesses reported to them.

Enter Ushahidi. It was an application build quickly by a group of programmers to map out reports of violence on google maps, a so called “mashup”. This way they made it easy for people to report incidents of violence and made it accessible to everyone. Well everyone with an Internet connection.

Ushahidi has since become a platform. Anyone can download Ushahidi and deploy it for their own purposes. For instance Ushahidi was used after the 2010 earth quake in Haiti to report events. Also Ushahidi is open source, so feel free to help improve this awesome project.

You can hear more about it in this highly recommended TED Talk: Clay Shirky: How cognitive surplus will change the world

2. logo
The logo is a platform where people can donate for social projects or raise funds for a social project. You may think of it as kickstarter for social projects. focusses a lot on direct and transparent support of projects. The platform is free to use and they pass on 100% of all the donations. You can see a more thorough explanation of what they do and how this is more effective than conventional funding here.

So how do they finance themselves? Well short answer: Some sponsors and friends help them. Moreover donators are free to give a little extra money to support betterplace. There is also a longer answer.

On a little side note: They are based in Berlin and very nice people 🙂

3. Random hacks of Kindness (RHOK)

hacking at RHoK Berlin
hacking at RHoK Berlin (Photo credit: @anked)

The motto of Random Hacks of Kindness is “Hacking for Humanity”. It is a global community building open technology to help make the world a better place. As such it is a prime example of an organization trying to improve the world through the use of software. You can find a list of projects developed in their wiki.

Random Hacks of Kindness hosts global events, also called hackathons, where people meet and work on solutions for problems together. The next global event will take place on the first and second December 2012. You can check if there is an event organized near you here. I’ll be attending the event in Berlin, so go ahead and join lots of other people and me. Let’s have fun together hacking and doing socially good.

4. Mission of Mercy

Mission of Mercy logo taken from their github page.

Mission of Mercy is a clinic management application for free dental clinics and is used in the United States. This application helps these free dental clinics tremendously by supporting the clinc flow. It was created and is mainly maintained by the awesome Jordan Byron, a co-founder of the Mendicant University.

5. Stadt Land Code

Stadt Land Code Logo
Stadt Land Code Logo taken from their home page.

A German initiative (English: “city country code”)  to support the development of more digital tools for citizens to improve social life. Fields of interest include, but are not limited to: public transport, infrastructure and politics. In general the tools should make it easier to participate and really make a difference. FixMyStreet is a good example of such a digital tool. The initiative includes a work shop and the possibility to win a project funding of 2500€.


See there are lots of software projects or initiatives having a social impact or aiming to have a social impact. Do you know any other social projects? Please feel free to leave a comment!

Many of the projects are open source, so go ahead and contribute or join the next Random hacks of Kindness event near you. Start your own project. Host your own event. It’s up to you.

Why is nobody #rubythankful anymore?

Do you know what #rubythankful is? It’s a hash tag, those are commonly used on Twitter to mark special things. There is even a website displaying all the recent tweets that have been marked as #rubythankful. It first came to my notice (or maybe it was even created) during the summer of 2011 when there was a little drama going on in the Ruby community, which I don’t want to blog about since enough has been said and it had a happy ending (1000s of dollars of donations). During that time someone introduced the #rubythankful hash tag and I was seeing many people tweeting about how awesome this hash tag is and how much they love it. So how about now? How many people are #rubythankful these days?

Nobody seems to be #rubthankful anymore
Not so many it seems (screenshot taken on the 21st of December)

At the moment of this writing there is just one tweet up there, which was tweeted by myself… and it isn’t the first time that the situation is like this.

Why does this even matter?

So people aren’t using a specific hash tag on twitter and as a result of that some home page looks pretty empty – no big deal huh? Well maybe it is, maybe it is not. I just think it’s kind of sad. Everybody seemed so excited about it, I was seriously hoping that it would be something that we, as the Ruby community, could adopt as a whole and incorporate into our culture.

At this point a little information about myself: I say “we” but I’m pretty new to the Ruby and open source community myself (in fact I just really started in the summer of 2011) so this is my point of view, the one of a newbie – so full of enthusiasm.

It’s not just about a hash tag!

And by incorporating it into our culture I don’t mean simply tweeting with the #rubythankful hash tag every now and then. It’s more the spirit that counts. In the open source community there are tons of people spending a lot of time creating software and then giving everybody full access to it. I think that this is one of the most AWESOME things out there. I mean, think about it, those people and the software they create make our lives easier every day – would it be so hard to say “thank you!” every now and then? All too often I see people ranting about open source projects for how they do things, for changes they haven’t implemented, for changes they implemented etc… these people probably use these tools regularly but instead of getting around to show some appreciation I see them criticizing the work that maybe even helps pay their bills. Of course this isn’t the rule, but it happens.

Saying “Thank you!” is just the beginning!

Saying thank you helps, as it shows a good attitude and it shows open source contributors that their work is valued (I’m always totally happy when someone thanks me for something I did, but well I’m still new). But why stop here? Why not contribute to a project you like? So far all the maintainers I’ve contacted in the Ruby world have been super helpful. Maybe you have this little helper method you use every time when you use a specific gem, maybe people would like it to be part of the gem? Why not just look in the issues on github and see if you can help make one of your favorite gems a little bit better? It’s a cool feeling plus you probably learn much about Ruby and the gem while doing so. I used to be REALLY uncomfortable with Meta-Programming until I read and reused some of _why’s code in hacketyhack!

And if that seems a bit too much, just filing an issue to make the maintainer of a project aware of a problem also helps a great deal!

It’s more general than just Ruby or open source…

I also write this post because I feel that this is a more general problem in modern societies, at least in my experience. You can do something well a hundred times and people will rarely thank you or compliment you. However, if after those many times where you did something good you do something wrong, people are way more likely to criticize you/the project than they are to compliment some good work.

So what’s the point?

I guess my point is that we should probably be a little more thankful for all the awesome things people do. When I was beginning to learn Ruby I read a saying “Matz is Nice So We Are Nice” – I loved that! Unfortunately I have failed to hear it ever again… it would be nice if the Ruby community could readopt this saying and maybe give the #rubythankful a little more love again… or maybe even more.

So will you use the #rubythankful hash tag? I know I will.