Once a Maintainer: Will McGugan
How an open source project and love for the terminal resulted in Textualize
Welcome to Once a Maintainer, where each week we interview an open source maintainer and tell their story.
Once a Maintainer is written by the team at Infield, a platform for managing open source dependency upgrades.
How did you get into programming?
My first exposure to computers was way back in the 80’s when my mother bought me a ZX Spectrum 48K. It was like a little home computer back in those days, and that was it. I was kind of hooked. I think I was nine or something. And yeah, I just discovered an aptitude for computers and a desire to tinker. I studied computer science at uni, but I dropped out after two years and got a job making video games because that was kind of my end goal.
I worked for a few games companies in Scotland. Two of them went bust, so tragically the games never got released. I worked for Evolution Studios, they make PlayStation games. I was working on PlayStation 3 games, like one of the first PS3 games, MotorStorm. So yeah, I've worked on varieties of bits of games and that just led to a career down the line.
Did you teach yourself graphics programming? How did you learn to work on games?
Yeah, I used to learn from books which we don’t see much nowadays. I had stacks and stacks of books on graphics technology and video games and I just devoured them. That’s basically how I learned.
Did you have any kind of community around you in doing this?
There wasn't really, because I grew up in a small town in northeast Scotland, and we all had computers, ZX Spectrums, Commodores, etc. and most people just used them to play games. So it was not much of a community. Later on I started subscribing to magazines where you'd get a floppy disk and it would have kind of like a website type thing and some other game demos and you could send your work there and it would be distributed amongst other people in in the UK, but that was pre-Internet. So I didn't actually meet anyone in that community.
How did you eventually find your way into the open source community?
Open source was a natural progression of the kind of things I was working on. You know, I'd build things and when the Internet came about, it felt natural to want to share your work. So I guess that was open source before I'd even heard the term open source. I used to put my code on my website. This was before GitHub and Google Code. And then Google Code came along and I put my work there and it started being used by a number of people, and you start to get feedback. So that’s how I got into open source, sharing my work and using the work of others.
Are there any projects that you remember from that time using and thinking, oh this is really amplifying what I can do by many times. Does anything stick out in your mind from that time?
Yeah, there were some libraries I used a lot. There's a library called wxWidgets. It's a cross-platform GUI library, so you could write something which worked on Mac and Windows and Linux. And there's quite a big community around that, people building various widgets and things and they would share them. And there was also a Python wrapper for that called wxPython. I used that quite extensively.
So what led to eventually creating your own open source project? I mean, it sounds like you were building things all along, but what made you take the leap?
Yeah, it kind of ramped up over the years. I put several libraries out there, first on Google Code and then on GitHub and then some of them started to get traction. It went crazy when I published rich. Rich is a Python library for nice formatting in the terminal, and there seemed to be a real need for that. When I released that, it just became massively popular, it just kind of took off in the Python community and now everyone's using it. So that's how I became well known in a very certain kind of niche.
There were lots of libraries out there which did part of what rich does, but they didn't work well together. So if you had say a library that does tables, and a library that does wrapped text, you couldn't put the wrapped text inside the table. And I really wanted to do that. So I built a system where it was composable and you could combine these things together. Nothing else did that at the time. Maybe you could trace it back to being in my small, small town and having no one to share these things with growing up, but that was definitely part of my motivation.
How did rich end up resulting in Textualize?
Yeah, so it was just over four years ago, actually. This was just before the pandemic, like literally a couple of months. And I was actually in Wuhan at the time because my wife’s family is there. So really crazy timing.
So I was working on rich, which is basically static content in the terminal, but people were starting to want to build applications with it. And I resisted for a while because, you know, I wanted to reclaim some spare time. But then I saw what people were building with it and they were actually attempting more full screen applications, and I thought, wow. This is so much more promising compared to libraries we used to use.
Is this like curses?
It's exactly like that. Curses was how people wrote these libraries. But they haven't moved on much since the 90’s.
It’s very hard to use. You have to be very motivated to build things with it. And I experimented with Textualize to see if I could build some kind of application library which did a better job. And I proved to myself after a few months that yeah, it can be a lot easier. And that was how it started.
So the idea is we built this application platform which people can build these libraries very quickly, faster than web apps, and you can distribute them in the terminal, but you can also turn them into web apps if you’d like. That’s what Textualize is based on.
How do you manage that human side of the community that you've built?
It is a lot of work. It's mostly asynchronous. In the Textualize team, we've got four developers, but there's lots of contributors and lots of people posting issues, so we try to respond. To those people, a lot of it is misunderstanding the docs, and we just point them in the right direction, but that kind of interaction is very important.
What we're working on at the moment is what you might describe as issue-based development. The issues can tell you where people are having trouble with your API, so you can focus your efforts there and refine it. It can also tell you what features they're missing, so you can build those features. And it means that you're always just ahead of what people need it for. So you can build the things that people need now rather than build the things people need in a year or two.
I think that's the strength of open source. If it's closed source, you don't have as many eyes on the code and you can't refine it as well because you've only got a handful of people looking at it for a year. When you release it, that's when you get feedback. But with open source, you get that feedback from the community and you know straight away.
Have there been any contributions from the community that just struck you as interesting or impressed you?
Yeah, with something that runs in the terminal you’d think that you’d do particularly terminal things, but not always. We had someone build a piano emulator in Textual. I've never thought someone would build that in the terminal, but it's quite cool. They've got all the keys and everything and you can click each one and it plays the MIDI music. It’s fun watching creative people take what you’ve built and do something really for themselves.
What are some other projects that you're using or you've come across that you think are really interesting right now?
There's pydantic, which got funded recently, that’s quite an interesting project. It's a data validation library that uses Python typing, so it's very easy to express in Python form. It's very natural.
There's also a project called MkDocs that's really excellent. It basically builds docs and it can extract signatures in your code and it looks really nice. It's very navigable. That's a really terrific project and he's doing amazing work.
To suggest a maintainer, write to Allison at firstname.lastname@example.org.
If you’re interested in learning more about how Infield can help your team keep its open source dependencies up to date, write to email@example.com.