Once a Maintainer: Matt Wynne
On tackling the lack of diversity in open source and creating a deliberate, welcoming community.
Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story. This week we’re talking to Matt Wynne.
Matt has been a programmer since the late 90’s and contributing to open source since 2008, when he joined the Cucumber project, created by Aslak Hellesøy. Cucumber is a tool for running automated tests, written in plain language. Matt worked as lead of the Cucumber open source project until February 2023, where he fostered a welcoming environment and encouraged new contributors, especially those who have been historically under-represented in open source.
Originally from northwest England, he now lives in the mountain town of Nelson, BC in Canada with his family.
How did you get into programming?
I'm born in 1975, and my dad was a university professor back in England. He brought home a computer for doing word processing sometime in the early to mid 80’s, a BBC Micro. It was 32 bit and you loaded programs onto it off a floppy disk, a 5 and 1/4 inch floppy disk. So they're really floppy. I used to get magazines with code listings in them and I'd type the code out of the magazine, sometimes huge long listings. It was just such a cool thing to have in the house. You could take it to bits as well. It could host two apps at a time and I found out somebody that we knew could burn these EPROMs so you could basically pirate. Amazing machine - what a lucky boy I was to have that in the house.
So it went from just doing what it says in the magazine, typing code in without really understanding it, to understanding it, to trying to create your own stuff. I was into composing music for games. That's what I used to do when I was in my teens. Then I came out of university and spent about a year doing nothing at all, and then I decided I should probably get a proper job. I did have this degree, so maybe I should get a job as an engineer.
I ended up at a company that did automation for the baggage handling systems at the airport. I used to go and deploy code at 11 o'clock at night - we'd drive to Heathrow airport with a zip drive with the new deployment on it and plug it into the machines and copy the code on and test it out. If it didn't work, we'd have to roll it back at like 2 AM because that was the cutoff period where, you know, planes are going to start needing to take off and bags are going to have to start going around the airport again. So that was when I first started getting paid to write code. I think that was C probably then, but I quite quickly started learning how to write for the web and then found Ruby, and the rest is history, I suppose.
How did you end up working on Cucumber?
So I had been practicing test driven development for a few years at that time, working in C# as a contractor. I went to a conference talk about acceptance testing, and the speaker talked about what they were doing with RSpec Story Runner and I was just like this is amazing. This is what I want to be doing. They were trying to write TDD tests but they could be read by anybody, not just techies. I was getting paid really well to write C# as a contractor, but I quit that and got a job at a little startup writing Ruby because I wanted to be part of this scene of people using RSpec and doing BDD.
So I went into this little startup. I was like developer number three if you count the CTO, and we used Cucumber from day one to test drive this whole rebuild of their Rails app. And so I was one of the very first users of Cucumber, and when I started out I didn't know any Ruby, I was learning Ruby on the job. I couldn't really contribute to the code, but I figured I could contribute to the community by answering questions on the mailing list. I figured I could just help people who are a little bit further back on the learning curve than I was. And then I'm quite good at writing, I guess. So that led to when David Chelimsky wrote The RSpec Book, there was a chapter on Cucumber, and David said to Jacquelyn, the editor, “You know, there’s a whole book in this.” And Jacquelyn said “Oh, who do you think should write that?” And he recommended me because of my writing for the mailing list. By that time I’d met Aslak in Chicago and bought him and Dave a bottle of whiskey each to say thanks for all of their work.
And yeah, we hacked together on Cucumber, and we built this wire protocol that’s still used today. You can use Cucumber to drive automation steps that are running through a TCP socket on embedded devices and stuff.
So really it started in RSpec and Ruby at the beginning, but pretty early on you made it useful in other languages as well.
Yeah, I mean, this is really Aslak’s genius, the Gherkin Syntax. It's become kind of ubiquitous in a lot of ways, much broader than Cucumber even. We've been through probably at least four iterations of the parser infrastructure to read those files and turn them into a meaningful model. The second iteration was Ragel. And Ragel generates code in lots of different languages. So then we're like, oh right, okay. We don't have to have these weird bits in Ruby, and then a wire protocol talking to a server written in C# or something. It can actually just compile C# code that compiles these files and then somebody writes the test runner on top of that. So then we ended up with this project that if you go into the Gherkin repo, we've got something like 15 programming languages. You're building the Java and the Ruby version, but you're also building the Perl version and the Python version and the Go version. There's even a Dart one that somebody submitted.
What's your favorite Ruby package?
It's a hard question and I have to admit I don't write much Ruby at the moment, so I'm not in the ecosystem working with the latest and greatest gems. But I was very fond of Capybara. I used to do a lot of automation of web apps in my job back in the day when I was working with Cucumber a lot and they were just very mature, well written tools, really nice to use. I also think RSpec itself deserves a mention because it it's really well written, really well designed, and it does some amazing stuff now as well, like randomization and things like that.
How do we get more people into open source?
Well, this is a really big topic. I got kind of back into the leadership of the open source project when we moved here to Canada. I spent the last two years running the Cucumber open source project, and a lot of that for me was trying to maintain the health of the community and think about who are going to be the next maintainers. Because we've got these different language versions, we need somebody who's a Java specialist, we need somebody who's a JavaScript specialist and so on.
At the time, the person who'd been the Go maintainer of Cucumber had walked away, and we didn't really have anybody owning that project. I didn't know any Go and I wasn't going to drop in and start - what I needed to do is find another Go maintainer. And one thing that really struck me, when I turned up to the Thursday call (we have a weekly Thursday call with all the community members), is everybody there was a white guy. And I thought really hard and I started going to diversity meetups and started to sort of study like, why is this and what can we do about it? And I think so much of it just comes down to privilege, because we white guys have the most spare time of any demographic. We tend to have more spare time, we've got less stuff to do, white men particularly.
I was coaching this woman who's a maths graduate, she's super bright, had almost graduated university in maths and she was delivering pizzas. I would ask to do a pairing session at a time early in the morning. And she'd be like, I probably won't be up till 11. And I was like, oh yeah, a student not up till 11. But it turns out it's because she was delivering pizzas till 2 o’clock in the morning. She was working a job because she needed the money to get her through university. This is a young black woman in California. I never needed to have a job when I was at university. My parents were able to give me enough money that I could live off of. Now when I went to university it wasn't as expensive as it is today, and my course fees were paid by my local council in those days, but still, that’s another barrier.
And if you're a young black woman and you walk into an open source project, and all you see is white guys, and quite often those white guys are being very white guy to each other, right? They’re quite aggressive in the way that they communicate, and that just sets up another atmosphere that just makes people feel like I don't belong here. I'm intimidated. What if I make a mistake? You’re doing everything in public and it feels really intimidating to people.
So how do we get more people and more diversity into open source? I think we have to figure out how to fund it, so it's more equitable and everybody is able to participate. I've had a huge amount of benefit in my life from getting into open source and the connections that I've made. I've built a company around an open source project. Not everybody's got the spare time to sit and hack on things in the evening when they're in their 20’s because some people have to work a part time job or whatever. So I think making it equitable so people can get paid to work on it.
And then individual projects having the courage and the leadership to stand up to people that are being assholes and being bullies and say this is not okay and kick them out of the project if necessary. And just from there creating an an atmosphere and environment that is about learning and sharing what you know and being deliberately welcoming. I remember when I changed our pull request templates, I iterated loads, and I used to do almost, like, usability testing. Just the words that you use in those pull request templates can be really intimidating to people. And I polished and polished and polished them. And the Cucumber ones are now full of emojis, and they're trying to be really friendly. I remember one of the maintainers was like, “Why do we have to have these emojis in it, it looks like a toy or something.” That's a kind of reaction a lot of people have got who are already on the inside, like, why is this necessary? But it's necessary because we have to be deliberately welcoming to people. They're already feeling lost. Somebody described it as turning up in a new city and there's no map and you can't read the signs and you turn up in an open source project. It's just super confusing and intimidating. So you have to make a deliberate effort to do the opposite.
There’s something about this that feels very like backwards to me. It feels to me like an open source contribution should be the most welcoming thing that someone can do. You're giving away your time for free to help this project that is also free software.
I think everyone has different motivations for being involved in open source projects. I actually positively want to code in public now. Like I want that exposure and that sort of vulnerability of like, look at what I've done. And you know, the more feedback I can get on it, the more I can learn.
This is age-old. This is one of the things I had to work out of Cucumber’s docs and and to some extent the way other maintainers would interact with newcomers. It's this idea of sort of like, oh if you've got an idea send us a pull request, you know show me the code. Rather than, “Oh, have you got an idea? Do you want to have a pairing session?” and we'll explore it together. There's this idea that I'm really busy and a bit stressed. Don't waste my time with your daft ideas unless you're willing to step up and write the code.
Right, my project is open for a contribution from someone who gives me something better or as good as I would have written myself. And otherwise, forget about it, don't even give me the idea.
Otherwise go away. And this “don't waste my time” thing I think partly comes from the fact that [maintainers] have got limited time. And they're trying to protect that, and I think that's fair enough, but it also means that we're missing out on a whole massive demographic of people who are never going to bust through that barrier with their personality and just go no, I don't care about you being mean to me. I'm still going to show you my attempt at the code and try and learn from your terrible feedback. Not many people are willing to go through that.
I spent from 2013 to 2019 trying to build a sustainable business around an open source project. And it was really, really hard. And yet I know that there were tons of companies all over the world that were getting value from our product, from our free open source products, but those companies just didn't give back. Most of them didn't give back. And actually I think the more mature we got as a product, the further we got towards the other side of the chasm, the worse that problem got. More of our users were people who might not even know how to find the repository where the source code was, let alone crack it open and start making changes to it.
We’re talking about companies contributing financially to open source projects, but there's also this aspect of behavioral modeling that you're doing as a maintainer, that's also happening or not happening within companies, right? The engineering managers, the CTOs can give them some resources, and the time.
If they can find and be guided to find the right project where there is a good atmosphere and you can learn versus the work that you're doing at work which is maybe more time pressured. One of the beauties of open source is nobody's pressuring you to meet a deadline. If you want, you can rewrite something three or four times, try different ways of doing it.
There's a pace to it that is really wonderful for practice because you can really just take as long as you want. And that's actually something that I think as workplaces, we need to give programmers more time to practice. You know soccer players don’t just play matches all day long, right? They play maybe 2-3 games a week and the rest of the week they practice. And programming is completely skewed the other way around. I think if people were getting more time in their jobs, that would be a really good start to explore open source and to practice.
If there are people out there who are interested in exploring open source, how do they know which projects to approach? And we can put some resources in at the bottom as well.
It’s trying to find this intersection between what is something that you use, or you are interested in using? I've only ever really contributed to open source projects I use myself. That's where I get my motivation from. And then, is it in a programming language that you either know about already or want to learn about? And then third, the disqualifier - are there assholes on the project? Is it a nice project that's friendly and well run and people are going to be supportive? You've got to try and find the intersection of those three I think.
OK, let's finish up with who do you think is doing really interesting work?
I'm really interested in these folks who are pushing back against all the hype about AI at the moment. I've been following a woman called Emily M Bender, and also Timnit Gebru. She was fired I believe, or let go from Google. She was on their AI ethics team.
There’s also a guy called Dan McQuillan in the UK and I've got his book which is called Resisting AI - An Anti-fascist Approach to Artificial Intelligence. He's got this thesis; it’s not that AI is fascism, but AI at the moment will do things that can easily enable more fascist stuff in society which is obviously not good. I just like that these people are calling this stuff out and getting us to challenge the more breathless types around AI. I think it's important for us to be thinking and talking about those things.
Some resources for newcomers who want to contribute to open source, provided by Matt:
https://egghead.io/talks/git-how-to-make-your-first-open-source-contribution
https://www.firsttimersonly.com/
https://github.com/MunGell/awesome-for-beginners
For maintainers:
https://www.theopensourceway.org/the_open_source_way-guidebook-2.0.html
This Twitter thread has lots of recommendations for projects that are friendly:
https://twitter.com/github/status/1507068733407346693
Once a Maintainer is written by the team at Infield, an app that helps engineering teams keep their open source dependencies up-to-date.
To suggest a maintainer doing awesome work in the community, find us on Twitter at @infieldai. To share, hit the button below: