The Changelog: Software Development, Open Source - Conversations about sustaining open source (Interview)

Episode Date: September 22, 2017

This episode features conversations from Sustain 2017 at GitHub HQ with Richard Littauer, Karthik Ram, Andrea Goulet, and Scott Ford. Sustain was a one day conversation for open source software sustainers to share stories, resources, and ways forward to sustain open source.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Hired. Hired matches outstanding people with the world's most innovative tech companies out there. Hired uses an algorithmic job matching tool in combination with a talent advocate who will walk you through the entire process of finding a better job. You might be looking for a more flexible work schedule,

more money, or remote jobs so you can travel and see the world. You might be looking for opportunities at Facebook, Mixpanel, or Squarespace, or the many other top tech companies out there looking for engineers on Hired. You and your skills can be a valuable asset to any of these companies. You just have to take the first step. That first step is Hired.com slash ChangeLog. Go there, learn more. Our listeners get a special $600 hiring bonus

when you find your next opportunity on Hired. Once again, Hired.com slash ChangeLog. From ChangeLog Media, Thank you. We had at Sustain, which is a one-day conversation for open-source software sustainers that was held at GitHub HQ back in June. We talked with Richard Littauer about scaling open-source maintenance and models to avoid burnout. Karthik Ram, the project lead of R OpenSci, an organization who develops open-source R packages for the data science community. We talked about how they plan to support and scale their thriving open science tools. And last, we talk with Andrea Goulet and Scott Ford, who run a consultancy called CorgiBytes, about legacy code and modernizing existing software applications.

Okay, so now I'm recording. So, Richard, tell me your full name. My name is Richard Liptower. And you're with maintainer.io. Maintainer.io is my main thing at the moment, yes. But what I want to talk about is theuserisdrunk.com. The User is Drunk 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.

It went viral and then it dissipated and died? 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 and it's a non-sustainable business model. So would you actually become intoxicated and then peruse websites? Yes, and there's videos online. For money. Yeah. Did the intoxication actually aid in your ability to suck at using the website?

It very much did. It also taught me a lot about what UX is and how it works. Yeah. 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. Turns a hobby into a job real fast.

It does. So tell me about this maintainer thing you're doing. So I was the 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 to maintain the IO. And basically what I do is community management as a service. So I'll come into your 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. So it seems a little bit odd to bring in an outsider to help build a community when it's like, isn't the people who are there the community? But a lot of times they don't have the information.

They don't have the knowledge of 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. Sure. So it's like a consulting situation. It's like a consulting situation. But you'll actually take the reins and get it going. 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 going to 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 the issue triage and out-of-office replies. Cool. So, I mean, you just kicked that off when? Recently, right? Around two and a half months ago.

Two and a half months ago. Tell me, how's it going so far? It's going great. I've had a lot of clients, 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. I have a much bigger client on the way, hopefully. And yeah, things are just better than expectations. Is this the kind of work that you really enjoy doing? 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. I like sharing that

sort of energy. So you have a vested interest in seeing open source sustain, of course, because you're super invested completely into that. We're here at this sustain event today. Late afternoon, so we've had most of

the day. We're getting to the solution section, but what are some highlights for you or takeaways you've had so far, conversations? One of the great highlights was I had a meeting about what makes a good maintainer. And we sort of come away with the idea that's actually just self-awareness and being able to say, I'm good here, I'm not good there. And 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 want to get involved in this? And like the long emotional tale of code. And so it's good to have people here talking about that and not just

being, yeah, code's just about the, you know, semicolons. It's more than that. So turning to yourself now, self-awareness. Yep. As somebody who sells maintainer services, what do you excel at and what do you struggle at with regards to software projects? 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 want to become a maintainer. How easy is that? How hard is that? I excel at figuring that out. The dev X of open source code. I am not the best person to figure out if your implementation is spec compliant.

Okay. So are there certain kinds of technical projects that excite you more than others? Or do you not care? I love JavaScript stuff. I love NLP stuff. I was trained as a computational linguist. I love internationalization.

And I'm a big fan of standards. I built a thing called standard readme. How to write a good readme. And I love making things compliant to that. It's kind of like pseudocode, pseudodocumentation. One of the things that we're doing here is actually going on right now as we speak is

gathering examples of people who are doing it right. So as you got around helping other people do maintenance and building 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 going to do well? NPM does a lot of good stuff with their community. They're not perfect in some ways. The CLI tools and the like, they've been 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. Node Together was great. That's with Ashley. Big fan of a lot of high-level decisions, like Go's decision to have a formatter. And so you just get rid of a lot of high-level decisions like Go's decision to have

a formatter. And so you just get rid of a lot of the issues that you have in other languages like JavaScript. Yeah, there's a lot of great projects, a lot of bad ones, but I just love it when you can see that people really care and it's obvious. 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. I don't mind which god you worship, you know. It's objective now. People who use tabs make less money. So it's like the final sec or the final say on the debate.

Just put a.file in your repo to automatically convert them and move on. There you go. Anything else about this event or about sustainability in general that you'd like to bring up as something you've learned or know or would like to have discussed more? 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 the project, for the best of the people, staying safe. One thing I noticed when I asked you for examples, you gave Node, Hoodie, and NPM. Yep. And these are organizations. Yep. What about a smaller scale?

Like you said, a lot of us are hobbyists. We're individuals. Yep. Maybe we're a team of two. Yep. First of all, are there any examples of people doing it well on the small? Yeah, I really like Sinister Sore Houses. Oh, yeah.

Way of doing things. I love how he has an AMA repo that has, like, hundreds and thousands of stars where you can just ask him questions. I've met him. He's just 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. I mean, he's not a small example. He's the most prolific coder on GitHub. Small in terms of he has small

projects, right? Yeah, exactly. Oftentimes he's the only person who has, you know, commits on those projects. On the other side of things, you know, 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 like, you know, 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. Noffle. Noffle has some really great stuff. He wrote a thing called Art of Read Me, which

just is a really passionate plea to have better documentation. Yeah. 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. Huh.

Very cool. Going back to, is it Sindre? How do you say his name? Sindrosaurus. Yeah, Sindrosaurus. He often will hop into our ping repo. So we have a repo on GitHub where you can just drop projects, drop links. Yep. 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 every time 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. He's always like, no, I'm good. Good for him. He just says no every time. Good for him. I feel like he's a person who really knows who he is.

Yeah, he does. Which is cool. I mean, I don't know him that well. I had lunch with for him. It's like, well. I feel like he's a person who really knows who he is. Yeah, he does. Which is cool. I mean, I don't know him that well. I had lunch with him once. That's about it. But seems like a great guy. And I have a soft spot in my heart 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. Yeah. And then two of the people from Open Collective worked at Cozy Rosengren's office. Casey made Hacker Paradise, which is just awesome. We're big fans of Hacker Paradise. We've teamed up with them and sent a few people. Oh, that's right.

You did that. Yeah. I've been on Hacker Paradise three times. I love it. That's awesome. It's wonderful. So, yeah, I haven't mentioned yet. You said you're a digital nomad.

Name some of the places that you've worked from around the world and some of your favorites? In the past two months, I've worked from Reykjavik, Ireland, Edinburgh, Glasgow, the Highlands, London, Berlin, San Francisco, and Brussels. My favorite is Edinburgh. I went to uni there. That's my home. I did work on the bus from Reykjavik Airport into

Reykjavik 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. I know where that is. Svalbard is the northernmost human-habitated place in the world. Okay. We have a JavaScript conference there in the church, because why not?

He has an NPM package called GeoPackage, which basically every time you push something to NPM, it'll tag your geographical coordinates. And I'm having a lot of fun with that. Oh, nice. Yeah. Very cool. So you have your own little map that you keep? Like places I pushed from?

I have yet to actually make that map work, but knowing that I could makes me pretty happy. Makes you feel pretty good. Cool. Well, thanks so much for sitting down and talking to me. Thank you so much. This has been great. And thank you for being here. It's wonderful. We love it. Happy to. Coming up, Jared talks with Karthik Ram about the struggles he felt

when trying to reproduce code in scientific research papers and how that led to our open sigh 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 4 million dollars in funding and we also cover their plans to support and scale their thriving open science tools. Stay tuned. This episode is brought to you by Bugsnag. Bugsnag improves the task of troubleshooting errors by making it more enjoyable and less time consuming. For example, when an error occurs, your team can get notified via Slack. You can see diagnostic information on the error.

You can identify the developer who committed the code. And Bugsnag's integration with Trello, Jira, GitHub, and many other collaboration tools makes it easy to assign and track bugs as they're being fixed. We have a special offer for our listeners. Head to bugsnag.com slash changelog. Try out all the features completely free for 60 days. Once again, bugsnight.com slash changelog. So, Karthik Ram, here to talk about your open source project.

Tell us about it. What's it called and what does it do? So, my name is Karthik and I co-founded this project five years ago called Our Open Sci. And back then I was a regular scientist with a day job. Okay. Trying to reproduce other people's code and failing. When you say reproduce their code. Yeah. What do you mean by that specifically? So I would read a paper by somebody else and they would say everything that we did is in the supplement and I would run the code and nothing would work. I see. So you're taking code from a research paper and trying to execute it. Yeah.

Gotcha. And it's failing. Nothing works. That sounds suboptimal. Much of scientific research is suboptimal. And then we realized that people are trying to do very specific activities that we can package into modules that we can release. Okay.

If you're trying to do X or Y or munch 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. Okay. And that's five years ago. Five years ago. And fast forward till now, we have almost $4 million in funding.

Wow. We have a staff of about seven people. Wow. We maintain 150 modules. We train people, and we build community. How did you get that done, in a nutshell? Magic. Yeah, exactly.

Just bootstrapping this thing one thing at a time okay well what do you think were the keys so if you had like go back and say well these three things are the reasons why we've gotten to this point and three is not necessarily that's an arbitrary number no but um the things that worked out for us was we built really tight software what do you mean tight? Like simple, simple, robust, well-maintained, good fixing every bugs that came along the way. Okay. And then people started trusting us. And then soon we started getting more and more buy-in from other people. How did you get other people to use it initially? Uh, Twitter. Okay. So we were tweeting things to it. The whole project came together through Twitter.

That's kind of amazing, isn't it? 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? Got each other's email. Came up with a name for the project and said, would you like to apply for funding? We wrote a grant together, got $200,000.

And then we became an entity. Wow. So there's apparently a huge need for what you're offering to just get a $200,000 grant. 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.

Wow. Just found a huge gaping hole in the scientific community. 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. So other scientists who have a burning need for something write software and contribute that to our suite. In like a plug-in style?

Or what do you mean by contribute to your suite? So they contribute a whole module to us. Okay. But we have a rigorous process by which we evaluate software. So we make sure everything is okay they're unit testing there's good documentation they follow best practices yeah so we put them through like the whole ringer and so by the time it comes out the other end it's very good software and then they

go back and they realize like oh i learned a whole bunch of stuff that's that's new to me and so collectively we are elevating the quality of software in scientific research you're making it sound very easy it's not easy it was it was we've been riding a struggle bus for this whole riding a struggle bus yeah what does that mean like like everything's been hard everything's been hard. 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. Yeah. You're looking back at it, and so it's easy to talk about looking back. 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 want to build this thing. We don't know where to start. What have been specific struggles on the struggle bus that you faced throughout the five years? Getting institutional buy-in for our work. Okay. So getting people to trust that we built 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. Right. When did you move from, well, you mentioned the $200,000 grant up front. Yeah. Were you always staffed that way? Or you say, well, we got $200,000,

let's just quit our day jobs and do this right now? Or did you slowly move into that? So I was a postdoc doing actual research back then. And this was my distraction, doing open source. And 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. Now we've made seven people quit their day jobs. Wow. Yeah. What are some challenges you face today?

So five years in, you've got a lot done, but what are some challenges now that face you? And to grow that beyond $1 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. Yeah. So you're always going back to the well of, you know, foundations that you've been relying upon. Yeah, but we also realize that software that we build is making a huge impact on science across the board. And 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. And so perhaps you should just fund us directly. Yeah.

Yeah. Have you, is that like your new idea, or have you made those efforts? No, no, that's our new idea. Oh, it's your new idea. You haven't tried it yet. No, not yet. Sounds like that's a good idea. Yeah.

Right? Yeah, exactly. We just want to reach out to like new funders and tell them we are maintaining key infrastructure that support people that you're trying to support um other struggles so you got the funding side is it is the project of the size now where you have uh is it is its needs beyond the seven people or you feel pretty well? I mean, 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 and 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. So for other people to follow in your footsteps, I guess the first step would be find a huge need. Yeah. Which is not hard because there is a lot of low-hanging fruit that is waiting to be solved. Specifically in research and science? No, just in open source in general.

Yeah. I mean, 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 and so the fact that we've been around for five years and we have a fairly solid plan to keep this sustained makes a huge difference it sounds like a lot of people can probably learn from your experience from your model are you doing any writing or documenting of like success and failures throughout the time and something like a pathway for people to follow great question so we're trying to write a how-to for the whole thing yeah and uh we're trying to incubate other projects that we can mentor yeah okay uh progress on that is like just a it's a

it's a new thing that we've started but like any open source project we're kind of stretched thin yeah so even with seven, we have these grand ideas to give fellowships to new open source projects, provide support for interns like the Google Summer of Code. But we have all these grand plans that just take time and staff, and we're doing the best we can. 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? Oh, fantastic question. So we have tons of opportunities for people to get involved. If people just go to github.com slash ropensci, so it's the letter R, the word open, and the letters S-C-I.

You can contribute code. You can contribute code. You can contribute documentation. You can help us wrangle issues. And you're welcome to join our Slack. We have an open link on our website. And you can participate. But 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 you review software 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 review with reviewers like code code review? Yeah. It's not even, it goes beyond code review. They review like your code, your license. So this isn't software that's coming into your system, but this is anybody's software? No, no, it's software coming into our system. Okay, software coming in. You say review your license.

Wouldn't you just have the license of the project? Are you talking about modules? Do they hold their own licenses? 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 five to 10 hours each to review the software. Wow, that's a long time.

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, the software comes out much stronger. By the time we accept that into our suite, it's a fantastic piece of software. How many of your processes around, specifically around software review, have you codified, automated? Five to ten hours is a big investment. Can you reduce that down, or is it already streamlined, and that's just what it takes?

You are jumping the gun on things that we're doing. This is brilliant. 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. And 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 conversations, substantial conversations about this is how I set up my code. And we think this is really important to building community. Yeah. Yeah. No, I think it's,

I think the best solutions today are still computer-assisted humans. Yeah. Right? Like reduce the burden as much as possible, but keep humans involved. You know, until the... Humans make a huge difference.

Sure do. Until our deep learning overlords have learned everything they need to for perfect software. I will wait for that day in my self-driving car. Exactly.

Awesome. Well, Karthik, thanks for sharing that story and check out github.com slash ropensci. Yep. Sounds like a project to learn from and to get involved in.

So check that out. And thanks for coming on the show. And thanks for having me. Up next, we talk with Andrew 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 Corgi Bytes, 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. And we'll be right back. This episode is sponsored by CircleCI. CircleCI is a continuous integration and delivery platform that helps software teams rapidly release code with confidence by automating the build, test, and deployment process. They recently launched version 2.0 of their platform with a focus on providing faster build times thanks to advanced caching strategies and flexible resource allocation. Super fast build cycles ensure quality code by using SSH access and local builds to quickly troubleshoot and remediate. Flexibility to run CI and CD without limits. There's no pausing work while environments update and language inclusivity frees up your team to use any tool chain or framework because CircleCI supports every language that runs on Linux. And finally, control workflows, let your team run, build, test, deploy stages as individual jobs, which lets you fully customize your

development process. There's a ton more to learn about CircleCI, so head to circleci.com slash changelogpodcast. Once again, circleci.com slash ChangeLawPodcast to learn more. I'm ready when you guys are. You guys look comfortable. Yeah. Cool. So with Andrea and Scott with Corgi Bites. Hi. Hello.

Thanks for joining me. Yeah. It's been a long time coming. It has been. So Andrea, did we have you on the show previously? No. Or we interviewed you for, maybe it was for our video series back don't back in the day or maybe we just hung out we hung out you gave you gave me a ride at the airport okay when i was speaking at uh moraska javascript conference

a couple years back yeah so um and we were like oh you should get on because we've got a podcast too and it's like we're gonna we should totally do that and then it didn't happen we lost each other so here we have you on you also have your own as you mentioned your own podcast legacy code Because we've got a podcast too. And it's like, yeah, we should totally do that. And then it didn't happen. We lost each other. So here we have you on. You also have your own, as you mentioned, your own podcast, Legacy Code Rocks. Yes. Celebrating legacy code, talking about legacy code. What's that show like?

So it's very similar to the Change Log, I think. We really modeled ourselves after you. And I'm not lying. We're flattered. In that it's about conversations about a very broad subject that needs to be talked about. Yeah. 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. Yeah, stay away from me. This is old and crufty. And we've discovered that there's a very enthusiastic minority of developers. That might be an understatement. Yeah. They genuinely love working on legacy projects. Really?

And I see a lot of overlap between legacy projects and open source projects. I think 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 have these really old text editors that are still maintained, and the people who are working on them and diving into those code bases,

they're diving into a legacy project. Let me share a little change log secret. I think I told you about this back when we talked a couple years back, because 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.

And it would be like more, it wouldn't be interviews, like conversational, it would be interviews, but it would be more like vignettes and telling those stories because they have to be fascinating of things like Vim, of all of the little tools that we use in Unix and stuff. And it's like LS, for instance. I mean, sure, a lot of those built-ins haven't been actively developed for a long time.

But nonetheless, their legacy, not because they're old and crufty, but because they've become, they've remained valuable for years and years and years. And I think that's noteworthy and something you should celebrate as opposed to denigrate. Right. Yeah. And, you know, over the course of the project, because it originally started, you know, a few years ago where we were at an Agile conference and they happened to have a software craftsmanship track. Yeah. And I was speaking in that.

You were speaking. And a lot of other people were too. So was Llewellyn Falco, Lee Zool, Arlo Belshi, a lot of folks who just are. Michael Feathers. Yeah. Who kind of are known in the craftsmanship space. And they said, you know, this is the first time that we all feel like there's like where we can actually talk about legacy code and people don't look at us weird because you say that you like working on legacy

code and people like give you the third eye they're like what are you okay like um and so we just started a slack channel like well we'll start with these five people and then now it's grown to 400 and we've got the podcast we started a g GitHub repository for open source projects, awesome legacy code, to kind of help curate some of those stories. And I think a big part of legacy code is a lack of communication around things. Right. So 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. And one of the things that we like to do with the show, or 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 it's a positive thing. It's what you've left behind. It's your benefit to society. So I don't know if I actually worked professionally on legacy code. And I guess definitions of semantics and stuff.

Yes. But I've done a lot of what I call rescue projects. Yes. Which I think those are kind of in the same category where it's like this has fallen into a state of disrepair. Yes. And yet it's still valuable to this company for reasons X, Y, and Z. We need to saveair. Yes. And yet it's still valuable to this company for reasons X, Y, and Z. We need to save it. Yep.

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. And taking something, it's kind of the same idea as when you flip a house. Yeah. You buy an old dilapidated house and you repair it and you bring bring life back to this thing again that's exactly what we call what we do we say at corgi bites that we do software remodeling yeah and there is a there is a real satisfaction there that's unexpected and so i think you're definitely on to something and as you mentioned you guys do this professionally with corgi bites and this is like corgi bites thing right yeah and so yeah it was

more like it was like, instead of doing sponsors, we'll just fund it through Corgi Bytes and just we won't stress about it. Right. 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.

But there's also, because I mean, like Corgi Bytes can be a thriving consultancy. Yep. Is that what you guys consider yourself, or a software firm? What do you guys? I think consultancy. Consultancy is fair. Yeah, that's fair.

I sometimes say a group of people who are passionate about software maintenance and modernization. Okay, maintenance and sales team, right there. Yes, exactly. However, if that's a consultancy or if it's a product team, it's, you know. That's why you always let Andrea tell people what it is. Yes, yes. Scott's like, yeah, we're a consultancy. That's why she talks a lot more than I do, yeah.

But I guess the reason why I point that out is because there's good money in doing the work that a lot of people, other people don't want to do. Yeah. Right? I mean, you guys have found that? Or, oh, you're giving me the side eye. Maybe there's not that good money. Well, I mean, I think with any business, there's always going to be ups and downs that fluctuate, right?

But, I mean, 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. Yeah, I feel like we have the inverse of what a lot of technology firms have. Which is, we were not expecting. A lot of people wanting to work for you. There was a lot of people who want to work for us, and we just don't have enough clients to hire everyone who would love to work for us.

Wow. And so it's an interesting flip in the ecosystem where most firms can't find talent, and we have talent knocking down our doors. That is interesting. Good problem to have, but still a problem. Yeah, exactly. So coming to conferences like this, talking about open source,

because I think the big thing is, for me as a marketing person, I've heard Scott, I mean, originally, the original kind of mission of Query Bytes was you wanted to figure out how could I get paid to work on open source. Yes, specifically fix bugs in open source projects.

That's your dream job. I love fixing bugs specifically. Hunting down a bug brings me more joy than almost anything else I can communicate. Wow. And hunting it down, fixing it, getting the fix pushed out, I love that. And if no other constraints on my life, that's what I would do full-time for open source projects. And I would just bounce from project to project as my interests suited me.

That's very interesting. And I would just fix bugs. I would add very, and if you look at like the open source projects I've contributed to across my career, very few features have been added. Yeah. Or if the features that haven't been added, it's like I think of the lack of the feature being there as like a bug. Yeah. Like the tree view in Atom kind of.

Yeah. Yeah. Yeah, like the TreeView and Atom kind of thing. Yeah, yeah. So I'm real proud of one of my contributions to Atom 1.0 was you can configure the TreeView to sort the way macOS Finder sorts files. Okay. So it can be alphabetical regardless whether it's a folder or a file. Right. And so that wasn't there, and you thought, this is a bug, I'm going to add it. Exactly.

I was coming from TextMate, and I liked the way TextMate sorted things, and it sorted them that way, and I wanted that to be an option in Atom. So, I added it. That's very interesting. So, it started off with, like, how can I make a living fixing open source bugs? Yeah. And we quickly found that... You actually can't do that. Yeah. Not yet.

So, I was like, well, you know, in my background in marketing, I was like, well, there's plenty of... You know, we can pivot it, and we can, you know, say we do maintenance and modernization. Right. Figure it out somehow. We'll figure it out and at least make it so that we can get paid. It seems like you're like looping around to it. Yeah.

We can't start there, but maybe we can end up there. Right. 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. Like I've done it for, you know, large enterprise companies, but I was like, I want to be the copywriter. Like I want to 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, right? You should come hang out with me. Or to make them helpful users. Yeah, right. So I did that on Bundler. Like that was how I got started. I just said, here, let me go in and update error messages.

And they got accepted. But it's hard for me to find time to do that. And so it's like, how can we figure out? These are the things that we love. How can we figure out how to make a sustainable business out of that? Especially as parents who are also business owners. that we love how can we figure out how to make a sustainable especially out of especially as like parents who are also business owners i mean it's like you know different phases of our life than than i was when i was a lot younger yeah and kind of like recognizing the the amount of privilege

that goes into being able to contribute to a non-profit project yeah and just like the economic privilege like that i have i have free time i have time that right that i don't need to be doing anything else and i have mental energy to you know put in this direction that's a really yeah 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 right and now maybe you do have 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 going to kick out the editor and do anything of quality.

Maybe I can add some bugs. Yeah. I'm not going to fix any bugs. And part of it is, like, how easy is it, right? So if you don't have good documentation, like, how is it, you know, do you have continuous deployment set up so that, you know, you can just kick something off and, you know, or is it going to be this big back and forth

where you haven't developed a relationship with the maintainer? So there's kind of a lot of idiosyncrasies there of do people want me to go in and fix their error messages? I don't know, right? Just 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 or the need,

not just for sustainable projects, but for healthy projects. And one of the things I would like to have this 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. But definitely we all see that valuing and recognizing the value of non-code contributions as such a necessary thing and something that's been lacking for a very long time. And even, like, 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. Right. I go in. I'll sort it by oldest.

I'll go into GitHub and sort the issues by oldest. You're a saint. I'm this guy. I know, right? He's going to go into some projects or my oldest. That's what he does. And start fixing stuff. Or I'll first try to reproduce it.

Right? Sure. And this doesn't look like it's an issue anymore. And at least leave a comment. Would you like me to clean it up? At least leave a comment, either for the maintainer. Maybe this can be closed, maintainer. It's been open for four years.

I can't reproduce it. No one else has commented on it in four years. Maybe it's safe to close it. Maybe it's not relevant anymore. 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.

Yeah. So the interesting thing to me is you've got Scott, and we've got the supply figured out, right? 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, right? I want to come work for him already. I know, right?

It's awesome. But then you also have the demand, but yet the supply and the demand, like there's a lot of bugs that need to be fixed, but there's a lot of people who want to fix them. It's like arbitrage that needs to happen. Yeah, what is that thing that is preventing these two needs from happening and working together. Where's the virtuous cycle that would have those benefiting each other?

Yeah, and we've done things like through Corgi Bytes, we said, okay, well, we'll use open source whenever we can, and then when we're billing on a client and it's genuinely client work, we'll make fixes as it goes. And so in that way, we'll continue to contribute, and we do. We've also had a couple of clients who have paid, like they 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. Yeah, like one of our clients, like their project's hosted on GitHub in the open. And we did, we helped them out with moving forward on a Rails upgrade from 3.2 to 4.x. Yeah. Nice. So basically, you know, enhancing documentation.

We can be kind of 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 can pay for on a specific project or like you know 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 had a couple other ideas too where the yeah i have a blog post and like i had three but i can't remember the third um but yeah one was insurance one was kind of a patron model where like you have um a large um oh i can't i remember

the third one the third one was kind of like a collective of organizations that depend heavily on a particular project having that group of people that group of people or organizations or whatever come together to fund a full-time person on that project. And to do so, like, you know, maybe the money for that would be managed through something transparent like Open Collective. But the kind of recognizing that, like, 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.

Full-time staff members, yeah. 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. 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 or convincing just the person above them that this is a good idea

to the point where a lot of these organizations don't even realize. And I feel that that came out in the data from the survey, the open source survey that GitHub just recently published. It was like this lack of clarity on policy, but everybody's doing it anyway. Right. Yeah, exactly. Or they say they're free to do it, but not to contribute back, which is super weird. You had that when you were working at a large company

that does consulting for federal government. 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 so this anti-open source culture had infected the subsidiary that I worked for. And I was using one of our parent company's open source projects at a client site and found a bug in it and fixed the bug and went to go contribute the fix back and had to get a copyright authorization letter signed by my legal team. And so I passed it along and it like opened up this can of worms. Like, wait, you're using open source at one of our clients. Like, wait, you're using open source in general, like, or culture doesn't support open source. And so it was this really interesting, like, like for a

minute, I thought I was going to get fired. I thought I might genuinely might get fired. Um, how did it pan out? The change was accepted. Okay. Yeah. Just paperwork went through. Paperwork went through, The change was accepted. But yeah, it was kind of like a slap on the wrist. And they then published a, they created a policy saying that if you're using open source at a client site, you need to make it very clear to the client that you're using open source. It was kind of the, was what was, and that the client needs to be involved in that decision making process. Yeah, so the way that I do it with my consultancy is kind of your guys' first,

I think he's all right, it's kind of your 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. And so I feel very free in my work as they're relying, like their entire stack is built upon open source. And so I see this issue or this problem or a place that needs fixing and I just plug the hole. I don't ask each 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. Right. Right. It's fine for a bug fix or even sometimes just submitting the bug is a value, right? Like reporting. Otherwise, maybe a small, like, I'm changing this API to accept two things instead of one. Like we had to build a small gem once. Right.

We built a couple small gems to fill a track like that. I do not feel free. 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 usable to lots of people. And so there has to be other ways. Yeah, we're in the same thing. And I think you 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. And so we have it in our master services agreement that you are allowing us to use and to spend a lot of time on. And I've had a couple of clients push back on that particular point as well or at least ask for clarification on that. We have as well. 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 and doesn't belong to the organization we're working with. And because I don't want to be in violation of a GPL, you know, a copy left license, I don't want there to be a conflict between the contract that I've signed with the client and the license they're using from a particular open source project. Yeah.

And it's so funny because we're going through this with a client now. It's like, everything's great. Everything's looking good. And 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 have never seen a clause like this. Right. It requires this type of intellectual property treatment. And we're like, well, that's because we've actually like thought about how we use open source and this is, this is the way it has to be.

And so I think that gets to, and 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 are, you know, have more business 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. Get more kinds of people to the table, right? Yeah. From different walks of life, but also from different areas of business.

Right. It's like the textbook definition of diversity is like, not on this stratosphere or that one, but like all of them, right? Well, and it's very small things. So like today, for example, A, they had childcare, right? So we were the only ones who took it. So Scott and I are also married. We were business partners first.

Yeah. So we'll give a quick origin story. So Scott and I went to high school together, reconnected our 10-year reunion. Scott was running the business, said, I have no idea what I'm doing in terms of marketing. Can you come help? And so I did. And then we got married two years later, and now we have two kids. And so a lot of times, like, if Scott and I both want to participate in a conversation, it's...

We have to decide who stays home. 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. I feel the same way about her. Scott, your voice is more relevant. I don't know. You got away with words. It probably depends on his confidence level is probably lower.

Well, but then, yeah, I don't know. I can see both sides. It depends on the conference. Imposter syndrome can creep in from there, right? That's why I backed that off a second because I thought, well, maybe not. No, because I get really bad imposter syndrome around, like front of you, right? That's why I backed that off a second. I thought, well, maybe not. No, because I get really bad imposter syndrome around, like, am I technical enough? Right? Like, I

don't actually contribute value. All I do is fix error messages and improve documentation. That's not valuable. Andrea's a much stronger presenter, though. Like, she, you know, her voice carries. I'm really quiet. Like, I have to have the mic, like, up my nose practically. Yeah. As Jared turns the mic towards my face. So, yeah yeah it's

but when there's so anyways you don't have to make that choice right and then for example like gunner like he said just be mindful of how like these are biases where you know women are typically note takers so just be mindful of that right and you know as you go throughout the day and small little things like that have made a huge, huge difference in my ability to feel not just that I am welcome here, but that it's like I can continue to be here. So, awesome job

to the Sustained organizers. There you go. Shout out to all the organizers. Any last thoughts? This has been a great conversation. I think we should, I think I need to come on your Legacy Code Rocks and we can just talk Legacy Code. Oh gosh, yeah. It's so much fun. We're always looking for

folks who are interested in being guests. So I know that there's a lot of folks who are on both. The changelog is on their feed. We listen to it. You listen to it every night when you do the dishes. Yeah. I listen to the changelog while I do the dishes.

Well, you might have to hear your own voice. What the heck? Oh, this episode's terrible. It'll be all good. As we all self-criticize. So very cool. So LegacyCode.rocks is the podcast. Yep.

Yep. Corgi Bites. 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. Very cool. And then there's 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. Yeah.

And then we also have like a weekly mastermind group that's kind of like a what's that it's kind of like a virtual meetup okay basically where um i'm almost always there and then whoever shows up at a given time what do you guys talk about whatever the people who show up want to talk about so it's very much a kind of just a free form meetup kind of style um and there are people who come in lurk and just listen or like turn off the cameras and mute their microphones and just listen to the conversation. Maybe we could start recording them. That might be content to be worth sharing. I was going to say, it sounds like a podcast to me. So sometimes we'll do some group pairing on like different projects, like, you know, different techniques.

It's really, you know, whatever people talk about that they want to bring sometimes we've had people go like really struggling with how to solve this particular problem and then we'll help that person with it it's yeah so it's neat yeah cool well scott and you're thanks so much for joining us yeah thank you all right thanks for tuning into the change love this week if you enjoyed the show share it with a friend. Rate us in Apple Podcasts. Huge thanks to our friends behind Sustain, Justin Dorfman, P.M. Mancini, Chet Whitaker, GitHub for hosting it,

and the many others who made that one-day conversation possible. Also, huge thanks to our sponsors for making this show possible, Hired, Bugsnag, and CircleCI. our sponsors for making this show possible hired bug snag and circle ci also thanks to fastly our bandwidth partner head to fastly.com to learn more and we host everything we do on linode cloud servers head to linode.com slash changelog to learn more check them out support the show this show is hosted by myself adam stachowiak and jared santo it's edited by jonathan youngblood and the awesome music you've been hearing is produced by myself, Adam Stachowiak, and Jared Santo. It's edited by Jonathan Youngblood. And the awesome music you've been hearing is produced by the mysterious Breakmaster Cylinder. You can find more episodes just like this at changelog.com or wherever you get your podcasts.

Thanks for listening. Thank you.