Benchee 1.1.0 released + why did it take so long

Benchee 1.1.0 has finally hit After, well, almost 3 years. So, in this blog post we’ll dive into:

  1. What are the changes
  2. Why did it take so long, with some (significant) musings on Open Source and bugs as well as my approach to it

What does Benchee 1.1.0 Bring to the table

The star of the show certainly are the two new major features: reduction measurements and profiling! Then there is also a nasty bug that was squashed. Check out the Changelog for all.

Reduction Counting

Reductions joins execution time and memory consumption as the third measure Benchee can take. This one was kicked off way back when someone asked in our #benchee channel about adding this feature. What reductions are, is hard to explain. In short, it’s not very well defined but a “unit of work”. The BEAM uses them to keep track of how long a process has run. As the Beam Book puts it as follows:

BEAM solves this by keeping track of how long a process has been running. This is done by counting reductions. The term originally comes from the mathematical term beta-reduction used in lambda calculus.

The definition of a reduction in BEAM is not very specific, but we can see it as a small piece of work, which shouldn’t take too long. Each function call is counted as a reduction. BEAM does a test upon entry to each function to check whether the process has used up all its reductions or not. If there are reductions left the function is executed otherwise the process is suspended.

Beam Book, Chapter 5.3

This can help you, as it’s not affected by system load so you could make assumptions in your CI about performance. It’s not 1:1 but it helps. Of course, check out Benchee’s docs about it. Biggest shout out goes to Devon for implementing it.

You can simply specify reduction_time and there you go:

list = Enum.to_list(1..10_000)
map_fun = fn i -> [i, i * i] end
"flat_map" => fn -> Enum.flat_map(list, map_fun) end,
"map.flatten" => fn -> list |> |> List.flatten() end
reduction_time: 2
view raw bench.exs hosted with ❤ by GitHub
Operating System: Linux
CPU Information: AMD Ryzen 9 5900X 12-Core Processor
Number of Available Cores: 24
Available memory: 31.27 GB
Elixir 1.13.3
Erlang 24.2.1
Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
memory time: 0 ns
reduction time: 2 s
parallel: 1
inputs: none specified
Estimated total run time: 18 s
Benchmarking flat_map …
Benchmarking map.flatten …
Name ips average deviation median 99th %
flat_map 3.52 K 283.95 μs ±10.98% 279.09 μs 500.28 μs
map.flatten 2.26 K 441.58 μs ±20.43% 410.51 μs 680.60 μs
flat_map 3.52 K
map.flatten 2.26 K – 1.56x slower +157.64 μs
Reduction count statistics:
Name Reduction count
flat_map 65.01 K
map.flatten 124.52 K – 1.92x reduction count +59.51 K
**All measurements for reduction count were the same**
view raw output hosted with ❤ by GitHub

It’s worth noting that reduction counts will differ between different elixir and erlang versions – as we often noticed in our own CI setup.

Profile after benchmarking

Another feature that I’d never imagined having in Benchee, but thanks to community suggestions (and implementation!) it came to be. This one in particular was even suggested by José Valim himself – chatting with him he asked if there were plans to include something like this as his workflow would often be:

1. benchmark to see results

2. profile to find improvement opportunities

3. improve code

4. Start again at 1.

Makes perfect sense, I just never thought of it. So, you can now say profile_after: true or even specify a specific profiler + options.

list = Enum.to_list(1..10_000)
map_fun = fn i -> [i, i * i] end
"flat_map" => fn -> Enum.flat_map(list, map_fun) end,
"map.flatten" => fn -> list |> |> List.flatten() end
profile_after: true
view raw benchmark.exs hosted with ❤ by GitHub
Operating System: Linux
CPU Information: AMD Ryzen 9 5900X 12-Core Processor
Number of Available Cores: 24
Available memory: 31.27 GB
Elixir 1.13.3
Erlang 24.2.1
Benchmark suite executing with the following configuration:
warmup: 2 s
time: 5 s
memory time: 0 ns
reduction time: 0 ns
parallel: 1
inputs: none specified
Estimated total run time: 14 s
Benchmarking flat_map …
Benchmarking map.flatten …
Name ips average deviation median 99th %
flat_map 3.51 K 284.55 μs ±13.79% 277.29 μs 557.14 μs
map.flatten 2.09 K 477.46 μs ±30.97% 410.71 μs 871.02 μs
flat_map 3.51 K
map.flatten 2.09 K – 1.68x slower +192.91 μs
Profiling flat_map with eprof…
Profile results of #PID<0.237.0>
Total 30004 100.0 6864 0.23
Enum.flat_map/2 1 0.00 0 0.00
anonymous fn/2 in :elixir_compiler_1.__FILE__/1 1 0.00 0 0.00
:erlang.apply/2 1 0.03 2 2.00
:erlang.++/2 10000 17.35 1191 0.12
anonymous fn/1 in :elixir_compiler_1.__FILE__/1 10000 30.29 2079 0.21
Enum.flat_map_list/2 10001 52.33 3592 0.36
Profile done over 6 matching functions
Profiling map.flatten with eprof…
Profile results of #PID<0.239.0>
Total 60007 100.0 9204 0.15 1 0.00 0 0.00
:lists.flatten/1 1 0.00 0 0.00
anonymous fn/2 in :elixir_compiler_1.__FILE__/1 1 0.01 1 1.00
List.flatten/1 1 0.01 1 1.00
:erlang.apply/2 1 0.02 2 2.00
anonymous fn/1 in :elixir_compiler_1.__FILE__/1 10000 16.17 1488 0.15
Enum."-map/2-lists^map/1-0-"/2 10001 26.81 2468 0.25
:lists.do_flatten/2 40001 56.98 5244 0.13
Profile done over 8 matching functions
view raw output hosted with ❤ by GitHub

We didn’t implement the profiling ourselves, but instead we rely on the builtin profiling tasks like this one. To make the feature fully compatible with hooks, I also had to send a small patch to elixir and so after_each hooks won’t work with profiling until it’s released. But, nobody uses hooks anyhow so, who cares? 😛

This feature made it in thanks to Pablo Costas, and his great work. I’m happy to highlight that not only did this contribution give us all a great Benchee feature, but also a friendship to boot. Oh, the wonders of Open Source. 💚

Measurement accuracy on Mac

Now to the least fun part about this release. There is a bugfix, a quite important one at that. Basically on Mac OS previous Benchee versions might report inaccurate results for very fast benchmarks (< 10 microseconds). There are many more musings in this issue, but basically we relied on the operating system clock returning times in a value that it can accurately measure in. Alas, OSX reports in nanoseconds but only has microsecond accuracy (leading to measurements being multiples of 1000). However, even the operating system clock reported nanosecond accuracy – so I even reported a bug on erlang/otp that was thankfully fixed in 22.2.

Fixing this was hard and stressful, which leads nicely into the next major section…

Why it took so long, perfectionism and open source

So, why did it take so long? I blogged earlier today about some of the things that held me back the past 1.5 years in “The Silence Between”. However, you can see that a lot of these features already landed in early 2020, so what gives?

The short answer is the bug above was hard to fix and I needed to fix it. The long answer is… well, long.

I think I could describe myself as a pragmatic perfectionist. I’m happy to implement an MVP, I constantly ask “Do we really need this?” or “Can we make this simpler and deliver it faster?”, but what I end up shipping I want to… well, almost need to be great for what we decided to ship. I don’t want to release with bugs, constant error notifications or barely anything tested. I can make lots of tradeoffs, as long as I decide on them like: Ok we’ll duplicate this code now, as we have no idea what a good abstraction might be and we don’t wanna lock ourselves in. But something misbehaving that I thought was sublime? Oh, the pain.

Why am I highlighting this? Well, Benchee reporting wrong results is frightening to me. Benchee has one core promise, and that promise is to measure your functions as accurately as possible. Also, in my opinion fixing critical bugs such as this one should have the highest priority. I can’t, for myself, justify working on Benchee while not working on that bug. I know, it’s not a great attitude and I should have released the features on main and just released the bug fix later. I do. But I felt like, all energy had to be spent on fixing that bug.

And working on that bug was hard. It’s a Mac only bug and I famously do not own or want to own a Mac. My partner owns one, but when I’m doing Open Source chances are she’s at her computer as well. And then, to investigate something like this, I need a couple of hours of interrupted time with no distractions on my mind as well. I might as well not even start otherwise. It certainly didn’t help that the bug randomly disappeared, when trying to look at it.

The problem that I did not have a Mac to fix this was finally solved when I started a new job, but then first the stress was too high and then my arms were injured (as mentioned in the other blog post). My arms finally got better and I had a good 4h+ to set aside to fix this bug. It can be kind of hard, to get that dedicated time but it’s absolutely needed for an intricate bug such as this one.

So, that’s the major reason it took so long. I mean, it involved finding a bug in Erlang itself. And, me working around that bug which is some code that well… was almost harder to write than the actual fix.

I would be amiss not to mention something else: It’s perfectly fine for Open Source project not to update! Sometimes, they are just done. Or the maintainers have more important things to do. I certainly consider Benchee “done” since 1.0 as it has all features I really wanted it to have. You see, reduction counting and profiler after are great features, but they are hardly essential.

Still, Benchee having a rather important bug for so long really made me feel guilty and bad. Even worse, because I didn’t fix the bug those great contributions from Devon and Pablo were never released. That’s another thing, that’s very important to me: Whoever takes the time to contribute should have a great experience and their contribution should be valued. The ultimate show of appreciation is releasing the feature they worked on is getting it released into people’s hands.

At times those negative feelings (“Oh no there is a bug” & “Oh no these great features lie around unreleased”) paradoxically lead me to stay away from Benchee even more since I felt bad about this state. Yes, it was only on mac and only affected benchmarks where individual function invocations took less than 10 microseconds. But still, that’s the perfectionist in me. This should be fixed within weeks, not 2.5 years. Most certainly, ready to ship features shouldn’t just chill on main for years. Release early, release often.

Anyhow, thanks for reading my musings on Open Source, responsibility, pragmatism and perfectionism. The bug is fixed now, the features are released and I’m happy. Who knows what’s next for Benchee.

Happy benchmarking!

The silence between

Sorry y’all, for the silence between.

What happened, why no new post in ~1.5 years? Well, the answer is quite simple: Life happened. First I was at a new job that was honestly quite stressful and took all my headspace, not leaving any space for blogging.

And then, I manged to injure my arms – how exactly I don’t know. It might have been a long time coming amplified by some unusually straining things I did that week. That was more than a year ago. I took 6 weeks off between jobs not doing anything hoping it will be better again soon. It wasn’t. Aside: Worst 6 week stay-cation of my life: at home, not programming, not writing & not playing games 😱 Of course, there was also Covid happening, welp.

Anyhow, I also did lots of physical therapy, saw specialists and did exercises every day for half an hour on a busy day to up to 4 hours+ on a free day. Good thing is, it was neither carpal nor cubital tunnel syndrome. I experimented with voice typing. Lots of stuff, this shit is scary.

I got a couple of breakthroughs – end of Summer 2021 my arms didn’t hurt more by the end of the week any more (as they did after a work week the entire time before). Before Christmas my pain got less to a degree where I could play games again.

And now? I still have varying degrees of pain, but now it’s mild pain and I feel like I can control it due to a variety of measures (braces, exercises, setup, it having gotten better). You gotta imagine, the first months of this I would sometimes get inexplicably strong pain jolting through my arm just because someone gave me an orange and I tried to hold it in my hand. Yeah, it was that bad.

So, I’m happy that I can do some gaming and some open source again. As well, as some writing. There are probably dozens of blog posts trapped in my head, half of which I have forgotten again. See, turns out I really do love software development. And so, while I was handicapped doing it or well was happy I could get to my day-to-day work but not in my free time, I thought about it – a lot.

So, let’s see how many posts I’ll manage to write and how much you’ll enjoy them.

A note on open source & responsibilities

With the last 1.5 years being mostly “I’m unable to do almost any open source or blogging”, I’m really happy that I changed my relationship to it. I used to feel guilty. I maintain big libraries, people depend on them. I need to fix bugs and have them be in great shape. That kinda feeling.

And well, I do still feel guilty. At the end of the day, I owe folks nothing. I provide free stuff. Take free stuff, fix free stuff and be happy. At the end of the day, my health and my life comes first. Doesn’t mean I don’t feel guilty sometimes or like I really need to fix something up, but it doesn’t eat me up and I’m fine. This would have been different

The expectation that maintainers are there to fix stuff whenever and face backlash when they don’t is what drives many people out of open source. I thankfully haven’t faced this backlash a lot, but it’s still a problem. Be better, everyone.

War in Ukraine

Now is a weird and arguably bad time to revive a tech blog. Russia’s unjust war of aggression on Ukraine, his threat of nukes and the unimaginable suffering of the Ukrainian people along with their bravery is on all our minds.

Well, I’m not sure if it is on yours but it for sure is on mine. This hits close to home for me. One of my closest friends was born in Ukraine. I have been to Ukraine for 3 years in a row pre-covid (2017-2019). I was planning to go again.

I gave talks at the wonderful Pivorak meetup in 2017 & 2019. Each time I had one of my closest friends with me and we had a little mini vacation in the wonderful city of Lviv that I want to visit again. Hell, I even have a favorite cafe in the city, I know the city and truly appreciate it. I’m not sure if calling many members of the Pivorak meetup (Anna, Oxana, Volodya, Anton…) “friends” is an exaggeration, but they’re definitely people that I’d excitedly run toward whenever I’d see them hug them and chat with them for as long as I could. And, I honestly don’t know if I’ll ever get that opportunity again. And… that is scary.

It was probably the best run ruby meetup I’ve ever seen, with curios, nice, humble and super active people. Hell, they even ran their own ruby learners workshop. They were shocked that people had forgotten the war in Ukraine and were afraid of Russia… little did we know.

I didn’t only see them in Lviv, some came to Berlin and I also saw them again at RubyC in Kyiv. Kyiv, where I walked across the Maidan square and past the memorials of the brave people who died during the Maidan protests, trying to pay my respect to each one of them.

So, with this background this is hard for me. I feel helpless as I can’t really help them. I don’t know what’s going to happen and what it will take for Putin to stop this war. Well, what I can do (and did!) and you can do as well is donate to support the Ukrainian people. If you’re reading this, you’re probably a software developer and have more dispensable income than most. Consider donating it through whichever means to organizations helping Ukraine. You can find donation links for instance here.

Sorry if this section is a bit more incoherent than usual, but I’m really lacking the words in any language to express how I feel.

So, with all that – why am I blogging/doing tech stuff? Honestly, I often don’t know how to help more. I’ll donate more, I’ll continue to speak up. I can’t think about the war 24/7, it’s hard and yes it’s privilege that I don’t have to think about it 24/7. As my current favorite author Brandon Sanderson said, we deal with these situations in our own way. He writes 5 extra novels in 2 years, I’ll focus some of my mind on open source and blogging. And also, I’ve been waiting for my arms to get better for so long – so I’ve been looking forward to this.

Before I’ll close this “short” interlude blog post, I have one more thing on my mind. Please do not confuse Putin & the Russian government with the Russian people.

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.