Jerod Santo: Okay, now I'm recording. Richard, tell me your full name.
Richard Littauer: My name is Richard Littauer.
Jerod Santo: And you're with Maintainer.io.
Richard Littauer: Maintainer.io is my main thing at the moment, yes.
Jerod Santo: But what I wanna talk about is theuserisdrunk.com...
Richard Littauer: Theuserisdrunk is a thing I did a few years ago where I launched a website where people could pay me money to get drunk and then look at their website from a UX perspective. Ridiculous, but it went viral, and that was it.
Jerod Santo: It went viral and then it dissipated and died?
Richard Littauer: It went viral, and then I had to raise the price to the point where people would stop buying it, because I couldn't drink that much. It's a non-sustainable business model.
Jerod Santo: So would you actually become intoxicated and then peruse websites for money?
Richard Littauer: Yes, and there's videos online...
Jerod Santo: Did the intoxication actually aid in your ability to suck at using the website?
Richard Littauer: It very much did. [laughter] It also taught me a lot about what UX is and how it works. It was a fun thing to do. I wrote a big retrospective on Medium about "Don't drink for money, because you swiftly hate drinking." I actually quit for like a year, because man... Man... Anyway.
Jerod Santo: It turns a hobby into a job really fast.
Richard Littauer: It does.
Jerod Santo: So tell me about this Maintainer thing you're doing.
Richard Littauer: I was a community manager de facto for IPFS around a year and a half, and then in March I decided to go out and do my own thing, which is Maintainer.io. Basically, what I do is community management as a service - all community organization, and help you figure out how to take random repos on GitHub and turn them into a real community, to facilitate community growth rather. I can't bring people on board, but I can make it easier for you to get people to code on your stuff.
Jerod Santo: So it seems a little bit odd, like bringing an outsider to help build a community, when it's like -- isn't the people who are there the community, like their challenge is there?
Richard Littauer: But a lot of times they don't have the information, they don't have the knowledge for how to build a community, they don't know how to set up contributing docs or codes of conduct, or readmes, or how to track different repos across an organization to make sure they're actively being maintained.
Jerod Santo: [00:04:04.10] Sure, so it's like a consulting situation.
Richard Littauer: It's like a consulting situation, yeah...
Jerod Santo: But you'll actually take the reins and get it going.
Richard Littauer: I get it going, and then I also -- for solo developers, if you have too many issues, I help you maintain your stuff. I'm not gonna do domain-specific PR reviews, but I can definitely figure out if your repository has the right level of documentation, if it's easy for people to become contributors and maintainers, and I can help with issue triage and out of office replies.
Jerod Santo: Cool. So you just kicked that off recently, right?
Richard Littauer: Around two and a half months ago.
Jerod Santo: Two and a half months ago. How's it going so far?
Richard Littauer: It's going great. I've had a lot of clients, I had a great time working with them, and I've just signed a contract for around a month with a big charity in the UK, and I have a much bigger client on the way hopefully... Things are just better than expectations.
Jerod Santo: Is this the kind of work that you really enjoy doing?
Richard Littauer: It is. I love technical stuff. I love getting deep into the code, but at the end of the day, what I enjoy doing is fixing spelling errors and making sure that it's easy for new developers to come on board... You know, sharing that sort of energy.
Jerod Santo: So you have a vested interest in seeing open source sustained, of course, because you're super invested completely into that.
Richard Littauer: Yeah.
Jerod Santo: We're here at this Sustain event today, late afternoon, so we've had most of the day... We're getting to the solutions section, but what are some highlights for you or takeaways you've had so far, conversations?
Richard Littauer: One of the great highlights was I had a meeting about what makes a good maintainer, and we sort of came away with the idea that it's actually just self-awareness and being able to say "I'm good here, I'm not good there." That was really good for me, because one of the things that's missing in code is human empathy and being able to really think about who you are, emotionally do you wanna get involved with this, and like the long emotional tail of code. So it's good to have people here talking about that and not just being "Yeah, code's just about the semicolons." It's more than that.
Jerod Santo: So turning to yourself now, self-awareness... As somebody who sells maintainer services, what do you excel at and what do you struggle at with regards to software projects?
Richard Littauer: I excel at having new eyes on the project and figuring out if it's good for new developers, and what it looks like if you wanna become a maintainer, how easy is that, how hard is that; I excel at figuring that out. The dev ex of open source code. I am not the best person to figure out if your implementation is spec-compliant.
Jerod Santo: Okay. So are there certain kinds of technical projects that excite you more than others, or do you not care?
Jerod Santo: Yeah. One of the things we're doing here, actually going on right now as we speak, is gathering examples of people who are doing it right... So as you go around and help other people do maintenance and build communities, what are some exemplars, in your opinion, of projects that you could turn to and say "Do it like these guys and you're gonna do well."
Richard Littauer: NPM does a lot of good stuff with their community. They're not perfect, in some ways... The CLI tools are really getting there hard, but their heart is in it, and you can see that, and I love that. Hoodie does it really well; they're all about community, they're all about how to do this. Node is getting there... I've been sitting in on some of the communications committee meetings and they're working really hard to figure that out. NodeTogether was great - that's with Ashley.
Yeah, there's a lot of great projects, a lot of bad ones, but I love it when you can see that people really care, and it's obvious.
Jerod Santo: The problem with Go's formatter is it gives tabs to your code, and we all know that people who use tabs make less money. [laughs]
Richard Littauer: [00:08:06.22] I don't mind which god you worship, you know...? It's alright...
Jerod Santo: It's objective now. People who use tabs make less money, so it's like the final say on the debate. No...
Richard Littauer: Let's put a DOD file in your repo to automatically convert them and move on...
Jerod Santo: There we go... Anything else about this event or about sustainability in general that you'd like to bring up as something you learned or know or would like to discuss more?
Richard Littauer: I would love to talk more about models for actually having people not burn themselves out at night. Like, how can we make it easier for the hobbyist open sourcer to do this and love their work for years. A lot of us are young guys - young women, as well; sorry, I keep using the word 'guys'... Young people, and we're starry-eyed and eager, and I've seen the other side of that as well, and that's hard. So what I really love about this conversation here is that we're talking about sustainability - not just financial models, but also long-term, for the best of the project, for the best of people staying safe...
Jerod Santo: One thing I noticed when I asked you for examples, you gave Node, Hoodie and NPM, and these are organizations...
Richard Littauer: Yup.
Jerod Santo: What about smaller scale? Like you said, a lot of us are hobbyists, we're individuals, maybe we're a team of two... First of all, are there any examples of people doing it well on the small...?
Richard Littauer: Yeah, I really like Sindre Sorhus' way of doing things. I love how they're using an AMA repo that has like hundreds and thousands of stars, where you can just ask them questions. I've met him, he's a really nice guy, and it shows in his code. It's idiosyncratic and lovely, and it's just like "This is what I do here."
He's not a small example, he's the most prolific coder on GitHub, but...
Jerod Santo: Yeah, small in terms of he has small projects, right?
Richard Littauer: Yeah, exactly.
Jerod Santo: Often times he's the only person who has commits on those projects.
Richard Littauer: On the other side of things, SubStack doesn't necessarily comment on everything, doesn't well document his stuff all the time, but you can see he's keeping the internet weird, and it's wonderful, it's just great to watch. I love his stuff.
I'm trying to think of any particular people who just no one would know about who I really like, and I'm failing. Nofel. Nofel has some really great stuff. He wrote a thing called Art Of Readme, which just is a really passionate plea to have better documentation. And he just writes these beautiful little modules that are really just empathetic, "Here's where I'm coming from, here's how you access my API", and I love it.
Jerod Santo: Very cool. Going back to Sindre Sorhus he often will hop into our ping repo -- so we have a repo on GitHub where you can just drop projects, drop links, and we'll pick them up and tweet them or we'll put them in our newsletter... And he'll often hop in there and drop things, and everytime I'm like "Sure, we'll link this up", and then I'm like... We always try to get him to come on the Changelog, and he's always like "Nah, I'm good." [laughs]
Richard Littauer: Yeah, good for him.
Jerod Santo: He just says no every time. I feel like he's a person who really knows who he is... Which is cool.
Richard Littauer: Yeah, he does. I don't know him that well; I had lunch with him once, that's about it... But he seems like a great guy. I have a soft spot in my hear for digital nomads, being one myself... Always on the road, always making new things. There's a guy here, Blake Embry, who's also like that. And then two of the people from Open Collective worked at Casey Rosengren's Hacker Paradise, which is this awesome --
Jerod Santo: We're big fans of Hacker Paradise; we've teamed up with them and sent a few people...
Richard Littauer: Oh, that's right, you did that! I've been at Hacker Paradise three times, I love it.
Jerod Santo: Really? That's awesome.
Richard Littauer: It's wonderful.
Jerod Santo: So yeah, we haven't mentioned -- you said you're a digital nomad... Name some of the places that you've worked from around the world, some of your favorites.
Richard Littauer: In the past two months I've worked from Reykjavík, Ireland, Edinburgh, Glasgow, the Highlands, London, Berlin, San Francisco and Brussels. [00:11:51.27] My favorite is Edinburgh, I went to uni there. That's my home. I did work on the bus from Reykjavík airport into Reykjavík itself; that was really fun. Watson, with whom I basically sort of run ArcticJS, which happens every two years in Svalbard, in the North of Norway.
Jerod Santo: I don't even know where that is...
Jerod Santo: Oh, nice. Very cool. So you have your own little map that you keep, with places you pushed from?
Richard Littauer: I have yet to actually make that map work, but knowing that I could makes me pretty happy.
Jerod Santo: Right, it makes you feel pretty good. [laughter] Cool. Well, thanks so much for sitting down and talking to me.
Richard Littauer: Thank you so much. This has been great. And thank you for being here, it's wonderful.
Jerod Santo: We love it, we're happy to.
Adam Stacoviak: Coming up, Jerod talks with Karthik Ram about the struggles he felt when trying to reproduce code in scientific research papers, and how that lead to rOpenSci, an organization which got started five years ago with the help of Twitter and a grant. We talk about the open source tools they've created for the data science community, how they got over four million dollars in funding, and we also cover their plans to support and scale their thriving open science tools. Stay tuned.
Jerod Santo: So Karthik Ram, here to talk about your open source project. Tell us about it. What's it called and what does it do?
Karthik Ram: My name is Karthik and I co-founded this project five years ago called rOpenSci. Back then, I was a regular scientist with a day job, trying to reproduce other people's code and failing.
Jerod Santo: When you say "reproduce" their code, what do you mean by that specifically?
Karthik Ram: So I would read a paper by somebody else, and they would say "Everything that we did is in this supplement", and I would run the code and nothing would work.
Jerod Santo: I see, so you were taking code from a research paper and trying to execute it.
Karthik Ram: Yeah.
Jerod Santo: Gotcha. And it's failing.
Karthik Ram: Nothing works...
Jerod Santo: [laughs] That sounds suboptimal.
Karthik Ram: Much of scientific research is suboptimal. And then we realized that people are trying to do very specific activities that we could package into modules that we can release... Say, if you're trying to do X, or Y, or munge this data or visualize this data, we have a library for it. So don't try to build this from scratch, we already have a module for it.
Jerod Santo: Okay. And that was five years ago.
Karthik Ram: Five years ago, and fast-forward to now, we have almost four million dollars in funding...
Jerod Santo: Wow.
Karthik Ram: ...we have a staff of about seven people, we maintain 150 modules, we train people and we build community.
Jerod Santo: [00:15:57.04] How did you get that done? In a nutshell... [laughs]
Karthik Ram: Magic...
Jerod Santo: Yeah, exactly.
Karthik Ram: Just bootstrapping this thing one thing at a time.
Jerod Santo: Okay. What do you think were the keys. So if you had to go back and say "Well, these three things are the reasons why we've gotten to this point." Three is an arbitrary number, but...
Karthik Ram: The things that worked out for us was we built really tight software...
Jerod Santo: What do you mean by tight? Simple?
Karthik Ram: Simple, robust, well-maintained...
Jerod Santo: Good. [laughs]
Karthik Ram: ...fixing every bug that came along the way, and then people started trusting us. Then soon we started getting more and more buy-in from other people.
Jerod Santo: How did you get other people to use it initially?
Karthik Ram: Twitter. So we were tweeting things throughout -- the whole project came together through Twitter.
Jerod Santo: That's kind of amazing, isn't it?
Karthik Ram: I had a day job, two other people had a day job; we were tweeting at each other, and then one day we said "What's your email?" We got each other's email, came up with a name for the project and said "Would you like to apply for funding?" We were awarded a grant, got $200,000, and then we became an entity.
Jerod Santo: Just like that?
Karthik Ram: Yeah.
Jerod Santo: Wow. So there's apparently a huge need for what you're offering, to just get a $200,000 grant.
Karthik Ram: Yeah, that was just the start, and then we realized things that we're doing, developing best practices, writing reusable modules - people are just dying for this stuff.
Jerod Santo: Wow. So you found a huge gaping hole in the scientific community.
Karthik Ram: We did, and it still exists in a big way. So fast-forward five years, we maintain less than 20% of the software that we ship; other people contribute to us. Other scientists who have a burning need for something write software and contribute that to our suite.
Jerod Santo: In like a plugin style, or what do you mean by "contribute to your suite"?
Karthik Ram: They contribute a whole module to us, but we have a rigorous process by which we evaluate software. So we make sure everything's okay, they're unit testing, there's good documentation, they follow best practices... So we put them through the whole wringer, and by the time it comes out the other end it's very good software. Then they go back and they realize, "Oh, I learned a whole bunch of stuff that's new to me." So collectively, we are elevating the quality of software in scientific research.
Jerod Santo: You're making it sound very easy.
Karthik Ram: It's not easy... [laughter] We've been riding a struggle bus for this whole time...
Jerod Santo: Riding a struggle bus... What does that mean? Everything's been hard?
Karthik Ram: Everything's been hard. Funding has been hard, getting community buy-in has been hard, but we're in a very good space right now.
Jerod Santo: Yeah. You're looking back at it, so it's easy to talk about looking back...
Karthik Ram: We've kind of become an authority in this space; we've built a voice in this space, and now people look to us for collaboration, and say "We wanna build this thing. We don't know where to start."
Jerod Santo: What have been specific struggles on the struggle bus that you faced throughout the five years?
Karthik Ram: Getting institutionals' buy-in for our work, getting people to trust that we build something that's really good. Funding has been a challenge, because we have full-time staff that we need to support, and in open source that's not an easy thing.
Jerod Santo: Right. You mentioned the $200,000 grant upfront... Were you always staffed that way? Or you said "Well, we have 200k, let's just quit our day jobs and do this right now", or did you slowly move into that?
Karthik Ram: I was at postdoc, doing actual research back then, and this was my distraction, doing open source. Josh Greenberg from the Sloan Foundation, who I got connected to through a bunch of people, believed in us and said "If you want to quit your day job and do this full-time, I will back you." And sure enough, everything aligned, and then I quit my day job, and then in a year I made my collaborator quit his day job, and now we've made seven people quit their day jobs.
Jerod Santo: [00:20:17.24] Wow. What are some challenges you face today? Five years in, you've got a lot done, but what are some challenges now that face you?
Karthik Ram: The challenges we face right now is scaling. Every new person we want to add to our team is one other FTE that we need to support going forward. Our current budget is about a million dollars a year, and to grow that beyond one million a year is very hard, because we write software for public good, and it's very hard to do that if you don't actually generate revenue.
Jerod Santo: So you're always going back to the well of foundations that you've been relying upon...
Karthik Ram: Yeah, but we've also realized that software that we build is making a huge impact on science across the board, so we are trying to, in the future, reach out to people that fund primary research, like the National Science Foundation, the national institutes of health, and tell them that "We support 27 projects that you fund, so perhaps you should just fund us directly."
Jerod Santo: Yeah... Is that like your new idea, or have you made those efforts?
Karthik Ram: No, that's our new idea.
Jerod Santo: Oh, it's your new idea; you haven't tried it yet.
Karthik Ram: No, not yet.
Jerod Santo: It sounds like that's a good idea.
Karthik Ram: Right?
Jerod Santo: [laughs] Yeah, exactly.
Karthik Ram: We just want to reach out to new funders and tell them "We are maintaining key infrastructure that supports people that you are trying to support."
Jerod Santo: Other struggles? So you've got the funding side... Is the project at a size now where you have -- is its needs beyond the seven people, or you feel pretty well staffed?
Karthik Ram: We're in a good space right now. Some other struggles are kind of trivial at this point. We would like to get -- I mean, our goal is to find the best talent we can find, no matter where they are, who they are and what they do, but politics and international law makes it very difficult to just randomly hire a contractor in Switzerland or Peru, but we're trying to make it work, and we are trying to find organizations that can help us make this easier.
Jerod Santo: So if other people were to follow in your footsteps, I guess the first step would be find a huge need.
Karthik Ram: Yeah, which is not hard, because there is a lot of low-hanging fruit that is waiting to be solved.
Jerod Santo: Yeah... Specifically in research and science?
Karthik Ram: No, just in open source in general.
Jerod Santo: Everywhere.
Karthik Ram: Yeah. Good open source software is kind of hard to come by, and then good open source software that has a potential to be maintained is even harder to find. So the fact that we've been around for five years and we have a solid plan to keep this sustained makes a huge difference.
Jerod Santo: It sounds like a lot of people could probably learn from your experience, from your model. Are you doing any writing or documenting of success and failures throughout the time? Like a pathway for people to follow.
Karthik Ram: Great question. We are trying to write a how-to for the whole thing, and we're trying to incubate other projects that we can mentor.
Jerod Santo: Okay. Progress on that?
Karthik Ram: It's a new thing that we've started. Like any open source project, we're kind of stretched thin; even though we're seven people, we have these grand ideas to give fellowships to new open source projects, provide support for interns, like The Google Summer Of Code... We have all these grand plans that just take time and staff, and we're doing the best we can.
Jerod Santo: [00:24:00.09] Give us some waypoints where people can go to either learn from your work or to help out with your work. What's the best way to get involved?
Karthik Ram: Fantastic question. We have tons of opportunities for people to get involved. If people just go to GitHub.com/ropensci, you can contribute code, you can contribute documentation, you can help us wrangle issues... And you're welcome to join our Slack. We have a link on our website, and you can participate.
The other thing that we do that is really important to the open source community, that doesn't exist elsewhere, is that we review software.
Jerod Santo: You review software...
Karthik Ram: Yeah, so we allow community members like you to contribute software to our collection, and we put that through very rigorous review, just like a paper goes through a review with reviewers.
Jerod Santo: Like code review?
Karthik Ram: Yeah. It's not even -- it goes beyond code review; they review your code, your license...
Jerod Santo: So this isn't software that's coming into your system, this is anybody's software?
Karthik Ram: No, it's software coming into our system.
Jerod Santo: Okay, software coming in... You say you review your license.. Wouldn't you just have the license of the project? Are you talking about modules, that they hold their own licenses?
Karthik Ram: No, we allow people to have permissive licenses, and so we make sure their license is compatible downstream. We make sure their code is well documented, has a good style, that's easily adaptable, and it's a brilliant process because everything happens in the open, on GitHub, and it takes our reviewers 5-10 hours each to review the software.
Jerod Santo: Wow, that's a long time.
Karthik Ram: And because it's open, it's completely non-confrontational; it's extremely friendly, and reviewers learn a lot, the contributors learn a lot, and in the end software comes out much stronger, and by the time we accept that into our suite, it's a fantastic piece of software.
Jerod Santo: How many of your processes specifically around software review have you codified, automated? 5-10 hours is a big investment; can you reduce that down, or is it already streamlined and that's just what it takes?
Karthik Ram: You are like jumping the gun on things that we're doing, this is brilliant. [laughter] So we are trying to build bots over GitHub that can do a lot of these things - check code quality... We already have bots that can check for code coverage, test coverage, things like that. So we're trying to reduce the burden on reviewers as much as possible, but I think the human interaction plays a big role, because people actually have substantial conversations about "This is how I set up my code", and we think this is really important to building community.
Jerod Santo: I think the best solutions today are still computer-assisted humans. Reduce the burden as much as possible, but keep humans involved.
Karthik Ram: Humans make a huge difference.
Jerod Santo: They sure do... Until our deep learning overlords have learned everything they need to, for perfect software. [laugh]
Karthik Ram: Yup. I'll wait for that day in my self-driving car.
Jerod Santo: Exactly. Awesome. Karthik, thanks for sharing that story, and check out GitHub.com/ropensci. It sounds like a project to learn from and to get involved in, so check that out. Thanks for coming on the show.
Karthik Ram: Thanks for having me.
Adam Stacoviak: Up next we talk with Andrea Goulet and Scott Ford about the love of legacy projects, legacy code... You know, all that stuff most developers hate to deal with. Andrea and Scott run a consultancy called Corgibytes, whose sole focus is to support and maintain legacy code projects. We also learn their podcast (Legacy Code Rocks) is modeled after The Changelog, which was very flattering. Check it out at LegacyCode.rocks. We'll be right back.
Jerod Santo: I'm ready when you guys are. You guys look comfortable.
Andrea Goulet: Yeah.
Jerod Santo: Cool, so I've got Andrea and Scott, with Corgibytes, joining me.
Scott Ford: Hi, thanks for having us.
Andrea Goulet: Hello. It's been a long time coming.
Jerod Santo: It has been. Andrea, did we have you on the show previously, or we interviewed you maybe for our video series, back in the day? Or we just hung out...
Andrea Goulet: We hung out. You gave me a ride at the airport when I was speaking at...
Andrea Goulet: Yeah. And we were like, "Oh, you should get on, because we've got a podcast, too!" and it was like "Yeah, we should totally do that!" and then it didn't happen...
Jerod Santo: Then we just each other... [laughter] So here we have you on; you also have, as you mentioned, your own podcast, Legacy Code Rocks, celebrating legacy code, talking about legacy code... What's that show like?
Andrea Goulet: It's very similar to the Changelog, I think. We've really modeled ourselves after you, and I'm not lying. [laughs]
Jerod Santo: We're flattered.
Andrea Goulet: Yeah, in that it's conversations about a very broad subject that needs to be talked about... But the whole idea is "Let's change the way we think about legacy code." Because legacy code has been seen as this thing that has a lot of shame around it.
Jerod Santo: Yeah, "Stay away from me. This is old and crufty..."
Scott Ford: And we've discovered that there's a very enthusiastic minority of developers...
Andrea Goulet: That might be an understatement.
Scott Ford: Yeah, they genuinely love working on legacy projects.
Jerod Santo: Really?
Scott Ford: I see a lot of overlap between legacy projects and open source projects. Most open source projects you could talk about in the context of legacy. Let's talk about Vim, for example; is there much more legacy than-- or Emacs... We've got these really old text editors, but they're still maintained, and the people who are working on them and diving in those codebases, they're diving into a legacy project.
Jerod Santo: Let me share a little secret... A little Changelog secret. I think I may have told you about this when we talked a couple years back; we were talking about legacy, and I actually had an idea for a show called Legacy, that was dedicated to telling the stories of software that stood the test of time...
Scott Ford: Nice...
Jerod Santo: [00:31:52.12] And it wouldn't be interviews like conversational -- it would be interviews, but more like vignettes, and telling those stories, because they had to be fascinating... Of things like Vim, of all of the little tools that we use in UNIX, and stuff. Like Ls, for instance. I mean, sure, a lot of those built-ins haven't been actively developed for a long time, but nonetheless, they're legacy not because they're old and crufty, but because they've remained valuable for years and years, and I think that's noteworthy, something you should celebrate, as opposed to denigrate.
Andrea Goulet: Right, yeah. And over the course of the project - because it originally started a few years ago where we were at an Agile conference and they happened to have a software craftsmanship track...
Scott Ford: Yeah, and I was speaking at that, and a lot of other people were, too...
Andrea Goulet: It was Llewellyn Falco, Woody Zuill, Arlo Belshee a lot of folks who just are...
Scott Ford: Michael Feathers...
Andrea Goulet: Yeah, who kind of are known in the craftsmanship space, and they said "This is the first time that we all feel like we can talk about legacy code and people don't look at us weird." Because you say that you like working on legacy code and people give you the third eye and they're like 'What? Are you okay?' So we just started a Slack channel with five people, and now it's grown to 400, and we've got the podcast, we started a GitHub repository for open source projects, awesome legacy code, to kind of help curate some of those stories.
I think a big part of legacy code is a lack of communication around things. Telling those stories and sharing that history is a really important part of the knowledge transfer of what went well, what could be better, what should change for your current project.
Scott Ford: And one of the things that we try to do with the show is to really change the attitudes and try to pivot the conversation away from legacy as this word with a huge negative connotation, to a positive thing - it's what you've left behind; it's your benefit to society.
Jerod Santo: I don't know if I've actually worked professionally on legacy code, and I have, I guess, definitions, semantics and stuff, but I've done a lot of what I call "rescue projects", which I think are in the same category... Where it's like, 'This has fallen into a state of disrepair, and yet it's still valuable to this company for reasons X, Y and Z. We need to save it." And I will just say that, while I've gone into those projects carefully, I had a whole lot of fun "saving the day", so to speak... It's kind of the same idea as when you flip a house. You buy an old, lapidated house, and you repair it and you bring life back to this thing again.
Andrea Goulet: Yes, that's exactly what we call what we do at Corgibytes - we do software remodeling.
Jerod Santo: Yeah. And there is a real satisfaction there that's unexpected, so I think you're definitely on to something. And as you mentioned, you guys do this professionally with Corgibytes, so this is like Corgibytes' thing, right?
Andrea Goulet: Yeah, it was like "Instead of doing sponsors, we'll just fund it through CorgiBytes and we won't stress about it." So we've kind of taken a different model and a different approach, but that just has meant that it's easier for us to maintain it.
Jerod Santo: So Corgibytes could be a thriving consultancy - is that what you guys consider yourselves? Or a software firm...?
Scott Ford: I think consultancy.
Jerod Santo: Consultancy is fair.
Andrea Goulet: I sometimes say "a group of people who are passionate about software maintenance and modernization."
Jerod Santo: Oh, sales team right there. [laughter]
Andrea Goulet: I don't know if that's a consultancy or if it's a product team...
Jerod Santo: That's why you always let Andrea tell people what it is... [laughter] Scott's like, "Yeah, we're a consultancy..."
Scott Ford: Yes, that's why she talks a lot more than I do.
Jerod Santo: I guess the reason I point that out is because there's good money in doing the work that a lot of other people don't wanna do, right? You guys have found that? You're giving me the side eye, maybe there's not that good money.
Andrea Goulet: [00:36:01.18] Well, I think with any business there's always gonna be ups and downs that fluctuate, but we've got a team of 12 people now, and we've got a backlog of resumes, surprisingly, of people who want to leave their current gig and come work for us...
Scott Ford: Yeah, I feel like we have the inverse of what a lot of technology firms have, where...
Andrea Goulet: Which we were not expecting.
Jerod Santo: You have a lot of people wanting to work for you...
Scott Ford: There's a lot of people who wanna work for us, and we don't have enough clients to hire everyone who would love to work for us. So it's an interesting flip in the ecosystem, where most firms can't find talent, and we have talent knocking on our doors.
Jerod Santo: Yeah, that's interesting. A good problem to have, but still a problem. [laughs]
Scott Ford: Yeah, exactly.
Andrea Goulet: So coming to conferences like this, talking about open source... Because I think the big thing for me as a marketing person... I've heard Scott -- and originally, the original mission of Corgibytes was you wanted to figure out "How could I get paid to work on open source?"
Scott Ford: Yeah, specifically fix bugs on open source projects.
Andrea Goulet: That's your dream job.
Scott Ford: I love fixing bugs, specifically. Hunting down a bug brings me more joy than almost anything else I can communicate.
Jerod Santo: Wow.
Scott Ford: And hunting it down and fixing it, getting the fix pushed out - I love that. If no other constraints in my life, that's what I would do full-time for open source projects. I would just bounce from project to project, as my interests suited me, and I would just fix bugs. If you look at the open source projects I've contributed to across my career, very few features have been added. Or the features that have been added -- I think of the lack of the feature being there as like a bug.
Andrea Goulet: Yeah, like the tree view in Atom, kind of...
Scott Ford: Yeah. I'm really proud that one of my contributions to Atom 1.0 was that you can configure the tree view to sort the way MacOS finder sorts files, so it can be alphabetical regardless of whether it's a folder or a file...
Jerod Santo: Right. So that wasn't there and you thought, "That's a bug, I'm gonna add it."
Scott Ford: Exactly. I was coming from TextMate, and I liked the way TextMate sorted things (it sorted them that way), and I wanted that to be an option in Atom, so I added it.
Jerod Santo: That's really interesting. So you started off with "How can I make a living fixing open source bugs...?"
Andrea Goulet: Yeah, and I think we found that--
Jerod Santo: That you actually can't do that. [laughter]
Andrea Goulet: Yeah, not yet... So I was like -- with my background in marketing, I was like "Well, we can pivot and say we do maintenance and modernization", and...
Jerod Santo: Right, figure it out somehow...
Andrea Goulet: We'll figure it out, and at least make it so that we can get paid...
Jerod Santo: It seems like you're like looping around to it.
Andrea Goulet: Yeah.
Jerod Santo: "We can't start there, but maybe we can end up there."
Scott Ford: Right.
Andrea Goulet: Well, it's interesting too, because my background is in content strategy and copywriting, and I always wanted to be a copywriter, but for applications, not for marketing websites. I've done it for large enterprise companies, but it was like "I wanna be the copywriter. I wanna go in and fix all of your error messages and move them from passive voice to active voice, and from third person to second person."
Jerod Santo: Oh... You should come hang out with me. [laughter]
Scott Ford: Or make them helpful user error messages.
Andrea Goulet: I did that on Bundler; that was how I got started - I just said "Here, let me go in and update error messages." They got accepted, but it's hard for me to find time to do that, so it's like "These are the things that we love - how can we figure out how to make a sustainable business out of...?"
Scott Ford: Especially as like parents who are also business owners... We're at different phases of our life than I was when I was a lot younger, and kind of recognizing the amount of privilege that goes into being able to contribute to an open source project, and just the economic privilege that I have. I have free time; I have time that I don't need to be doing anything else, and I have mental energy to put in this direction.
Jerod Santo: That's a good point, because sometimes you have the time, but you're just out of the mental energy, because you've spent it on things you need to... And now maybe you're in a place where you're not completely time-strapped, but I know I get to the end of certain days and there's just no way I'm gonna kick out the editor and do anything of quality. Maybe I can add some bugs... [laughter]
Scott Ford: Right.
Andrea Goulet: [00:40:10.02] Yeah, and part of it is like "How easy is it?" If you don't have good documentation, do you have continuous deployment set up so that you can just kick something off? Or is it gonna be this big back and forth where you haven't developed a relationship with the maintainer? There's a lot of idiosyncrasies there of "Do people want me to go in and fix their error messages? I don't know."
Jerod Santo: Yeah. Thinking about a lot of the recent conversations, both here at Sustain and elsewhere around the value of non-code contributions, and really the desire, the need - not just for sustainable projects, but for healthy projects... One of the things I like to have as a conversation here with people - I haven't quite opened it up - is like "Does healthy and sustainable mean the same thing or are there distinctions?" I think there are distinctions, but that's a conversation to be had.
Definitely, we all see that valuing and recognizing the value of non-code contributions is such a necessary thing and something that's been lacking for a very long time.
Scott Ford: Yeah, and even in my focus, of like I love to fix bugs, issue triage becomes the first step of that, and I see that as a non-code contribution. I go in, I'll sort by oldest - I'll go into GitHub and sort the issues by oldest.
Jerod Santo: You're a saint. [laughs] Who's this guy? Who's gonna go into some projects owned by owners and start like fixing stuff?
Andrea Goulet: That's what he does, yeah.
Scott Ford: I'll first try to reproduce it, right?
Jerod Santo: Sure.
Scott Ford: Like, this doesn't look like it's an issue anymore. At least leave a comment.
Andrea Goulet: "Would you like me to clean it up?"
Scott Ford: At least leave a comment, either from the maintainer... Maybe this can be a closed maintainer; it's been open for four years, maybe it's -- I can't reproduce it, no one else has commented on it in four years...
Jerod Santo: Maybe it's not relevant anymore.
Scott Ford: Yeah. Versus "Hey, I've confirmed that this is still an issue and it's been an issue for four versions." I'll dive in and fix it.
Andrea Goulet: The interesting thing to me is, you know, you've got Scott, and we've got the supply figured out, because we've built a whole team of people who basically flock to Scott and are magnets to him, because it's like "You like doing that? I like doing that, too."
Jerod Santo: I wanna go work for him already. [laughter]
Andrea Goulet: I know, right? It's awesome. But then you also have the demand, but yet the supply and the demand -- there's a lot of bugs that need to be fixed, and there's a lot of people who wanna fix them...
Jerod Santo: It's like arbitrage that needs to happen.
Andrea Goulet: Yes, what is that thing that is preventing these two needs from happening and working together?
Scott Ford: Yeah, where's the virtuous cycle that would have those benefitting each other?
Andrea Goulet: Yeah, and we've done things through Corgibytes; we said "Okay, we'll use open source whenever we can, and then when we're billing on a client - and it's generally client work - we'll make fixes as it goes", so in that way we'll continue to contribute, and we do.
We've also had a couple of clients who are supported by a foundation, so they have us just kind of come in for a few months, clean up their backlog, do issue tracking, things like that.
Scott Ford: One of our clients, their project is hosted on GitHub in the open, and we help them out with moving forward on a Rails upgrade from 3.2 to 4.x.
Jerod Santo: Nice.
Andrea Goulet: Basically, enhancing documentation, so that we can be an augment of that. But I think it's even more systemic than that, and are there different business models, like open source insurance, that companies could pay for on a specific project? Could they use the Patreon model where it's like an individual developer contributes and says "I value this, so we're not relying so much on enterprises or organizations." So you've got a couple other ideas, too.
Scott Ford: [00:43:56.05] I have a blog post -- I have three, but I can't remember the third... [laughter One was insurance, one was a Patreon model where you have a large -- oh, I remember the third one. The third one was kind of like a collective of organizations that depend heavily on a particular project, and having that group of people or organizations come together to fund a full-time person on that project. To do so, maybe the money for that would be managed through something transparent like Open Collective, but recognizing that there are smaller businesses out there who depend on open source projects just as much as the really big companies do, but they can't afford to hire somebody full-time.
Jerod Santo: Full-time staff members, yeah.
Scott Ford: They probably could afford maybe a tenth of a full-time person. So if you had ten of those companies come together, then you do have a full-time person who's funded to keep that project healthy.
Jerod Santo: Yeah. I think maybe part of the problem -- just thinking about how open source creeps into organizations over the years, and it's been a very ground-up, grassroots... Like, an engineer by engineer either not asking for permission, [laughter] or convincing just the person above them that this is a good idea, until the point where a lot of these organizations don't even realize --
Scott Ford: And I feel that that came out in the data from the open source survey that GitHub just recently published... It was like this lack of clarity on policy, but anybody's doing it anyway.
Jerod Santo: Yeah, exactly. Or they say they're free to do it but not to contribute back, which is super weird.
Andrea Goulet: You had that when you were working at a large company that does consulting for the federal government.
Scott Ford: Yeah, that was owned by a company that had like three open source projects, and I'm trying to be kind and not use names... But that company's culture was very anti open source, and this anti open source culture had infected the subsidiary that I worked for. I was using one of our parent companies' open source projects at a client's site, and found a bug in it, and fixed the bug, and went to contribute the fix back, and had to get a copyright authorization letter signed by my legal team, so I passed it along -- it opened up this can of worms, like "Wait, you're using open source at one of our clients? Wait, you're using open source in general? Our culture doesn't support open source." For a minute, I thought I was gonna get fired; I thought I genuinely might get fired.
Jerod Santo: How did it pan out?
Scott Ford: The change was accepted...
Jerod Santo: Okay... The paperwork went through...
Scott Ford: The paperwork went through, the change was accepted, but it was kind of like a slap on the wrist. They then published a -- they created a policy saying that if you use open source at a client site, you need to make it very clear to the client that you're using open source, and the client needs to be involved in that decision-making process.
Jerod Santo: The way that I do it with my consultancy is kind of you guys' first method of -- I work it into my contract, kind of like two levels of deliverables, where it's like first-party deliverables and second-party... And those are open source things. So I feel very free in my work; their entire stack is built upon open source, so I see this issue or this problem, or a place that need fixing, and I just plug the whole -- I don't ask individual client "Hey, can I go do this bug fix?" That being said, because of the way that I do it, I don't feel free to make large contributions. It's fine for a bug fix; even sometimes just submitting the bug is of value, reporting. Otherwise, maybe a small -- like, I change this API to accept two things instead of one.
Andrea Goulet: Right. Like, we've had to build a small gem once.
Scott Ford: Yeah, we built a couple small gems to fill a crack like that.
Jerod Santo: Right, but I do not feel like it's in my client's best interest to go and spend 20 hours building a brand new thing or a huge feature, which probably would be generally useable to lots of people... So there has to be other ways.
Andrea Goulet: [00:48:07.14] Yeah, we're in the same thing. I think you've mentioned something really important, which is the legal framework around it, because we had the same thing - we had our attorney look at everything through the lens of open source, and I think that's something that most consultancies might forget, is that there's a lot of IP-related things here, so we have it in our master services agreement that you are allowing us to use and to spend --
Jerod Santo: And I've had a couple clients push back on that particular point as well, or at least ask for clarification.
Scott Ford: Yeah, we have as well, because we have a clause in there that says if we make a change to a third-party open source project, that change is governed under that license; it doesn't belong to the organization we're working for.
Jerod Santo: Exactly.
Scott Ford: Because I don't wanna be in violation of a GPL copyleft license; I don't want there to be a conflict between the contract that I've signed with the client and the license I'm using for a particular open source project.
Andrea Goulet: Yeah, and it's so funny, we're going through this with a client now... It's like, everything's great, everything is looking good, and then it's like "Okay, now I just need to get my legal team to run past it, or my CEO", and then we get the "I've reviewed hundreds of contracts and I've never seen a clause like this, this type of intellectual property treatment." And we're like, "Well, that's because we've actually thought about how we use open source, and this is the way it has to be."
One of the things that I've been really encouraged about at the conversations today is how do we broaden the experience and invite people who have more experience, so that open source doesn't feel like it's just a group of software developers, it's really a cohesive and integrated, collaborative, cross-disciplinary team.
Jerod Santo: Yeah, get more kinds of people to the table, right? From different walks of life, but also from different areas of business. It's like the textbook definition of diversity; it's like, not on this stratosphere or that one, but like all of them, all stratums.
Andrea Goulet: Well, it's various small things. Today, for example, a) they had childcare. Scott and I are also married; we are business partners first -- I'll give a quick origin story. Scott and I went to high school together, reconnected at our ten-year reunion; Scott was running the business, said "I have no idea what I'm doing in terms of marketing. Can you come help?" So I did, and then we got married two years later and now we have two kids. So a lot of times, if Scott and I both wanna participate in a conversation, it's--
Scott Ford: We have to decide who stays home.
Andrea Goulet: We have to decide who stays home, and I'm usually the one where it's like "Well, Scott, your voice kind of feels more relevant here."
Scott Ford: I feel the same way about her, so...
Jerod Santo: Scott, your voice is more relevant... [laughter] I don't know, you got away with words... It probably depends on -- his confidence level is probably lower. I don't know, I can see both sides. It depends on the conference.
Scott Ford: The impostor syndrome can creep in...
Jerod Santo: Right, that's why I backed that off a second, because I thought, "Well, maybe not."
Andrea Goulet: No, because I get really bad impostor syndrome around like "Am I technical enough?" Like, I don't actually contribute value, all I do is fix error messages and improve documentation.
Jerod Santo: [laughs] Well, that's not viable...
Scott Ford: I'm just a much stronger presenter though. Her voice carries, I'm really quiet; I have to have the mic up my nose, practically... Yeah, as Jerod turns the mic towards my face. [laughter]
Andrea Goulet: But when there's childcare, we don't have to think about it.
Jerod Santo: You don't have to make that choice.
Andrea Goulet: Right. And then, for example -- Gunner, he said, just be mindful of how these are biases where women are typically note-takers, so just be mindful of that as you go through today. And small, little things like that have made a huge difference in my ability to feel not just that I am welcome here, but that I can continue to be here.
Jerod Santo: Yeah, that's awesome.
Andrea Goulet: Awesome job to the Sustain organizers.
Scott Ford: Yes.
Jerod Santo: There you go. Shoutout to all the organizers. Any last thoughts? This has been a great conversation. I think I need to come on your Legacy Code Rocks and we just talk legacy--
Andrea Goulet: Please do! Oh gosh, yeah... It's so much fun.
Scott Ford: Yes, we'd love to.
Jerod Santo: I'll just nerd out with you guys.
Scott Ford: Yeah, that's the show.
Andrea Goulet: [00:52:06.17] I would say we're always looking for folks who are interested in being guests. I know that there's a lot of folks who kind of are on both the Changelog, as on their feed, so... You listen to it every night when you do the dishes.
Scott Ford: Yeah, I listen to the Changelog while I do the dishes.
Jerod Santo: Well, you might have to hear your own voice on an upcoming.. "What the heck? Oh, this episode is terrible!" [laughter] As we all self-criticize... So very cool - Legacy Code Rocks is the podcast, Corgibytes is the company...
Andrea Goulet: Yeah, right now that's the newsletter we're working towards, and you can find the podcast in Stitcher or iTunes if you just look up Legacy code rocks.
Jerod Santo: Very cool.
Andrea Goulet: And from the newsletter you can join the Slack channel and things like that. One of these days we'll have a whiz-bang website like you do and fancy microphones [laughter]
Scott Ford: Yeah. And then we also have a weekly mastermind group that's kind of like a virtual meetup, basically... I'm almost always there, and then whoever shows up at a given time.
Jerod Santo: What do you guys talk about?
Scott Ford: Whatever the people who show up wanna talk about. It's pretty much just a free-form meetup kind of style, and there are people who come in, lurk and just listen; they turn off the cameras and mute their microphones and just listen to the conversation. Maybe we can start recording them, that might be content that'd be worth sharing.
Jerod Santo: I was gonna say it sounds like a podcast to me. [laughter]
Scott Ford: So sometimes we'll do some group pairing on different projects, different techniques... Whatever people will talk about that they wanna bring -- sometimes we've had people really struggling with how to solve this particular problem, and then we'll help that person with it. It's neat.
Jerod Santo: Very cool. Cool, well, Scott, Andrea, thanks so much for joining us.
Scott Ford: Thank you.
Andrea Goulet: Yeah, thanks for having us.