info.michael-simons.eu

A couple of days ago I was asked above questions: “How to become an Open Source committer?” I think the answer might be interesting to other as well, so I am sharing it here as well.

At some point I wrote a GitHub README.md, which you can read over there: github.com/michael-simons. I think it gives a pretty good idea what I am up to.

While that I probably would fail all of the FAANG assessment tests for getting a job and I am not the person to look for implementing low level optimizations and stuff like that, I think that I am a decently good generalists with deep knowledge in a couple of important things, such as databases and the bigger (server side) frameworks, but also on a language level. My aim is to keep an overview on how things work together and go rather deep into the topic that I am working on in a project.

Anyway, I created a GitHub account back in 2010, my first contribution was a pull request to a jQuery add-on I like but that was missing a piece I wanted. I needed that for my foto project Dailyfratze.de. At that time I was working for nearly 8 years already at a small German company in Aachen, mostly doing Oracle Database based stuff… At the frontend with Oracle Forms Client/Server: Not exactly the stuff that is popular on GitHub. However, I was often blogging about some work related stuff right here, for example this here bulk operations in Oracle, an article that still has hits, or integrating Hibernate of old with Oracle spatial. Many of these old posts have been accompanied by issues in the trackers of the respective projects.

And yes, I do absolutely think that good issue reports are valuable and Open Source contribution on their own rights, very much like contributions to documentation and heck, just fixing typos. So from my perspective, a proper first step can be reporting things. If you work in a company that uses Open Source projects and you ran into issues take the time to create a reproducer. Don’t just go to a project and yell “this doesn’t work”, but pay back by something that is runnable and shows the error. Most maintainers I know are happy to work with that. If you employer doesn’t permit this, I would rethink my time there: Your employer is saving money by using Open Source. While contributing features or fixes is actually not always legally possible, taking the time for proper issues is. And if your own project is that secretive, do a dummy.

My personal journey continues with a log of blogging about rails. I really used it a lot and I like it to this day. For whatever reason, it just worked back then and I found everything I wanted in there. Some posts might be more angry and ranty, but that usually boiled down to gems (those are projects you can pull in as libraries) required native counterparts on the system and well, let’s say that ecosystem was worse on macOS around 2010 than it is today.

Somewhen around 2011 I rewrote aforementioned foto project from Ruby on Rails to Java with Springframework which really got my deep into Java. We started to experiment with Spring in the company, replaced a couple of old applications for the customer with new ones and great success and in 2013, Spring Boot appeared and I have been using it ever since:

The application that I went public with is this biking.michael-simons.eu, still maintained and used (by me). Back in the early days I provided tons and tons of feedback to Boot and somewhen, also small features and bug fixes. In the end, it’s about trust.

At the same time, I had the great opportunity to visit ISAQB trainings and met Gernot Starke, a great personal inspiration. What an honor that he asked me to contribute to arc42byExample. Of course I took this chance.

Up until here the important part to understand is this: I am diligent at my work. Sometimes I overwork, but not too much. I have other interests than spent all day and night coding (More about this here). I was blessed that I started my professional live in a company that fostered and supported its employees: With a budget for trainings and a budget to take time for exploring and learning things. I cannot repeat this often enough: It depends so much on the first impression you get of work life which trajectory you take on and what expectations you allow yourself to develop. If you are a junior and your find yourself in a place that is all about the grind and hustle: Get out. Find something sustainable. I honestly don’t believe in “I hustle until my 30ths and than I stop” thing. Find a place that enables growth on a mutual level.

Anyway, I didn’t grind away with OOS contribution either. I started to experiment with giving talks. First at lokal meetups and (Java) user groups with good success. I somewhat like it, but it stresses the hell out of me. I am more of a writer. But it with some persistence it give me some kinda good name, which is of course valuable, both for contribution and growing a network.

Talks this days is a so-so topic. I personally find it really hard to justify traveling through the world and giving talks at every possible place (and not only eying the pandemic here). There’s no reason for me to fly to Brazil or so giving a talk about Spring Boot or Quarkus. There are excellent developers out in the world everywhere and I would rather coach a person from anywhere in the world to talk about Neo4j than flying ten thousand miles todo it myself just for a day off.

Back to open source: Make yourself a bit of a name. Report issues. Reach out over appropriate channels (tickets, Gitter, Slack; no unsolicited private messages). If you want to contribute code: Look for projects that have for contribution labels.

When you’re excited about a new idea and you might already have implemented it in someway or form and you think “hey, let’s just submit it!”, think again: Imagine the people at the receiving end. Is it a new feature? How will it be maintained in the future? Is it just something for a very small use case? Does it fit the rest? Who will own it? It is often safer to open up an issue and discuss if someone wants a new feature in their project or not. This will safe everybody’s time in the end.

Twitter is a good place for some discussions as well and from a question like this, a great learning across several people can come: Fix potential exponential backtracking in ReflectionUtils array parsing.

If its possible, go out to local meetups or conferences. Don’t just sit in there and spent your time passive, meet people. Talk with them. Listen. Build a network and contribute. In the end it’s a lot about trust and people, as I wrote already in 2017.

I personally was lucky: My close work with Spring and Spring Data people brought me into conversations with two people I would call both inspirational and friends these days: Oliver Drotbohm and later Michael Hunger. With a slight detour trying out consultancy at the good company INNOQ, I ended up at Neo4j. At Neo4j I maintain one of our Open Source projects, Spring Data Neo4j, together with Gerrit Meier. Several other modules have been spun off from there.

This month, I celebrated my 4th anniversary:

Of course, Neo4j doesn’t earn money by paying me and the teams that work on pure Open Source modules (such as connectors and drivers). We do need them however to facilitate the usage of our main products, such as Neo4j Enterprise and Neo4j AuraDB.

For me it was a once-in-a-lifetime opportunity. I get to learn from so many smart people in a world-class database company and on the same time do my work in the open. As said, don’t grind yourself mindlessly away, but also don’t let open doors pass.

Last but not least: Nobody is a worse developer if they don’t do Open Source. It is useful, educational and a lot of fun most of the time, but it’s not required at all to be good at a job.

Update: I had short conversation with Tim about the at when is a good time to enter a project: With rather young or mature projects:

If you follow that thread, you’ll see I spoke also about whether small equals insignificance or not (Hint: Small does not mean insignificance for me… Heck, you might even start something small that YOU need yourself and maybe attracting contributors on your own).

And while I was thinking about that topic, I remembered the initiative from iJUG last year, explicitly sponsoring new people to get into Open Source projects. Markus Karg wrote about this here (in German). While I am personally deeply into Spring and Quarkus these days, the Jakarta EE and Adoption projects are really valuable to the whole Java ecosystem.

And last but not least, sometimes things just don’t work out. Have a look at that small 5 Minute video:

Markus and Andres are both well known in the Java ecosystem, both avid Open source contributors and committers. And even though they followed the recommended approach, asking before contributing a new (small) feature, they weren’t able to get it in. This is super frustrating, but it happens and it happens to experience people as well. Don’t let it get to you if it happens to you.

Title photo by Peter Herrmann on Unsplash