Open Source 100: George Goldberg, Mattermost Core Committer
Open source software has transformed the world. This powerful idea—technology shared through a special license that permits its free use and repurposing—is at the heart of almost every major software system in the world, from the website you’re reading to mobile app on your phone.
Billions of people benefit from open source. But only a microscopic fraction of those users have contributed back. What if we could dramatically increase the number of contributors? What if we could expand the idea of open source in a meaningful way beyond software and into more disciplines—like science, business and the arts?
There are millions of people who would want to contribute if only they knew how. Many don’t know where to begin. Some are afraid—are they good enough to have their work become part of a public record where it could be dissected and judged? Could they be embarrassed? What if they made a mistake?
These are common fears, and that needs to change.
The purpose of the Open Source 100 project is to help unlock the potential of millions of people around the world by breaking down these barriers and encouraging them to share their talents with the open source community. In this new series of interviews, we’re meeting 100 people who contribute to open source projects from all backgrounds and learning about they got started and how they made an impact.
Our goal is to find people you can relate to. Folks just like you who needed to learn how to become a part of the community and had apprehension along the way. People who made mistakes and overcame them, and who eventually learned to contribute and then made differences in the world.
We hope this series inspires you to think differently about your potential to benefit the world.
Interview 1: George Goldberg, core committer on the Mattermost open source project
In this inaugural interview, George Goldberg shares his experiences growing up in Cornwall, England and Hong Kong and getting started early with the KDE open source project while a student working part-time at Collabora.
His hobby running a student movie theater eventually led to using Mattermost as an open source messaging app. Seeing the needs of the early-stage project, he began making contributions in his spare time.
Over time, George’s contributions grew and eventually he became a staff core committer at the company sponsoring the open source project. Today, he works professionally in open source, not only developing the software for thousands of enterprises that rely on Mattermost daily, but also welcoming, supporting and empowering a new generation of contributors making a difference in the future of the project.
Here are highlights from the interview:
Open Source 100: We’re here with George Goldberg, who’s a staff contributor on the Mattermost open source project, and staff at Mattermost, Inc. And we’re just here to learn a little bit about George himself, how he got into open source, and what it’s like to work on the Mattermost project. Maybe, George, you can introduce yourself a little bit, like where you’re from, where’d you grow up, what you do in your spare time?
George Goldberg, Mattermost core committer: Yeah, sure. I’m from the U.K. You can probably tell from my accent already. I grew up in quite a rural part of the country, the sort of bottom left-hand corner in a region called Cornwall. And then when I was 18, I moved briefly to Hong Kong, and then landed up in London, where I’ve been for the last 10 years or so. I, some time back, went to university and studied electrical engineering as an undergrad, but I was always a bit more into the software side of things than the hardware side. And while I was doing those studies, I also worked for a company called Collabora, which is an open source company based in Cambridge in the U.K. And I did work on telecoms related software there. Then, after that, I did various bits and pieces, and eventually ended up joining Mattermost a little over a year ago.
Open Source 100: Very cool. How did you hear about the Mattermost open source project?
George: Initially, it was when Slack hit the scene, and suddenly went viral and everyone was talking about it. Every little software project was using Slack suddenly. And, being quite an avid open source person myself, and being very suspicious of the cloud as a default state, the first thing I wanted to do was find an alternative to Slack that wasn’t a closed source SaaS product. At that point in time, it didn’t look like there really was anything, but there were noises about some projects that were coming along that might hopefully be that.
About nine months later, at the university I was at, I used to run a volunteer cinema society, and we had a lot of staff to coordinate. And people wanted to use Slack. We didn’t want to pay for Slack because, you know, volunteer clubs never have any money at all. We had another look. We had an old server in the corner that ran the Wiki, the website, and other things. We’re like, “Oh, can we stick something on that?” There were a couple of products out there to evaluate. I think Rocket.Chat was one of them. And Mattermost had just burst onto the scene with a big kind of, “We’ve just built this huge open source product.”
If I’m honest, neither of them were really quite what we were looking for. But the one that had promise, the one that felt like it would be given enough time, was Mattermost. So I ended up looking, keeping an eye on these projects, and eventually starting to fill in a few missing features in Mattermost. With it being an open source project, that was a possibility. I made a few pull requests on GitHub, stuff to fill in some of the gaps for that cinema group that needed it. I ended up doing all kinds of different things with it, and eventually ended up joining the company to work on it full time.
Open Source 100: That’s an excellent final outcome. What were some of the gaps you saw? From when you started, to the first few pull requests, what were some of the differences that you made that you saw happen in the project?
George: One of the things that was a big deal was we actually had chat history. By then, we’d given in and been using the free version of Slack for a bit, and we wanted to migrate stuff across. There was an importer, but it was a bit half-baked. It was missing quite a few things we needed. So the first place I started was trying to fill in the gaps with that, with the view that, you know, this product’s ready for us to use now, we just need to get the migration right.
From there, that led into other things. Things that we wanted to import that Slack could do but Mattermost couldn’t do yet, like channel linking and that kind of thing. So, I ended up adding the first version of channel linking support and so on. It was quite rewarding. I ended up contributing things that, I guess, weren’t really strictly necessary for the purpose I started out doing them, just because I was enjoying myself.
Open Source 100: Excellent. It’s quite remarkable how quickly you can make a difference in open source projects. You’ve worked on open source projects for a while. What are some of the differences and similarities between Mattermost as an open source project, and other ones you’ve worked on?
George: There’s a whole range of different styles of open source projects. My first meaningful contribution to open source was when I was about 16 or 17, and it wasn’t a code contribution. I started doing miscellaneous bug triage, essentially. Going through bug reports and reproducing old ones, seeing if they still existed, that kind of thing. And that was for the KDE project, so that’s the Linux desktop environment there. It was a very large community, and it was an interesting one. There were a number of companies dotted around the world, many of them based in Germany because that was a project that had its roots in Germany. A significant number of the volunteer contributors were based in Germany as well.
That was an interesting project because it had a few corporate players. But it absolutely didn’t have any corporate players that made up a large enough part of the project to substantially influence it. They could have a little influence here and there. Some of the subprojects were quite heavily corporate, the ones that were of more interest to paying customers of some IT consultancy, and less interest to the community. But overall, it was very much a volunteer-speared project.
That contrasts with a lot of the other big open source projects, like Mozilla Firefox for example, where there is one quasi-corporate nonprofit entity that is very much at the center of it. Or a lot of more modern open source projects, and I would put Mattermost in this category, where there’s actually a for-profit company at the center of this community, and they’re shepherding it. They’re providing a lot of the resources that go into the development of the product, but part of that is there is an open source product. There may be proprietary add-ons, or an enterprise edition, or whatever.
There are slightly different models depending on if you’re thinking of GitLab, or Mattermost, or Elasticsearch, MySQL, and so on. But it’s a different kind of situation. In a purely community-led project, there are challenges around leadership and doing the kind of grotty tasks that people don’t really want to do. Because where everyone’s a volunteer, you end up very dependent on a few people who actually enjoy doing the dirty work.
Whereas where there’s a company heavily involved, it’s a lot easier. Often the company will provide the resources to do the very detailed maintenance, QA, the things that community contributors often aren’t so interested in. But then the challenge there is that you’ve got to balance this large amount of power the company has in the community, and make sure that your community is functional and the power balance isn’t too disparate. If you look at the history of Node.js, for example, they had some serious difficulties they had to overcome around the role of the corporate entity in the community. It’s not without its challenges, whatever model you’re using.
Open Source 100: Yeah. That totally makes sense. In either one of these models, there’s a lot of people out there that have always wanted to contribute to open source, and they’re sort of held back. I’m curious, what do you think holds people back from contributing when they want to?
George: It’s difficult because I think that’s one of those things that’s different for everyone. On a personal level, it can be just not being sure they’re good enough or being a little bit intimidated by it. Once you overcome that aspect of it, I think keeping the contribution path simple is very important. So when someone decides they want to see how they can give something back, often they’ve got a strong sense of goodwill. Maybe they’ve used the product or maybe they’re really excited about the product and they’re like, “I want to give something back.” And it’s making sure that there isn’t so much impediment placed in their way that they lose that good feeling before they’ve given something back.
I think that’s the crucial factor. Making it easy to contribute, making it welcoming, and that there’s a diversity of views on what makes a welcoming open source project. I’m not personally someone with very strong opinions on that subject. I’m sort of willing to go with whatever there. But I think the key is that it does need to be thought about. How do you welcome people in, make sure their contributions are valued and make sure you’re not placing unnecessary hurdles in their way?
And, actually, there’s a point there for an open source project with a large corporate entity involved. When you’re a paid developer working for a company, you’re used to having various hurdles placed in your way of each piece of code you write. Quality assurance, all this kind of stuff. Process. It’s there for a reason. It’s a good thing, but it can be very difficult for volunteer contributors because if you throw a massive pile of some QA at them in order to get their bit of code in, sometimes it just tips the balance to being, “You know what? I’ve spent days writing this code. I can’t deal with this QA.” You can end up feeling unwanted by that. So it’s very important to balance the need for process to produce a quality product but also supporting the community so you’re not saying, “Thanks for this contribution. Now go do these 700 other things to it before we’ll accept it.”
Open Source 100: Got it. When you started first coming in the Mattermost project, what are some things that people might have interpreted as welcoming? What are the things that an open source project can do to welcome people, and what did you find when you started at Mattermost, your first contributions?
George: I think one of the great things with Mattermost, then, was that there was a very clear and not particularly long guide on how to make a contribution. I looked at GitHub. I could see— from the labels and things on pull requests and all that—that there was a process. There was a process that the core team was using. It wasn’t immediately obvious how that process worked, but there was a document which summarized “this is the flow you go through.” And it was short enough that I read it without getting distracted or losing interest or whatever. And that made it very easy, because it’s like, “Oh right. If it’s a help wanted ticket, that means if I solve it, the hurdle of ‘will the team take this’, is already overcome. It’s just making sure it’s technically alright then.”
That was nice. It was like, “I know that this thing I want to add to the product, it’s there as a help wanted ticket. That means they want it, too. I’m not going to spend ages writing this feature and then only have to argue with the core team who don’t actually want that feature for some reason.” That was great. It was like, “I know what I’m doing won’t be wasted.”
And then, when I put in pull requests, there was a fast response that was very welcoming. The PMs in particular, the product managers who are the sort of first stage of review, really knew how to encourage. You know, “Thank you so much for the contribution. We’re going to take a review to check that it looks the way we’re expecting, and then we’ll pass it on to the developers who will check over the code, and then we’ll merge it.” Just saying, “Thanks very much, and this is what we’re going to do.”
It immediately makes you feel appreciated. “I’ve done this and you guys are on it.” It’s the complete opposite of where you put in a pull request and it’s ignored, and you’re like, “Well what’s going on? Does anyone even care? Have I done something wrong? Have I offended them?” This kind of thing. Communication is hugely important in any kind of remote transaction where the people aren’t in a room together. Communication really helps to make people feel appreciated and make sure there’s no misunderstanding.
Open Source 100: Do you ever think, in a non-open source project, that should happen more? Do you think in a non-open source project where you don’t have volunteers, how involved should the product managers be in making sure pull requests are reviewed quickly and keeping the flow going? How important is that when people are paid to do work, and they don’t necessarily have to cater to volunteers?
George: It’s a tricky one, partly because I’m in many ways lucky to not have very much experience of working in non-open source software. I mean, I’ve worked on a lot of closed-source software, but it’s always been in open source companies. So, the open source culture has always been there, even if the particular thing we’re working on isn’t actually being open sourced. I would say that, definitely, some of this process can be beneficial anywhere. I mean, you don’t have to be quite as thorough if you’re working with the same team you’re always working with. They kind of know what the game is already. They know what the process is going to be. But keeping up communication is a good thing just generally. Definitely.
Open Source 100: Yeah, makes sense. When we’ve got people out there who are outside, looking in, they want to make a contribution to the open source project for Mattermost. What do you want them to know that might help them make that first contribution?
George: Have a flick through our contributor documentation. Don’t feel you need to read all of it, just have a little look to get a sense of how it all works. And you’ll pick up from that, I hope, the places where there’s really good immediate opportunities to contribute. Whether that’s code, whether that’s documentation, whether that’s translation, whether that’s integrations. And that means you’ll be looking in the right place. You’ll be on the same wavelength as the core team at that point, and once you’ve done that, the rest is just semantics, really. If you’re on the same wavelength as us, whatever you produce is going to be valuable.
Open Source 100: Very cool. Let me ask a couple last questions. What would you like to see for the contributor community? For all the different places that they could work, what are some places that you’re like, “Hey, if you’re interested in a first pull request, you might try out this. For something meatier, try out this.” What would you personally love to see from the community?
George: Difficult question, that one. There’s a lot of places I feel like we could do more. I think integrations are huge. We’re only really scratching the surface of what’s possible with integrations, particularly with the plugins API that’s just going in at the moment. This is a level of “integratibility,” if that’s a word, that hasn’t really been seen in software of this kind before. And I think, “Blow our minds with the things we never even thought of that you can do with this new capability.”
Open Source 100: Very cool. Yeah, we’re all excited with the plugin architecture. Can you just tell us a little bit more about how the plugins work?
George: Rather than webhooks or slash commands that you’re probably familiar with from all the different software like this—the plugins allow really deep integration, and kind of overriding of all kinds of different parts. Initially, in the first release, we’ve only exposed a few bits and pieces. You can override the popovers. You can override message types. But essentially, we’re moving toward the ability to override all kinds of components of the UI and how the server processes these things.
For example, at the moment Mattermost uses Markdown for rendering batch messages. But with a message-type plugin, you can override that to do anything else. For example, you could have a Slack-compatible one that uses Slack’s markup language. A Jira-compatible one, so your messages from your Jira instance displays correctly because Jira’s markup is completely different than Markdown. You can even have interactive elements in there. You can have messages that you actually interact with and they change.
For example, I’m thinking a GitLab pipeline would be a great one. Having the progress of the pipelines appearing in a message, and the ability to manage those pipelines from within it, and this is ChatOps. This is two-way ChatOps, not read-only. If you think of it like an analogy with radio communication, the old fashioned radios. “Hello. Can anyone hear me? Over.” And then the other person’s replying. You don’t really have duplex communication there. One person speaks to the other. The other speaks back. ChatOps with slash commands and webhooks is a bit like that, but this is taking it to the next level. This is a full-on two-way simultaneous conversation between the humans controlling the systems and the systems that ChatOps is controlling.
Open Source 100: Awesome. And right now, the plugin architecture’s in beta. How does someone get involved? How does someone propose an idea and get feedback for the plugins? Should they just go? Do you want them to interact? How do they understand where the beta of the plugin architecture is going? And how would you advise them to participate?
George: The best way, if you want to talk about anything or find out more about anything, is to join the pre-release Mattermost instance. The core team works entirely on this Mattermost instance, which is public. You can just sign up. It’s pre-release.mattermost.com. Sign up, log in. We’re all there. All the development discussion goes on there. I think there’s a channel called “Plugins” or something similar. Join that channel. Come and talk to the team who are building the plugin system. Ask them any questions. Make any suggestions, and if you’ve got an idea already, just go build it. The great thing about plugins is it doesn’t actually matter what we think of your idea because it’s a plugin. People who like it or want it can use it. People who don’t, don’t have to. So be creative. There are no limitations.
Open Source 100: What’s your handle on GitHub and what’s your handle on the Mattermost pre-release server, for people who want to contact you?
George: On GitHub, I’m grundleborg, and on Mattermost I’m just George.
Open Source 100: Perfect. Alright, well thank you George, and we’ll look forward to hearing more from you in a future podcast.
George: Alright, thanks.
