Okay, now I'm recording. Richard, tell me your full name.

My name is Richard Littauer.

And you're with Maintainer.io.

Maintainer.io is my main thing at the moment, yes.

But what I wanna talk about is theuserisdrunk.com...

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.

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. It's a non-sustainable business model.

So would you actually become intoxicated and then peruse websites for money?

Yes, and there's videos online...

Did the intoxication actually aid in your ability to suck at using the website?

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.

It turns a hobby into a job really fast.

It does.

So tell me about this Maintainer thing you're doing.

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.

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?

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.

\[04:04\] Sure, so it's like a consulting situation.

It's like a consulting situation, yeah...

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 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.

Cool. So you just kicked that off recently, right?

Around two and a half months ago.

Two and a half months ago. How's it going so far?

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.

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... You know, sharing that sort of energy.

So you have a vested interest in seeing open source sustained, of course, because you're super invested completely into that.

Yeah.

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?

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.

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?

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.

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 pseudo-code, pseudo-documentation.

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."

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. I'm a big fan of a lot of high-level decisions, like Go's decision to have a formatter, so you just get rid of a lot of the issues that you have in other languages, like \*coughs\* JavaScript... \[laughter\] 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.

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\]

\[08:06\] I don't mind which god you worship, you know...? It's alright...

It's objective now. People who use tabs make less money, so it's like the final say on the debate. No...

Let's put a DOD file in your repo to automatically convert them and move on...

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?

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...

One thing I noticed when I asked you for examples, you gave Node, Hoodie and npm, and these are organizations...

Yup.

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...?

Yeah, I really like Sindre Sorhus' way of doing things. I love how they're using an [AMA](https://github.com/sindresorhus/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...

Yeah, small in terms of he has small projects, right?

Yeah, exactly.

Often times he's the only person who has commits on those projects.

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.

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\]

Yeah, good for him.

He just says no every time. I feel like he's a person who really knows who he is... Which is cool.

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 --

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! I've been at Hacker Paradise three times, I love it.

Really? That's awesome.

It's wonderful.

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.

In the past two months I've worked from Reykjavík, Ireland, Edinburgh, Glasgow, the Highlands, London, Berlin, San Francisco and Brussels. \[11:51\] 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.

I don't even know where that is...

It's the Northern-most human habitated place in the world. We have a JavaScript conference there in a church, because why not?! \[laughter\] He has an npm package called Geopackage, which basically -- everytime you push something to npm, it will tag your geographical coordinates, and I'm having a lot of fun with that.

Oh, nice. Very cool. So you have your own little map that you keep, with places you pushed from?

I have yet to actually make that map work, but knowing that I could makes me pretty happy.

Right, it makes you feel pretty good. \[laughter\] 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, we're happy to.

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.

\[13:30\]

So Karthik Ram, here to talk about your open source project. Tell us about it. What's it called and what does it do?

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.

When you say "reproduce" their code, 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 this supplement", and I would run the code and nothing would work.

I see, so you were taking code from a research paper and trying to execute it.

Yeah.

Gotcha. And it's failing.

Nothing works...

\[laughs\] That sounds suboptimal.

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.

Okay. And that was five years ago.

Five years ago, and fast-forward to now, we have almost four million dollars in funding...

Wow.

...we have a staff of about seven people, we maintain 150 modules, we train people and we build community.

\[15:57\] How did you get that done? In a nutshell... \[laughs\]

Magic...

Yeah, exactly.

Just bootstrapping this thing one thing at a time.

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...

The things that worked out for us was we built really tight software...

What do you mean by tight? Simple?

Simple, robust, well-maintained...

Good. \[laughs\]

...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.

How did you get other people to use it initially?

Twitter. So we were tweeting things throughout -- 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?" 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.

Just like that?

Yeah.

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. So you 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. Other scientists who have a burning need for something write software and contribute that to our suite.

In like a plugin style, or what do you mean by "contribute to your suite"?

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.

You're making it sound very easy.

It's not easy... \[laughter\] We've been riding a struggle bus for this whole time...

Riding a struggle bus... What does that mean? 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, 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 wanna 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 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.

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?

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.

\[20:17\] 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?

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.

So you're always going back to the well of foundations that you've been relying upon...

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."

Yeah... Is that like your new idea, or have you made those efforts?

No, that's our new idea.

Oh, it's your new idea; you haven't tried it yet.

No, not yet.

It sounds like that's a good idea.

Right?

\[laughs\] Yeah, exactly.

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."

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?

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.

So if other people were 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.

Yeah... Specifically in research and science?

No, just in open source in general.

Everywhere.

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.

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.

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.

Okay. Progress on that?

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.

\[24:00\] 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?

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.

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 a review with reviewers.

Like code review?

Yeah. It's not even -- it goes beyond code review; they review your code, your license...

So this isn't software that's coming into your system, this is anybody's software?

No, it's software coming into our system.

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?

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.

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 software comes out much stronger, and by the time we accept that into our suite, it's a fantastic piece of software.

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?

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.

I think the best solutions today are still computer-assisted humans. Reduce the burden as much as possible, but keep humans involved.

Humans make a huge difference.

They sure do... Until our deep learning overlords have learned everything they need to, for perfect software. \[laugh\]

Yup. I'll wait for that day in my self-driving car.

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.

Thanks for having me.

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.

\[28:09\]

I'm ready when you guys are. You guys look comfortable.

Yeah.

Cool, so I've got Andrea and Scott, with Corgibytes, joining me.

Hi, thanks for having us.

Hello. It's been a long time coming.

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...

We hung out. You gave me a ride at the airport when I was speaking at...

The Nebraska JavaScript Conference a couple years back.

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...

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?

It's very similar to the Changelog, I think. We've really modeled ourselves after you, and I'm not lying. \[laughs\]

We're flattered.

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.

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?

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.

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...

Nice...

\[31:52\] 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.

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...

Yeah, and I was speaking at that, and a lot of other people were, too...

It was Llewellyn Falco, Woody Zuill, Arlo Belshee a lot of folks who just are...

Michael Feathers...

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.

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.

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.

Yes, that's exactly what we call what we do at Corgibytes - we do software remodeling.

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?

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.

So Corgibytes could be a thriving consultancy - is that what you guys consider yourselves? Or a software firm...?

I think consultancy.

Consultancy is fair.

I sometimes say "a group of people who are passionate about software maintenance and modernization."

Oh, sales team right there. \[laughter\]

I don't know if that's a consultancy or if it's a product team...

That's why you always let Andrea tell people what it is... \[laughter\] Scott's like, "Yeah, we're a consultancy..."

Yes, that's why she talks a lot more than I do.

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.

\[36:01\] 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...

Yeah, I feel like we have the inverse of what a lot of technology firms have, where...

Which we were not expecting.

You have a lot of people wanting to work for you...

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.

Yeah, that's interesting. A good problem to have, but still a problem. \[laughs\]

Yeah, exactly.

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?"

Yeah, specifically fix bugs on 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 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.

Yeah, like the tree view in Atom, kind of...

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...

Right. So that wasn't there and you thought, "That's a bug, I'm gonna add it."

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.

That's really interesting. So you started off with "How can I make a living fixing open source bugs...?"

Yeah, and I think we found that--

That you actually can't do that. \[laughter\]

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...

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. 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."

Oh... You should come hang out with me. \[laughter\]

Or make them helpful user error messages.

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...?"

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.

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\]

Right.

\[40:10\] 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."

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.

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.

You're a saint. \[laughs\] Who's this guy? Who's gonna go into some projects owned by owners and start like fixing stuff?

That's what he does, yeah.

I'll first try to reproduce it, right?

Sure.

Like, this doesn't look like it's an issue anymore. At least leave a comment.

"Would you like me to clean it up?"

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...

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.

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."

I wanna go work for him already. \[laughter\]

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...

It's like arbitrage that needs to happen.

Yes, what is that thing that is preventing these two needs from happening and working together?

Yeah, where's the virtuous cycle that would have those benefitting each other?

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.

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.

Nice.

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.

\[43:56\] 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.

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.

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 --

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.

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 the 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 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.

How did it pan out?

The change was accepted...

Okay... The paperwork went through...

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.

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.

Right. Like, we've had to build a small gem once.

Yeah, we built a couple small gems to fill a crack like that.

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.

\[48:07\] 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 --

And I've had a couple clients push back on that particular point as well, or at least ask for clarification.

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.

Exactly.

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.

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.

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.

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--

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, so...

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.

The impostor syndrome can creep in...

Right, that's why I backed that off a second, because I thought, "Well, maybe not."

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.

\[laughs\] Well, that's not viable...

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\]

But when there's childcare, we don't have to think about it.

You don't have to make that choice.

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.

Yeah, that's awesome.

Awesome job to the Sustain organizers.

Yes.

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--

Please do! Oh gosh, yeah... It's so much fun.

Yes, we'd love to.

I'll just nerd out with you guys.

Yeah, that's the show.

\[52:06\] 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.

Yeah, I listen to the Changelog while I do the dishes.

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...

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 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\]

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.

What do you guys talk about?

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.

I was gonna say it sounds like a podcast to me. \[laughter\]

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.

Very cool. Cool, well, Scott, Andrea, thanks so much for joining us.

Thank you.

Yeah, thanks for having us.