Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story. This week we’re talking to Marit van Dijk, contributor to Cucumber JVM and expert in Java and behavior-driven development (BDD). Marit is a regular speaker on dependency management. Marit lives in the Netherlands with her family where she currently works as a developer advocate for JetBrains.

How did you get into programming?

So I studied a mix of social science and computer science at university. In the Netherlands it’s called Social Science Informatics. So that's a program that is a mix of social science and computer science. Actually I started as a psychology student, and then in my third year I started doing computer science on the side and then just found it way more interesting and more practical in the sense that I had an idea that you know, I can get a job with this. So I have a Liberal Arts degree from the Faculty of Science, which is fun.

Some of the classes were programming in Java 1.2 at the time, a long time ago, and I really loved it. But I got really frustrated when doing the actual coding. It doesn't work, and it doesn't work, and that was really difficult. So when I started working in IT, I did a bunch of other stuff - I was an information analyst for a while, a project manager, and then through a reorganization, I got back into coding. Then I had to basically re-learn Java 1.8. I did a lot of like coding challenges for practice. And then I thought, I want to work on something real. And you know, I don't want to build a side project that is extremely contrived, and I can't think of anything to build anyway. So I thought let's work on real projects and I can learn from that, but also do something that's actually useful instead of building another, you know, this, that or the other. So that's how I got into back into programming and into open source.

And what led to becoming a member of the Cucumber project or or maybe before that, what was your first foray into into open source?

So the Cucumber project was serendipity, really. I'd worked as a test automation engineer for two years and through reorganization, I got back into programming. I was a project manager before that at a bank. And as a project manager, you know, sometimes you work really hard all day and end up further from your goal. If you're programming, usually you have something tangible, or at least you learned what doesn't work. So I realized I actually really liked that. I love programming. I changed jobs to work at a different company, also as a test automation engineer. And I had heard about Cucumber and wanted to start using it for our test automation. What I liked was that you could reuse certain parts - you write tests, you have steps, but then you can reuse those those steps. So you can sort of build new tests faster. Whereas the project I'd worked on before, there was no reuse and it was a mess.

So yeah, I really liked using it and and one of the tips that I'd read was to work on something that you like using. So I just started looking for issues. I think the first thing I worked on actually, I messed up something with Git, which I hadn't learned properly by then. And I messed up. And I thought, oh, they're going to be very upset with me and want nothing to do with me and want me to go away. And they were actually really, really nice about it. They were like oh, let us help you fix that. Do you still want to contribute? Because they were like, hey, somebody wants to help. They were super enthusiastic. Rien, who is the currently the main maintainer of Cucumber JVM, helped identify issues that I could work on that were, you know, small enough and easy enough to get started when you're not familiar with the code base or anything. Sometimes still when I have some time I'm like, hey, do you have something for me to do?

From what I hear from other people, I think I really lucked out because I've also had friends who did a random small contribution somewhere and people were like “No, no, that's not needed, that should be obvious.” When they're trying to add to a small part of the documentation, you know, they try to run the project for the first time, it doesn't work. They figure out why it doesn't work, they try to add that to the ReadMe or the project and they're like “No, no, that should be obvious. Everyone should know that.” OK, thanks.

Right. I'm trying to donate my time to give you some work for free. And that's the response that I get.

Sometimes I do get it because people come in with ideas of, “Hey, this should be completely different.” And I get that maybe from your perspective or in your use case, yes, but if we take it then we would end up having to maintain that and it doesn't play so well with the current structure or other features or where we want to go with the project. So yeah, if it's a bigger contribution, check with the project before you do all your coding to make sure that it's something that the team wants or that you're implementing it in the way that they want.

I once saw a video clip of a drive-by contribution where someone was like “OK here's a contribution” and you make comments and then there's just radio silence. It’s like “Here, take my contribution, take it or leave it.” And I’m more of a fan of the collaboration aspect. I worked for a long time on the Cucumber documentation, which you know, still isn't great because we all do it in our spare time. If we had someone who was a technical writer, it would be a lot better. Even though I was the the main person working on it, I would still do PRs for all of my changes. And someone somewhere in the world that I’ve never met would do reviews on those and find little things that could be clearer or mistakes that I've made and and just make little tweaks that made it even better and and that's my favorite part of working with people on software is that if you work together you make it that much better.

What are some of your favorite open source packages?

I don't actually use Cucumber anymore, but I do love the community because I'm still a part of it and it's still a place where if I want to get my coding on, I can just ask for something to do. I use JUnit a lot, always for testing, even with Cucumber. That’s a Java unit testing framework which is really great. And maybe some adjacent testing libraries that make you do more fluent assertions or like AssertJ or Hamcrest or things like that. Testing is important, having come back to software development from test automation. I was a test automation engineer for a while, then I became a software engineer and now I'm a developer advocate, but only as of last summer, so that's also new.

How do we get more people into open source or even more specifically, how do we get more women into open source? Do you have thoughts on that?

Well, I'm not sure it's getting women into IT and open source as much as not actively chasing them away. You know, if we could start by not chasing them away, that would be great.

I think that diversity, not just women but people with different lived experiences in IT and open source would be beneficial to everyone because having different lived experience also makes you think of different use cases or in certain cases, abuse cases. How could this be abused? What could possibly go wrong that if you didn’t have that experience you might be blind to? I live as a white person in a western country and when I travel, you know, they will let me into another country. I can get a visa and I don't have any problems with any of that. And I was talking to some of the people on the team who are from other countries, maybe outside of Western Europe, maybe aren't white, and they are much more careful. Like “Oh, I print everything when I travel and you know, sometimes even I need to have information of the exact hotels where I'm staying.” and whatever. And I just never thought of that.

Alsounderstanding that English might not be their first language. It's not my first language, it's my second of several. But you know, sometimes we get questions where clearly the person who's asking isn't a native English speaker and having the patience to deal with that rather than “Yeah, this question is unclear. Close issue. Bye, bye.”

That's a simple thing, just taking into account that when you're working on an open source project, people might be anywhere in the world and might be in different time zones. If you do a PR, it's customary to wait at least 24 hours before merging so that all the time zones have time to look at it. And even then I probably wouldn't do it so fast. It’s not like corporate software where we need to get this feature out because that has business value. Of course getting new features out or or fixing bugs adds value for the developers who are using it. But there's nobody actively waiting for it, except maybe for security issues, in which case I also know people who've worked really hard on on fixing it and getting it out there as fast as possible. But under normal circumstances you would wait for all of the time zones to have a chance to look at a PR.

Another example is that for Cucumber you can use it in multiple languages- programming languages but also natural languages. So you can write the feature files in multiple languages and the keywords. We had someone come in who had a request for Dutch keywords, which is funny, because Rien and I are both Dutch. So then Aslak, who created Cucumber originally, asked us, “What do you think of this request? Do you agree or or disagree?” And since we were both Dutch we were like, yeah, I see where you're coming from, but still I like the current one better for these reasons, yada yada yada. So this is where it helps if you have people from different nationalities who speak different languages.

Who’s someone you think is doing really interesting work?

I have a friend who's a professor at a university, Felienne Hermans. She created a gradual programming language, it’s called Hedy. It's based on Python, but it takes you there step by step. So rather than learning Python and having the compiler yell at you when you get it wrong, she built it so that it sort of hides away the compiler yelling at you. It gives you better feedback when you're learning, so it doesn't discourage people, and apparently especially girls are discouraged by the compiler yelling at them. She teaches programming to 10-12 year olds who are maybe too old for something like Scratch. They say oh, my brother and sister use that, I’m too old for that. So she wanted to do something textual, but then they start using Python and they get frustrated. I’m a huge fan of her work.

Once a Maintainer is written by the team at Infield, an app that helps engineering teams track and plan their dependency upgrades.

To suggest a maintainer doing awesome work in the community, find us on Twitter at @infieldai. To subscribe, hit the button below: