Design, software, and open source

So before we get into p5.js, you have a pretty interesting background in terms of how you got into open source in the first place. Can you tell us a little bit about that?

Yeah, I guess I have some background in computer science - or I did, just like undergrad, but I really moved more into an arts space after that. But I was doing art using software, so I used a lot of open source tools, some of them tools called open frameworks or processing. It was after grad school that I started thinking about “Oh, who makes these tools? I wonder if I could help or give back in some way”, because I was working at like a design studio at the time, so I thought I could probably get some time to help with these.

I didn’t really know where to start, but I just kind of joined some mailing lists and thought I could kind of figure it out. The thing that I found was that it was really hard to know where to begin. I was kind of like, “Oh, I’m here, I wanna help!”, and no one really reached out; I felt like, “Oh, okay, I’m gonna have to elbow my way in here.”

That just didn’t work for a while, until actually Casey Reas, who makes the Processing project along with Ben Fry and Dan Shiffman - I had a conversation with him and I was kind of mentioning this and he invited me, he immediately reached out and said “Oh, do you wanna work on Processing?” and kind of gave me a really structured in to do that. So it kind of went from there; I had no idea what I was doing at first, but I think that was one of the things that was really special about my entry to it. In a lot of projects you do have to know what you’re doing and prove yourself right off the bat, and they really gave me space to just be totally confused and totally lost for a while, and kind of find my way into the project.

So did you create p5.js or was it a collaboration with other people? How did that all work?

Yeah, so I guess when they asked me to work on processing, the idea – well, I said “I’ve just been starting to learn JavaScript, and I think it’s really cool… So if there’s something I could do with that…”, and they said – so Processing, maybe to back up a minute, is like a platform for making graphics or interactive experiences or projects, and it’s designed to be really friendly for beginners or for artists or for non-technical people, and it’s based on Java.

[04:16] So it kind of came out of this frustration that with Java you would have to write all this code and know what you’re doing pretty well just to get like a circle to appear on the screen. With Processing, the idea was that it’s just one line of code to get you a circle on the screen, and with one more line you should be able to change the color.

So the task they gave me (or the question) was, you know, Java, when they began the project in 2001, was the de facto language to be working in, and since then - this was like 2013 - there was some energy around the web, or JavaScript specifically… So they were asking “What would Processing look like today, or if it were made for the web?” And so out of that came p5.js.

In the beginning it was me, and I was working with a collaborator, Evelyn Eastmond, who also had some experience with another learning platform called Scratch.

Was she at Bocoup…?

Yeah, she was, and then now she’s working with – what’s it called? HARC. Human Advancement Research Center; it’s the Ellen K. It’s the Alan Kay research group.

Cool.

But yeah, so we were working on that together for a little while, and then she ended up kind of moving away from the project right before we did a public release at the first year maybe… It was the two of us working together on that.

I recall that there was sort of like a proof of concept of Processing in JavaScript that John Resig, the creator of jQuery did at one point… But it didn’t really have – how do I put this…? It didn’t have all the things that make this useful. p5.js has a lot of things that really help you along, and it was more of just a proof of concept for the language. So was there ever any kind of problem with creating a new version of it, or anybody saying “Can we build on top of this?” or was it just people going “Oh yeah, this is actually something that I can use”?

Yeah, there was a little bit. When John made that, he kind of, I think, did a very – he was able to do it actually pretty quickly and just ported Processing to JavaScript. It was less like a project that he wanted to maintain and more like you said, a proof of concept, and put it out there. Then since then, other people have kind of taken that and maintained it to some extent, but it just didn’t quite have the parity with where Processing was, or the maintenance support to make it really robust.

We talked a little bit with some of the people involved with that project, and then I think ultimately decided to try and remove any existing requirements or infrastructure and just start from scratch. One reason was that we were really thinking of this not as a port to JavaScript, but like a reinterpretation for the web. So a lot of the syntax stayed the same, but I felt free to change it in the places that it needed to change, or to add to it or to remove things that didn’t make sense, and to have that be really clear in our minds, that like – you know, one thing we were dealing with was it was kind of an interesting audience, because we had people that were long-time Processing users that wanted to move to the web or move to JavaScript, and then we also had people that were native web users that might be interested in this project, so we were trying to make something that would kind of fit me in the middle, because a lot of the syntax with a Java-based language feels strange perhaps for JavaScript, right? It’s not a perfect one-to-one, so we were trying to find something that didn’t alienate or supported that audience that was coming from Java and from Processing, but also trying to make something that really felt like native and like a fit on the web and wasn’t like this kind of out of place thing.

[08:27] I think there were some tensions around like “Why not just put this energy into (the other project was Processing.js) Processing.js?” And yeah, I think it was really just being able to kind of start from scratch, and I think also where I was at the time when I started the project, I just didn’t really have the JavaScript experience really to take a project that was so developed already and figure out how to work with it. I was literally kind of learning about objects and functions at the time, which is kind of crazy… So like starting from an empty slate, let me build things up and then go back and be like, “Oh, this part needs to be rewritten” or “Now I understand what I’m doing here.”

That’s interesting. There’s such a huge audience for this… What did you do to kind of get the word out a little bit and promote it, and then what was the community response around it?

Well, like I said, there’s a few different audiences, and with the Processing audience it was not too hard. I mean, one reason for choosing the name p5.js was like the “brand” recognition… Because we had some ideas of just like other names that might be fun to use, and I think the word “processing” has always been kind of confusing. I have students that are like, “Oh yeah, I’m going to Processing it.” They don’t quite understand it’s the name of the language, because like, why would they? It sounds like a task, or it’s hard to google, because you search for “processing” and then all sorts of process-related things come up. And then p5 isn’t much better, because the name comes from – originally, when they got the Processing domain, it had fives instead of the s’s, so people would call Processing p5 for short. So we chose the name to have sort of a connection, to give it sort of a legitimacy in the eyes of people that were Processing users, and I think that really helped in terms of – you know, one of the big audiences is schools, people using it as a teaching tool… So to have something that felt clearly associated with Processing helped.

Then there was also this audience of web users that I was excited about; maybe they were people that were artists or designers, or maybe they were also just people that were not that, but were interested in doing more of that, and maybe they already had a fluency with the web, but were actually looking for something that would give them an in to making graphics, or making more creative artistic things. So I think getting it out to that audience really depended on collaborators and people in that community. Nadia, you mentioned Bocoup already; they were helping a lot, especially in the early development of the project… They were just so gracious in inviting me and Evelyn there and giving feedback and helping us learn what linting and things like that were… [laughter] So I think sharing it with them, and then them sharing it with their networks, it gave the project a life beyond just this creative coding community, which was really exciting for me.

Is it different to – in terms of getting people to collaborate on an open source project, or even just to use it – is it different in messaging to, say, a designer or an artist, versus a software developer that’s worked on a ton of other open source projects. Was extra worker messaging that you had to do there?

[12:19] Yeah, totally. Oh, there’s so many things I could say on this topic. I guess the first thing I’ll say - and it’s not specifically about artist and designer versus anyone else (but maybe it is a little bit) which is that feeling I had when I was like “Oh, I’m going to have to elbow my way into this space” or “I have to prove myself”, and just feeling like that’s not my nature, to push my way into a space or to shout out and try to get attention just to be a part of something… So I think being given an in like I was, I felt like I wanted to give that in to other people; I wanna create a space where people feel as welcome and supported as I did, being someone that barely knew JavaScript and doing my first project… To be a collaborator, so that you don’t have to elbow your way in, you don’t have to prove yourself, you don’t have to even necessarily know anything, you just have to be interested and willing to learn. And so.

That was from the get-go one of the really, really important parts for me… And that question of like “What would processing look like today?”, it’s like “Oh, of course it would be made with HTML and JavaScript and CSS”, but also I think there’s like a much better awareness of our need for diversity and inclusive spaces, so that needs to be like a core idea that is part of this project. It’s not like, “Oh, we made this code library and now how do we sprinkle some diversity in here? Get some women in the room, or something…” I saw so many projects try to do that and just struggle, and I thought “What if from the beginning every decision we make is based on supporting that idea?

That’s where it’s coming from, and then in terms of the messaging, it’s like having a really clear community statement and code of conduct, having a lot of documentation for users of the software, but also trying to do that for the development side, trying to set a tone in the GitHub issue threads where people feel okay to not know something or to ask a question, or communicate and not feel like it’s a hostile environment.

And then also making explicit decision with the code… There were times where we’ve actually traded off performance to some extent - I don’t wanna say this and make people too mad - so that the code could be a little bit more readable. So instead of doing like jiu-jitsu magic behind the scenes in place, we were like “Let’s not do that, so that if some new contributor is coming to the project, they won’t be just totally lost.” So all of that goes into messaging…

My hope is that that makes it welcome for someone that might not have contributed to an open source project before, or maybe it’s an artist or designer that would never even consider themselves a software developer, let alone an open source contributor.

Another thing that’s really special about this project is that there’s a lot of students that are contributors. Being a teacher here at UCLA (and previously I was at NYU), just involving a lot of students in that process, and having meetups where people can come and I would show them how to make a pull request, and try to find issues for them to work on… It’s this kind of nice thing where a lot of them will be involved for the couple years they’re in school, and then some of them will stay and some of them will go, but it’s sort of a first experience in open source that they have.

[16:05] And these students, a lot of them are learning to code for the first time. It’s like I teach them coding in our intro interactivity class, and then at the end of the class I’m like “Hey, if you wanna be a part of this and actually make this tool we’ve been using, you can come to the meeting on Friday”, and a lot of them do. So it’s like a really different kind of audience than maybe typical, or other open source projects have.

That’s so cool! I wonder if there are other – I mean, because you also teach and understand the academia side a little bit, are there other examples of projects that are teaching open source in school and having these hands-on opportunities? Because that seems like such a great way to up-level people into open source.

Yeah, I’m not sure… I mean, I know that there are some courses I’ve seen that are more like intro to open source, where they actually focus on that. And I know there are a lot of open source tools that are being used, in the arts at least… It was like Arduino, which is dealing with microcontrollers and processing in Scratch… And all of those are fairly friendly to contribute to, but I don’t know specifically if that’s emphasized.

Maybe the thing that is closest in spirit is something like Google Summer of Code, and it kind of is a really similar energy happening in the Summer, where it’s like, you’ve got a bunch of students, and the idea is not really to pull a ton of contributions out of them - although sometimes that happens - it’s really to give them an onboarding experience where they feel mentored and supported and able to participate. So I think a lot of things about that program are similar to what I do with the p5.js meetups.

Was there a point where you kind of recognized or you could see yourself moving from launching the project, and initially promoting and pushing the project, to more of like maintaining the project?

Well, I’ve strategically stayed under 1.0 just so at any moment I can change everything… [laughter]

Take it from me, that doesn’t work that way… [laughter]

Well, I saw someone post on Twitter “This project seems good, but I’m gonna wait until it gets to 1.0 to use it”, and I was like “Alright, see you there!” [laughter] But yeah, let’s see a moment… I think this project, since it’s so involved with schools, I kind of see a change from semester to semester. The first time I actually used it in a class it was probably totally irresponsible of me, but it was like at RISD in fall of 2013, so we’d been developing it for like three months, and we were just like “Hey, here’s a thing you’re gonna have to use!” It was very hacky at the time. Then I think kind of rolling it out, then by spring 2014 I was teaching at NYU ITP a little bit, and it became something more…

Maybe by the fall of 2015 it felt like a point where I wasn’t running around, trying to stop up holes and put out fires as students were using it. It felt stable enough that it was like a thing, and no longer like a test, whether we should use this tool or not. So I don’t know if that was the perception outside of it… I guess that was like a year, a year and a half after we started working on it.

[20:10] I don’t know, I don’t feel like there was a moment, I guess. It feels like it’s been this continuous thing where like – I think that it’s the user base is still growing; in each semester I feel like there’s more teachers getting in contact… It’s not just in schools, but more people posting things they’ve made with it. The maintenance has been kind of constant. Maybe it feels like there’s less huge holes now, but I still see all the holes all the time, so it’s hard to say.

That’s sort of like your role though, as the originator/maintainer of this project, to always see all the problems.

Yeah, I guess so. And then to make new ones. We’re like, “Oh, let’s make a web editor. Let’s make a desktop editor.” [laughter]

Exactly. I think one of the big shifts that I’ve seen in project after project is there’s this point where you’re just out there trying to get people to use it, trying to drive contributors to it, and then eventually you’re not looking for problems anymore, you’re just letting problems come to you. There’s enough pull requests and things to deal with that you hear about problems when they happen and you don’t necessarily have to go looking for them, right?

Yeah, definitely.

So p5 has a lot of contributors… How did you grow such a big contributor base, other than forcing all of your students to contribute, like you were talking about earlier? [laughter]

Fail them if they don’t… [laughs] Let’s see, how did I grow it…? I think just trying to make it really easy to make a pull request and to find something to work on. I guess one reason it’s easy is there was a huge emphasis on documentation for users of the tool. A lot of people if they’re looking for their first thing to do, I can say like “Oh, well find any page that doesn’t have an example on it, or a sufficient example, or any piece of documentation that feels vague, and I’m sure you’ve encountered one, because you were just working with this tool.” Just make a change like that.

Since all the documentation is in line in the source code - that was really important to us; I won’t accept a pull request unless the documentation is there, and if you’re editing code, it’s really easy to edit the documentation at the same time. But because it’s in the code, it’s cool because it really feels like you are actually doing something, you’re contributing to the source code. It doesn’t feel like you’re contributing to some documentation repo, or a document or something.

[24:09] And you have to kind of go through the steps to build everything and put the library together, so it’s like a really good way to learn all the steps of the process of creating a pull request, and building a library and submitting everything, and to see results immediately. I have an unlimited number of those kinds of things that are pretty doable for anyone that has some vague familiarity with code.

Having that, and then having other issues, just trying to – I do a really bad job of this – but I try to regularly tag things that are kind of smaller issues, and also log things that are small issues; rather than just fixing them myself when I notice them, just like logging and seeing if someone else wants to take it.

It’s a lot in the documentation - there’s this cool video that Luisa Pereira made, that was like “Inside p5”, that’s like this hand-drawn animation where she’s basically saying “If you’re a programmer and you come to the repo, all the source files - it’s not anything very complex. You can kind of go through and figure everything out.” But if you’re not an experienced software developer/open source contributor, it totally feels confusing; what is grunt? What is JSHint? What’s a gitignore? So she made a really nice two-part video that walks you through what each piece is and what each tool does, that you can kind of watch as a first step.

So having a lot of stuff like that, and then one moment where there were a lot of contributors that I was really excited about was we had this conference, and I’d like to do another one, we’re just looking for support… It was at Carnegie Mellon University in the summer of 2015, I think. It was this thing where Golan Levin, who runs the STUDIO for Creative Inquiry there got some funding from the NEA to host a conference. So he was talking to me like “Oh, it’s gonna be this dev sprint. Pick your five best programmers. You can all come here for a week and get so much done.” And somewhere along the line I was like, “Okay, but what if we invite a few more people?” It kind of kept growing, and I was like “I don’t think dev sprint is necessarily the right word…” It’s the right word for some people. Some people hear it, but for other people we’re gonna have to use a different name, and we called it “Contributors Conference.”

I put the word out on Twitter and social media - “Anyone that’s interested in coming, you can apply. You don’t have to have a lot of experience, or any experience. Just explain why you wanna come and what you think you could contribute.” It kept growing, and we kept being like, “Oh, but we should bring this person too, and this person seems really cool, and this person’s got interesting experience from Python…” We ended up with like 30 people there, when we were aiming for maybe like eight total. So it went from being a very nice, cushy week, to everyone kind of sharing rooms and having these pretty inexpensive meals, just so we could – because we didn’t have a lot of money.

So it was like a week before that, and then I was like “Oh yeah, I’ve been saying this thing - anyone that wants to contribute, can, and should be able to. Now they’re all coming, but I don’t know if that’s true… [laughs] How is this gonna work?” Because a lot of people were really new to the project, or hadn’t been involved in open source. I was like “What’s gonna happen? Am I gonna be running around to 30 people, trying to help them one by one? This could be a nightmare.”

[27:57] They just showed up, and I was sort of terrified, but I was like “Okay, let’s break into teams. Here’s some of the stuff we wanna do…” I did like an initial intro, making a pull request and things like that, and it was just sort of amazing… I saw one person had learned how to make a pull request and she was teaching it to her neighbor one hour later.

We had a lot of rules, like “You can wear headphones, but you have to be willing to stop and answer a question at any moment, from anyone”, which is not really a sustainable way to work generally, but we said “For this week, let’s try and work this way, where you just know that you could be interrupted, so don’t get too crazy deep into some thing in your head.”

It was cool. It was half women, over half the people there it was their first time contributing to open source, their first time even using GitHub or making a pull request… And yeah, it just kind of worked. People found a place that they could each kind of contribute something, and we had really different roles; we put equal emphasis on people that were making a community video, versus people that were working on the WebGL section of the library, and kind of gave those equal time and equal weight.

So events like that, where people can come and really get in immediately… And then a lot of them continued to keep contributing after that.

So cool! I’m marveling just because you’re playing this up as like this is your first project, and you kind of just “tried this thing” and “it just sort of happened”, and you’re sort of just like following all these amazing best practices, or whatever you wanna call them… And stuff just kind of seems to work for you. Does that come from – we had another guest we talked to who was saying because he wasn’t familiar with the project at all, but became a maintainer of it, he really emphasized things like documentation, because it kind of came from his own experience. Where did all these great ideas come from? Was it just like intuition from your own experience that you were saying, of wanting to give everyone else the same opportunities that you did…? I guess maybe this is more of a comment, it’s really awesome to see that you did all these things that I think so many other projects would have benefitted from.

No, I think it’s not just a comment, it’s a question that has an answer, which is – there’s a few things. One of them is that I was just so lucky to be working with and surrounded by people that were super good advisors and mentors and role models. One of the reasons that I was interested in getting into open source was – it was a guy, you know, as one does… So my partner was involved in open frameworks; he was actually the community manager. So I heard, before I was even working on Processing and p5 and when I was starting out, I heard a lot of things that he was thinking about. They had that similar struggle; they had built this project for a few years and then realized “Oh, this is a very homogenous group of people developing. How do we change that?” It’s a struggle, and he was saying, “We’ve got this mailing list, and it’s this group of people, so anyone else feels like an outsider.” He gave me so much advice, like what’s the difference between a mailing list anyone can join, versus a mailing list that you have to request an invite to. That’s already adding a barrier. Like, where are these barriers and how do you take them down? Or what is a mailing list versus just a broadcast channel where anyone could subscribe, and doesn’t have to necessarily identify themselves as in or out at any moment?

[32:11] So getting a ton of advice from him, and then… You know, Ben and Casey and Dan Shiffman with Processing, they’ve been building this audience and this community since 2001, that is like a really supportive, nice community of people. So we already had that on our side. And similarly, Bocoup has a lot of experience doing really well-run open source projects, so they offered a ton of advice.

It was just all, from every angle, everyone was helping me think through this, and supporting it, too. I didn’t get a lot of pushback; even when I was doing things that felt uncomfortable for people, everyone was willing to sit with that, and I think that was… Something I think about a lot now that I’m running this project is to incorporate the view of someone that is different than you; it can’t be me just trying to think “What does that person need? What do they wanna say?” You have to actually pass the mic to them, and pass the leader cap to them, and let them do it, even when you’re not sure about the decisions that they’re making necessarily, and trust. I think they did a lot of that, which was really helpful.

Part of that, kind of passing the mic to someone that has a different experience, I think when they passed it to me I was maybe being a woman, or maybe just being a really kind of shy and socially anxious person… I was mentioning earlier, I’m just generally sensitive to “Oh, am I really invited here? Should I leave? People are thinking I should go now? Should I…?” [laughter] So just having that general anxiety in myself, and like “How do I make this a place for–”, maybe I’m an extreme case, but other people also don’t worry about that… That even when they make a mistake or they’re not sure what to do, they still feel comfortable kind of sitting here. So I guess paying attention to that. But it’s not at all like I get it right all the time. A lot of times I realize I’ve screwed up afterwards, and I think that’s part of it - messing up, and then not being like “Oh god, I’m never gonna try that again”, but instead just being like “Okay, how do we do this better next time?” Maybe I offended someone, or maybe I excluded someone, but is there any chance they’d be willing to talk with me and show me a better way? And if not them, is there someone else that I could talk with to understand this better and figure out what to do next time?

Can we talk about that a little bit? Because I think on this show we often talk about all the really great examples of getting new contributors and things like that… What are some things that you’ve tried that didn’t work out at all?

I think at first I would feel really excited with someone new if they seemed interested or they sort of understood what to do, or seemed to be picking it up really quickly… And if they seemed excited to get in deeper, I would just open the door and be like, “Yeah, down that dark hallway! Go for it!” and I think that tended to overwhelm… I wasn’t very conscious of – just because someone’s like “Oh yeah, I’m excited about this” doesn’t mean I have to push them in as deep as they might seem like they wanna go at first.

[35:57] Especially dealing with students, sometimes it was a really different power dynamic that I have to be conscious of. Some students, if you’re the teacher, they really feel like they want to do the thing the teacher wants them to do. At first, I wasn’t necessarily aware of that; I was also new to teaching, so I would just think “Oh, we’re both excited about this project! We’re gonna jump in!” and then later realizing that I need to find a way to make it much easier to step back, or do it piece by piece and really make sure it’s their decision to go into each space… And also to offer people defined ways to be involved, so that it doesn’t feel like this – and I think that’s with any open source project, you kind of worry “What am I getting into? Am I gonna be able to get out?” I think some people have that feeling. So being like “Look, this is the task, and if you wanna figure out another task after that, we can do that.” I messed that up a lot in the beginning, I think.

And then… I don’t know, there’s always these parts where it sounds so easy, like “Oh, we’ll set this tone on GitHub issues” or “We’ll have this community statement”, or “We’ll support these things”, but it’s not that easy. And if it was that easy, everyone would just do it. So there are times where someone will be extremely aggressive on a GitHub thread, and it doesn’t happen really often with this project, but sometimes it does… Or not even aggressive, but they’ll use some language that could be really off-putting, and I’ll usually try to address it first, just on that thread. But there have been a few times where I had to email the person and talk with them offline… Sometimes people have gotten upset about that, and they felt like I was tone-policing, or not being welcoming to them, that I’m privileging some other group that I’m trying to be welcoming to… So with those ones I can’t be like “Oh, and then I figured out the solution, it was X!” It was just acknowledging that you can’t make everyone happy all the time. Or even if we say “We are in support of a diverse audience…”, who gets to speak, or who gets to share, and how much, and what? And not that I’m trying to set rules about those things, but that at some point you have to be like “What is the thing that we’re putting on the homepage?” or “What is the language that we’re using here?” and I think I’ve gotten that wrong in the past… And just trying to ask “How do we do this better in the future?” I guess I was really vague, I’m sorry.

Not at all.

I don’t know, there’s a specific instance that I’m thinking of really clearly, but I haven’t found a really good way to talk about it yet, so I don’t really want to go really deep into it, but… It’s along those lines.

It’s fine, I think anybody listening who’s had to maintain a project knows exactly what you’re talking about. They’ve had an issue like that. I think that a lot of things about conduct, or even just what is the mission or scope of the project, or what kind of community do we want - do we want a nice and accepting community? All of those are about drawing lines and drawing boundaries, and there’s always gonna be people that test where those lines are, and it’s really difficult to deal with.

And in both of the examples you were giving, I feel like I’m hearing this tension between wanting to empower people, but then also sometimes there just need to be these norms that get set, or sometimes there needs to be more handholding, and it’s not always obvious to know when you don’t have context on that individual person… Because you have a big project, where you have random people coming in - you don’t know them well enough always to say “Oh, I know what you’re capable of or not” or “I know how much I need to talk about your language or not” or whatever, and it sounds like a really big job.

[40:14] Yeah. Actually, I thought of one more example that was a little bit more specific, which was that there was a post on our web editor, which was issues that were not even public yet, that we were only testing internally, basically, and it was from someone who didn’t know, and the tone of it was kind of like “This doesn’t work and I’m really upset.” I just wrote back kind of like, “I’m sorry you’re upset, but this isn’t really public yet, so things are still really in flux. Also, please be careful with your tone; we’re all working really hard with this. If you’re just saying how mad you are, then it’s kind of disheartening for us.”

Then I find out later that it was a very young student who didn’t totally understand – had been showing this editor in a class, that I didn’t know about… It wasn’t like they had just stumbled upon it, and they didn’t understand much about GitHub or about the project in general, but they were kind of excited about this idea of GitHub issues, and that they could kind of communicate with the creators. You know, it’s like a young person just explaining “I’m frustrated!”, and I was thinking of it like an adult, like “Oh, how could they not think for a second about how this might come off.” And as soon as I understood the context, it was totally different; the message was like, “Oh, okay, I can identify with that, or understand it completely.”

And then also my response - I had been responding as if it were an adult that could understand what I’m saying in this way, whereas a child just heard like “Oh, you weren’t supposed to be using this tool, and also, you didn’t say it right.” I felt really bad, and I felt like I had really screwed it up, but it also made me think… The thing that I’ve been saying I had forgotten, which is like you can’t make assumptions about people that are participating in this project, so if I could go into each message and not have some image of them in my mind, I think that was the takeaway for me… Just imagine it could be anyone, and imagine the best-case scenario, where whether they’re saying something that feels aggressive or not, imagine them as like a good person that is having some difficulty with this tool, and put myself in their shoes and then think about a better way to respond, even if I would still kind of communicate the same thing.

You’re making me like totally sad face right now… [laughter] It’s like, that’s such a touching story! [laughter] It’s just like – it’s such a hard balance between… Like, from a maintainer’s perspective, they need to also protect themselves and set boundaries (emotionally protect themselves), and be able to say “This doesn’t make me feel good when you say something like that”, or whatever. They have total right to do that. And on the other hand, especially now, there’s so many new people flooding projects, flooding GitHub, who just completely might not understand… And like, how do you make both sides happy? It’s so hard.

Yeah, it’s funny, because there’s a thread on the GitHub Maintainers repo that was about mobile use, and I was thinking, the thing that I do the most with mobiles, I respond and then I wanna edit it, because I’m like “Oh, that was too snappy” or “I didn’t like the way I said that.” And it’s hard to edit on the mobile version. But then someone on the thread was like “I just try not to do that on my phone. It just doesn’t seem like a good situation”, and I was like “Oh, that’s so true.” If my issue is that I’m responding and then not happy with the way I phrased things because I was going to fast, I should just not be responding to GitHub issues on my phone, as I’m riding the subway. I should just compartmentalize that a little more.

[44:13] I think a lot of the responses that I’m less happy with come out of just trying to do too much, or to respond too quickly, or not being in a calm enough place that I can just be totally open and thinking clearly, instead of like “Oh, that hurt my feelings!”

So your work straddles both software and design worlds… You officially called yourself both an artist and a programmer; how do you navigate those different cultures? Where have there been really good crossover learnings, and where has it been hard?

Well, I guess the artwork that I do – they’re really not separate things. I’m a lot of times making software or making systems as the artwork or as part of an artwork. A lot of what I do is making software that facilitates performances that are kind of dealing with being a person, or general social interaction I guess is kind of the focus of my artwork. So when I try to draw a through-line from programming or from working on p5.js specifically, that’s where it is for me. p5.js is not actually the tool that I use most often to make my artwork, in the way that some other people make a tool and then are making drawings, for example, using that tool.

Since I’m doing things that are more like software systems or apps… I use JavaScript a lot, I don’t use p5.js specifically that much. So the through-line between that project and my art practice is really the social aspect of it, and I think that’s why I’ve put such a big focus on it, because it’s the thing that’s really my main interest.

But then I think having a background in software and in technology gives me I think a different way of thinking with my artwork, so I’m understanding things on different levels - from a systems perspective, or from the perspective of how the technology might actually work, or what I might actually build, but then also coming back out and thinking like “Oh, but I don’t actually have to build a production-ready app. How do I create the art experience?” Like, take off the software developer hat and put on the artist hat and say like “What is the thing that I could make that’s kind of in the middle of that, and creates the experience that I want to?” So rather than flipping between the two, I find myself really in the space that’s sort of in the middle.

A lot of the artwork that I do is kind of critical of or addressing new technology, and I feel like I’m able to do that in a more nuanced way, because I really understand the technology the way it’s built… A lot of my friends are involved in making some of these things.

And then I think on the software side, the art side of things really helps me think about experience, and about the kind of social aspects of things… Putting less emphasis on “What does it do?” and “How fast?” or something, and more on “What is the experience of that like?”, from an original conception to after the fact when you’ve experienced it, or you’ve used the tool, how do you feel?

That’s deep. [laughter]

Yeah, I’m gonna have to sit here and meditate on that… [laughter]

Why do you think there aren’t more people with your skill sets and backgrounds in open source? I’m thinking people just sort of with that design esthetic or understanding, or that are really thinking about the user experience kind of things… Why aren’t more of those people involved in open source?

[49:53] I think there’s not enough emphasis on them yet. There’s still a lot of feeling of like the technical or the power of it is the thing that really holds up a project, and all the graphic design or the documentation or the community or whatever - that’s secondary. I think if we flip that a little bit and think that actually, documentation is really, really important, and then also the community is really important… Yes, there are always gonna be the users that go to the tool that just does the thing that they want the fastest or the best, but there are also a lot of users that will go to the community that they feel they can relate to.

Sometimes when I’m talking to my students and they say “There’s so many JavaScript libraries to do touch interaction. How do I decide which one to use?”, I tell them some things about various technical considerations, but I also say “Just look at the website, get a feel for it, and think, does this feel like a thing I wanna engage with?” Does it feel really flashy, or does it feel really technical, or does it feel friendly or accessible to you in a way that you think you could imagine yourself going here and looking up documentation and kind of teaching yourself how to use it?

I think those aspects are super important, but under-valued. It’s been really freeing with this project to say we’re not trying to make the fastest JavaScript graphics library, or the most efficient, but we’re trying to make the one that really gives people an in to a broad range of techniques or functionality for making things on the web. Getting over that “I still always wish that it were faster and it did more and it worked better”, but to not hold that as like the only goal has been really useful.

That’s really insightful, actually. I don’t think that we spend enough time talking about choosing which culture you respond to. There’s a lot of focus in the technical community on “Does this thing have the right features?” or “Is this thing some version of correct?” But I think we forget that these communities are where we’re gonna have to live for a while, and finding cultures that you respond to can be even more important.

I’ve seen a couple projects grow and literally convince people to take on projects and to do stuff in those libraries because they responded so well to the culture. People that had no interest in doing robots I think got into Johnny-Five because of the culture.

Yeah. I think that it’s gonna have to change, because it’s just becoming so much easier to learn how to code, it’s becoming – not that it’s easy, but there’s so many more resources, and it’s becoming so much more present that I think assuming your user base is very technically minded, technically sophisticated people just doesn’t make sense in terms of like the reality of people out there on the web that are making things with code.

So you’re employed to teach, not to just work on this open source library, but it sounds like a part of your role there is sort of working on this library, as well… When you think about how to continue to sustain this library with such a growing user base and contributor base, how do you think about how to do that?

[53:45] [laughs] Well, I don’t have any great ideas. We’ve tried some things. We had an idea - I don’t know if this was a failure or not… So there’s this Processing Foundation that Ben, Casey, Dan and I direct, that is sort of an umbrella for Processing and p5.js, and I think one problem with it being called the Processing Foundation is that it sounds like the Mozilla Foundation, or something, and people are like “Oh, can you fund our projects?” and we’re like “No, no, no, we made it so that you could give us money!” [laughter] So it’s not like a big organization or anything, it’s really just a structure for us to kind of identify what we’re doing and try to raise some money to make it more sustainable.

Recently, we’ve rolled out this membership idea, where you can make an annual donation, and you don’t get any extra anything… You get your name on a website, but it’s a way of trying to frame this idea of – I guess we’re trying to put out this idea of an ongoing support open source project that you use.

We had a really great response from – you can do this as an individual, as a studio, because a lot of design studios use us, or as an educational institution. And I’m not trying to sound pitchy here, I’m not trying to convince anyone to become a member, I’m just trying to explain what we did. So the idea behind it really came from thinking “Oh, there’s so many schools that teach with these tools, and they pay so much money for proprietary licenses like Adobe. Maybe they would give us some small donation, considering they teach with this free software we make.” And we didn’t get a lot of response, so we felt kind of like “That didn’t work.” [laughs]

We had a lot of hope that maybe we could put this new idea out here that “Yes, you’re using open source…”– less so to individuals, but especially to larger institutions that would pay thousands of dollars to a company, just a few hundred dollars to help support these tools that you teach with. So I don’t know, that was an idea; that didn’t quite work, so now we are trying to think of other ideas.

I think for me personally it’s been – and I guess one difficult thing is… It’s much easier to get funding and also contributors around something that’s new and much harder to do at first, like maintaining something. So probably like, “Oh, I’m gonna make this new library? I could probably get some grants to do that.” And since it already exists, the sustaining grants are much fewer and harder to get, and I think you’ve talked about that on your show.

And trying to think of sort of new things, but actually kind of reframing what we’re already doing as a way to try and get support… But really for me, I think the place that I’ve gone to in terms of sustainability is just lowering my own desires or expectations for it. That’s been really hard to do, because I’m the sort of person that – like, I really want every project I do to be like 500%, as good as I can possibly make it. If I’m making an art project, or a piece of software, I want it to be like “I feel 100% happy with the code and with every detail of it.” And I realized, this project is not that. Not that I’m not trying, but it’s such a large thing, and the web is always changing, so it’s not actually possible for it to be “Everything is working and everything is up to the standard that I would like it to be at every moment”, and that’s okay. I should just go to sleep and do some more the next day, and set limits - not have all the GitHub emails come straight to my inbox, but go to a folder and look at them at times when I’m working on this… And just to be more realistic about what is possible, and making some hard decisions, like “Maybe we won’t add this set of features. Even though it’d be really cool, just because there’s not the energy to sustain that”, or maybe it needs to be like an add-on library, so it doesn’t feel part of the core library that needs to be maintained if it goes out of date.

[58:28] Have you thought about bringing on other maintainers?

Yeah. I’ve made some attempts in the past to try and more formally bring people on in that role, and I think it’s difficult. I don’t know… Actually, maybe it’s something I need to explore more. Maybe it’s more the sort of thing that I feel like it didn’t work the first couple times, and then I gave up. So I’ve tended towards things where it’s more fluid, that people can be as involved as they want, and then I try to support that and engage them as much as they seem interested, and then when they leave the project, to let that be natural, and not kind of frame it like “Oh, you’re a maintainer and now you’re not.”

Maybe that is something that needs more thought. It is something I’m thinking about… We’re just about to launch a Spanish version of all the documentation and the website, and I realized with that – it sends the wrong message to have really incomplete and messed up documentation in one language (in Spanish) and then really complete in English, or something. So I said “If we’re gonna launch this, we need someone that will commit for one – for any language, to commit for one year to being the maintainer of that.” Then at the end of that year, you can keep going or you can find someone else to take your place… Or we will kind of change the status of the documentation. So it will still be there, but it won’t be linked as a language button from the homepage. So people can still access it, but it doesn’t give the idea that we’re just neglecting it. And then at any point when someone is ready to sign on to that role, then we’ll put the link back up and have them maintain it.

So trying to think of that – for me, that model makes sense in terms of translation, and maybe there’s things from that that could come in in terms of maintaining the codebase in general.

I guess similarly I’m wondering - and we didn’t touch on this earlier, but something I hear from other maintainers is getting new contributors in the door - there might be these established practices for doing that, but then getting them to that next step can be harder, or getting them to come back and contribute regularly can be harder. Has that been a challenge in your experience, to get people beyond those first couple of commits? And especially I guess with the students, kind of like cycle through?

Yeah, I think I have a little bit less of that problem, because I think a lot of people, because this is really their first time doing it, that if they go through all the trouble to learn how to do that process, they feel like that is a significant thing for them, so they feel sort of like “Oh, I wanna do that again”, even if it’s other small pull request, or something like that.

And so what happens – the pattern more typically is like, you know, over this semester they’re very active, and then their thesis takes over, as it should. Or it fluctuates more, or they get a job and they have less time for it. Or maybe they have more time.

[01:01:50.24] So I think going from the first commit to – the big hurdles are like the first commit, and then maybe sustained over a longer period of time, beyond a specific, like Google Summer of Code period, or a semester, or something. But on the other hand, I don’t feel it’s – I would love for people to stay on the project beyond that, and a lot of them do, but I also wanna make it feel really clear that that’s not an expectation.

Then for non-students, it’s a lot more fluid. What I find more often is that people come in and are being really active, and really taking on the role of maintainer for a while - for a few months, for a year or something, and then kind of step away. So maybe what I really need to do is recognize that type of contribution more clearly.

So when do you decide, or I should say how do you decide when somebody is ready to be given commit access? What have they done in the project when you wanna give them that extra little bump up?

I try to do it really immediately, and sometimes if I don’t do that, it’s just like it being like one more thing that I forget to do, among the mix of things… I’m like, “Oh crap, who else do I need to add in here?” But yeah, the general policy is that if you’ve made a commit, then you should have push access to the project. And people still submit pull requests, and generally I will review and merge, or say to someone else “If you think this is good, merge it.” But then I guess the place where it differs is if there’s a specific area… So there’s one person that’s kind of maintaining the WebGL stuff, and so that person has full push access; I mean, they have access but they kind of make the decision, and same thing for typography - they can just go ahead and make the changes without any expectation that I need to review things. So that’s the policy - whether I remember to keep adding people as they make commits is a different question.

This has been great… Are there any final things that you wanna say, or anything that we didn’t cover that you find important or interesting, or things that you’ve learned?

The thing that really stands out to me is when people have been extremely generous in some moment, that made me change the way that I thought about those projects, about the open source community, about the way I wanted to interact with other people. One example was - really early on, Evelyn and I went to Bocoup, and they had offered to kind of review our code and give us some suggestions. One engineer there, Ben Alman, sat down with us and looked at it all over, looked at what we had, and then gave us some recommendations. The first thing he said was like “So I would recommend not putting your source code all in one long file…” [laughter] He was like “You might wanna set some standards… Like, are you using two equal signs, three equal signs, are you having spaces, or tabs?”, things like that. To me now they seem like the most basic, obvious things, but just being new to all this, we had no idea.

[01:05:54.28] In the moment, when he was making some suggestions like this, I did not get the feeling at all – I didn’t feel embarrassed. I didn’t feel embarrassed like I do now, thinking about it… [laughter] And I think to be able to do that is really special. Here are people that are such experts at this thing that we were really new to, and they met us and didn’t treat us like people that didn’t know what they were doing; they treated us as equals and just gave us their honest feedback and didn’t make us feel embarrassed about where we were at with the code.

That still really sticks in my mind, that what might feel really obvious to you after working on something for a while or learning something for a while is not at all obvious. Somebody’s just starting out, and why would it be? So can you give someone that feeling that even if they know less, and they are less experienced, that doesn’t mean they’re less good of a developer, less of a person, less of a contributor, or something. I think that really touched me, and there were moments like that where people really took the time to engage, give feedback, give advice…

I also think of Ben and Casey having made Processing, and I know they follow on the p5.js repo, and then every once in a while we’ll be debating something and Ben Fry will come in with a link back to this discussion that they had ten years ago about this thing, and how they already figured it out… [laughs] And they’re being like “I’m really cautious to post this here, because maybe you’ll come with a better answer, but I just felt there was so much discussion that I wanted to offer this context.” That kind of openness - even if you’ve done it before, maybe you don’t have all the answers, or maybe you do, but you’re still willing to let someone new try and make their own conclusions and mistakes… I think that takes a lot of thought and a lot of energy, and I’m so appreciative of those moments and gestures. I don’t know how I’d sum that up, but that’s the thing that I think is often underlooked, but so powerful and so useful.

That’s a great note to end it on actually, so… I wanna thank you for coming on, this has been amazing. Thank you.

Yeah, thank you guys.

Thanks, Lauren. This was awesome!