Ep. #16, Project Maintenance with Robby Russell of Planet Argon

Patrick Woods: Awesome. Robby, thanks so much for coming on the show today.

Would you mind starting by sharing a little bit about who you are and what you're working on?

Robby Russell: Yeah. So I'm Robby.

I'm the CEO and co-founder of Planet Argon, we're a Ruby on Rails primarily consultancy.

We've been around since 2002 and I've been working with Rails since the beginning of 2005.

So for a few years now.

And outside of that, I'm also known as the creator of Oh My Zsh, as an open source project.

And I just wander between running a business and being an open source contributor and musician and I'm just a nerdy person in general, I suppose, in some ways.

Patrick: So here at Orbit, we're a Ruby on Rails shop as well.

I'm curious about your perspective just on the state of the Ruby on Rails community and ecosystem today.

Robby: Yeah. That's an interesting question.

Obviously, I have a biasness towards it because I've been using it for such a long time.

And I think one of the things about Ruby On Rails that's been hard for me to stray from, I suppose, is that when I got introduced to it, I had been working with a number of different programming languages just prior to that, like PHP and Perl and did some Python work, and worked in .NET, a couple of different companies and doing some freelance stuff for a couple of years as well.

And I felt like when Ruby on Rails showed up basically on my front door, and like literally on my front door.

It's an interesting story, we can get into that.

But it just had this like, Aha moment. I was really excited at the time about--

I had just recently picked up one of Martin Fowler's books on refactoring.

And we started to get really excited about doing that with some PHP projects that I was working on.

But when I saw DHH had implemented Active Record in Ruby, and I hadn't really used Ruby outside.

I've heard of it a few times. I was like, "I love this way of interacting with the database."

So nice because I had been using PostgreS.

My previous company, and I worked with my boss at that company, wrote the O'Reilly book on PostgreS.

So I was indoctrinated to PostgreSQL really, really early on in the community, which ends up being part of the reasons why I probably was moderately well-known blogger back in the early days of the Ruby on Rails community because I was the PostgreS person.

It was like DHH was always talking about MySQL and I was like PostgreS is better, trust me.

And I don't know that I won that war outside of PostgreS is a much more popular this days, but that's a whole another story as well.

But I felt as a software developer, I was able to accomplish a lot more and it made a lot of decisions for me.

And I felt like prior to frameworks like Ruby on Rails, there was a lot of decision fatigue, and you work on every project and usually, if you get the benefit of starting a new project, then it was like, okay, well what library am I going to use and PHP is going to interact with the database.

What's the scheming going to look like?

What am I going to be using on the View Layer? There's a lot of things to decide.

And every project I would inherit, was drastically different depending on who built it.

And so Ruby on Rails provided a set up conventions and made a lot of decisions for me.

I was like, "Okay, I don't have to make those decisions, I like the decisions that are being made in here. I had maybe a few disagreements on a few things early on. It was hard for me to--"

I was really nervous about relying so much on the ORM-- Active Record.

I don't want to bore the audience too much on the too low level, but I had worked in this in previous environment where we use a lot of databases constraints, and a lot of stored procedure type logic in the system.

So if you did something like a mark a record in your database to say inactive, you could set up some triggers to update a few other associated records and other tables.

And that was magic, PostgreS handled it all.

And then when I moved to the Ruby on Rails role, those first six to 12 months, I was really struggling.

I always be like, "So Active Records going to do that for me, maybe, kind of, how confident do I feel about that?"

Anyways, once I got past that and I started to really embrace just some of those basic things that were bundled in Ruby on Rails, we didn't have things like database migrations back then, even in Ruby on Rails and other things that people really like about Rails that implemented over the years.

But a lot of that stuff wasn't even there in that first year or so working with that.

But I felt like I was a much more efficient developer.

I was delivering things quicker and it was exciting and it was new and that was part of it.

So that explains why I switched, and got really excited about for this first few years.

And it was exciting, new technology.

They were really on the cusp of doing cool stuff with like AJAX back then.

And it was just like pushing things forward. And I think that felt really healthy.

So fast forward to today.

So I think for the last four or five years, I felt that Ruby on Rails has done a good job of continuing to improve the stability of the platform, the speed, performance, things like of that nature.

But we're up against a lot of new stuff. We're back into decision fatigue era.

I don't exactly know when it happened, but I do feel like most people starting a new project, there's a lot of options about like, well, how much are we going to do with our applications?

How much are we relying on these cloud platforms that have all these cool Lambda functions and how can we string together this application with these other systems and we've got microservices?

There's a lot of decisions to be made.

And I think if you are a really large organization that has a lot of people that can think and become master or just have a really deep level of understanding of those different tooling and platforms out there, then you could take advantage of.

But for a lot of companies, a lot of teams, a lot of small earlier startups, they have a small team.

I still believe that Ruby on Rails is a really good platform for a small team to accomplish a lot and help you start getting into that dealing with those scaling problems that Rails has been notoriously pointed out as like, well, it's too slow, or once you get to a certain point, you're going to need a break this model up or something.

I think there are a lot of patterns we can embrace now that allows Ruby on Rails to still flourish in that environment.

But it's not the new glamorous stain on the block.

When we started using Rails originally, I was having to explain why Rails was viable to someone that had been like, "well, Java has been doing this. This is like we were using Java servlets and all these, I can't remember all, JSP and all these other different things you could use back then. And we were fighting what we thought was like the old guard. And now Ruby on Rails is trying to defend itself as the old guard, even though it still feels like a pretty clean robust platform."

I think Ruby on Rails has set the example for a number of years.

The thing I would say, and I was listening to the DHH in an interview you did early, a couple of months ago on my way over to my office.

And I was thinking a little bit like the thing that I would be most critical of Ruby on Rails, is I think it suffers from, in a weird way, its own success, in that a lot of the people that were early adopters of Ruby on Rails, either continued to be early adopters and kept going off and exploring new technologies, or they created a really profitable business, or create some sort of business.

And they're busy tweeting and writing articles about running a business, having employees scaling their business.

You don't have the CEO of Shopify talking about how great Ruby on Rails is anymore.

There's a vacuum now I think in the community.

I'm not having enough of those excited, energetic people that are adopting it and talking about all the new things you can do it, because it's been around for so long.

So I think there's a marketing branding problem within the Ruby on Rails community.

And I think there's ways to the community can do it.

The Rails website hasn't been updated in a number of years.

And that's okay. It's just, I think the last time I even looked at it, it was like still had a Ruby on Rails 5.0 tutorial on the page.

As an example, I'm just like, that's just not getting this sort of attention because even DHH is focused on running his business, and growing and they're writing books about other things.

And so we're just missing out on some of that early excited evangelism that I think a lot of these new technologies do benefit from, because someone's going to be the first person to go plant that new stick out and be like, "Look what we're doing over here."

So it's a battle of ideas and patterns and approaches.

And I think Ruby on Rails can excel again, but it's going to take a conscious effort by people to step up and share and talk about it.

And maybe me talking about here is one way of doing that, but it's just, I'm also not trying to work on a lot of new starter projects for my company.

We like to take over existing applications and make them better, is typically what we're working on.

That the only type of projects, but that's what we've been known to be doing for several years now.

And so, that also doesn't come across as super glamorous, but I also think that's a discussion the community, as a software development community, I think needs to have in terms of most of what we do as software developers is taking care of and iterating on existing software projects, not getting this other brand new shiny project.

So, it's great that teams do get those opportunities to do that when they do but most people joining a job, that's not going to be your first task is to spin up a brand new application.

You're going to start working on an existing project that's already proven some value in the company can now hire people to work on it.

Patrick: Yeah. What do you think about the role of maintenance versus new creation in terms of code and infrastructure?

I'd love to hear your perspective on balancing out new creation versus maintaining the systems that are already there.

Robby: So I have a podcast called Maintainable, and when I talk with people about dealing with the challenges related to technical debt and legacy code, and anecdotally, it seems like a lot of teams are trying to aim for--

Once they get to a certain point where they have a large enough team, and they're outside of that early MVP, constantly pivoting mode, there are trying to spend approximately a third, earmark about a third of their developer time to work on improving the existing applications and platform to basically iron out the issues, the things that are causing them some friction, slowing them down, so that when they're using that other 70%, they're being more effective.

Because I think a lot of teams might keep focusing so much on shipping new things, and maybe cutting corners at times to get those things out.

And I think that's definitely okay, as long as there's a process for when you decide to how to go about prioritizing, cleaning up a little bit along the way.

So it seems like the teams that have done a good job of making that part of their ecosystem, where the developers aren't needing to have big laborious debates with the product owners on prioritizing and dealing with technical debt or maintenance type work, that may seemingly not have much of value to their customers.

It seems like they're trying to approximately earmark around 30% of time to that sort of thing.

I think what I've also heard is that, and my take is I don't think you can separate that work out from different teams.

If you have just a maintenance team, that's all they deal with.

Maybe if there's some rotational thing, but I think if you're someone that's shipping code and you're not also responsible for coming back and cleaning things up or refactoring a little bit of what you had worked on, then I think that can cause a different problem in organizations where like, "Well, it'll be someone else's problem."

And then that might cause some issues between.

Because I feel like by doing that maintenance work, those refactoring type tasks, you gets better at building the new stuff because you're like, "Oh, right. I don't want to make that mistake."

Because there's a lot of companies that might take that strategy and be like, "We're just ship, ship, ship over here."

And then we add some other people to provide support, and refactor behind the scenes.

It shouldn't be seen as support work as much as it's like.

That's really important work to make things more efficient.

And it's really, it's not just about our making the code better, it's about making your own life as a developer better, so that you can feel more efficient.

Because once you get to the certain point where you've got too much in your way and everything, like if your CI pipeline takes too long or your tests are super brittle and flaky, then you have a different problem where you stop trusting the system that you're a part of.

And then when people leave, and come and go, then it becomes even more challenging to ever really get back to that state of feeling like you have a cohesive stable platform that can survive team changes, which are inevitable at some point or another.

Patrick: What are some ways you've seen companies or teams build that culture of maintenance and willingness to do that type of work on a consistent basis?

But what are some practical things you've seen that work well?

Robby: I think if you are a team, a lot of the people I've spoken to about this seems to be that they're when they have a CTO or someone higher up in the business, like maybe one of the co-founders had that technical background, they seem to just try to bake that and really on and think it like, this is important to us.

I say that with some caveats, that I've also talked to a lot of companies of that type where you got the CTO of a company who's day-to-day working in and out of code all the time as well.

So I'm like, "Well, you're at a different point than you will be like in five years where you probably won't be working in code. What will your culture looks like then?"

Because sometimes those CTOs that are coders might be save-the-day type people as well, and then they go in and deal with all the messy stuff because they don't want to bother their other developers with those other things.

So, that can create some problems too.

But I think, if you have that sort of formula, if you're falling in say, some sort of, say Scrum or something, type of approach where you've got a product owner and you've got your software development team, they're all collaborating.

And then that product owner is knowing that we're got it, they're advocating for taking on debt to get addressed.

Because they've heard it and they've listened to it.

So I think, those seem to be healthy teams where those people seem to understand it because the engineers on that team have done a good job of explaining the business value.

I think if anything that developers struggle with is, communicating how is this going to help the businesses?

This isn't just making my life as a developer better, because I think when they focus too much on themselves and that's not the product owner's responsibility is to make sure that you love your job.

It's that they're shipping the right things to the customers for the product.

That's an important part of it but that's not their primary focus.

That needs to be your responsibility as a developer, is to be looking out for yourself.

But you think you need to be able to connect that back to the like, why is it so important to you?

Because you want to be able to deliver more value and more consistently, or at a higher velocity, the number of features and updates that you're making that the customers care about.

Or you're making things faster, which is better for the end users, things more efficient and you're removing some of the things like, "Oh, this areas of the application is very fragile at times," that causes maybe there's churn in your customer retention because of that.

So there are ways that connect those things and, or it takes too long for us to get feedback from our clients where we're shipping on a new feature to, like our test users because of our CI pipeline takes too long, or we've got a really brutal test, or it needs a lot of manual QA because that's just the way we're set up at the moment.

So there's a lot of those different things I think combinations that come into play of which, it seems like the teams that talk about it and require it to be part of the process, and then figure out how to think about it on the system level.

And so is part of their workflow and ethos is important.

I think it's the teams that are like, "One day we'll eventually get to have that conversation," are the ones that are probably struggling with it.

And you may or may not be able to figure that out on your own, or you might need to go maybe hire a consultant or someone to come in to help you figure that out.

Patrick: Yeah. So you're involved in a lot of stuff.

So, Planet Argon, Oh My Zsh, your band of The Mighty Missoula.

Thinking about all of those areas where you have impact and do work, I'm interested in your personal heuristic for deciding when to do something new versus when to work on maintaining something that's already there.

Robby: That's an interesting question.

So, I'm not a software developer that loves to code.

I don't love code for the sake of writing code. I am interested in the output of it.

And so, I always share this story that, I feel like the number of different ways that my dad failed to get me excited about becoming a software developer when I was a kid.

He works in IT, he still works in Silicon Valley in hardware.

And he's like, "You should get into software."

Since I was five, he's been advocating. I'm 41 now.

So, he thinks he convinced me to do it eventually, but I was not excited about the idea at all.

And I think it was hard for me to understand why software could be exciting.

And I still feel that way to some rookie.

I only learnt to write software because I wanted to throw some things on the internet, like "Oh, I want to sell stickers on the internet."

So I'm like, how do I make a web page so I can allow of people to place orders online?

So my very first e-commerce site back in, I think it was '97, was a site where you could go, place an order for a sticker, you can buy it.

You can actually do credit card processing.

You make a request, and then I would send you an email that says, here's where you send a couple of dollars to.

And it would save their information into a CSV or a text file basically, that I would FTP into the server and go look at and say, "Look, I got a couple new orders."

Mail orders was the thing. I was into Zenes and Punk music and selling stickers for Punk bands and stuff like that.

That was what I wanted to do.

And then I had a Zene as well, and I wanted to put the content up online.

So I figured out how to make my page, where you can have all the different pages and show our articles and photos and stuff like that.

So I learned some basics of HTML, CSS and a little bit of scripting to accomplish those things.

And I'm like, "Ooh, this is interesting. I can use this for other people's projects as well."

But it never came out like, "I want to learn how to code. What can I..."

"You do this way."

It's more like, I want to do this thing, I guess I need to learn some code because I can't afford to pay anyone because I don't have any money to pay someone to do this.

So I had to figure that out myself.

And so that basically became a trend.

Eventually, I had some doors opened up where I got a job working and doing some coding.

And here I am many, many years later, a couple of decades later having written software.

And the funny thing is Oh My Zsh, another topic I think we're going to talk about is, when it comes to swag and things for the community is thinking, I now have an open source project, that's all stickers.

And it kind of like full circle, like I always wanted to sell stickers, I wanted to have a sticker company.

And now I'm selling stickers almost every day on the internet because of some software I wrote.

And so it's kind of weird way to go about doing that, but I succeeded there.

So, but when I come back to your original question on the, when the new versus when just to maintain something.

So something like Oh My Zsh, the funny stories there is like I only created it mainly to encourage a couple of my coworkers to switch from Bash Z shell.

Because when we were pairing on some code, they would be using Bash and they'd be trying to write something on their computer and was like, "Oh, I don't have these shortcuts in here."

And I'm like, " Ah, come on, just copy my Z shell configuration over here."

Your life will be better, I promise. They're like, "Aah, I'm skeptical of using this copy paste of all his weird recipes are obvious found from his peers in the developer world back then."

And so, after a long time of trying to figure out how to encourage them to do that and failing miserably, getting them excited to switch from bash to Z shell, because some people really want to understand how things work before they use them.

I am not that kind of person. I'm like, "Oh cool, this will get me part of the way there. Great. I'll do that and then I'll figure it out from there."

I don't need to understand all the inner workings or everything for me to feel comfortable.

And I know there's people that do appreciate that.

So I ended up creating a Git repository one weekend thinking, "Okay, I'm just going to toss my configuration file, because I don't immediately understand what it all did either, because I was copying and pasting from prior to GitHub, having like adjust, we had Patsy and a couple of other sites where you could share some code snippets online. And so people would share like, here's some Z shell configuration things, and I would copy paste things and I'm like, "Oh they're cool. It may change my terminal prompt a little bit, of here's some cool shortcuts."

So I tried to document what was in my file because I had accumulated things over a couple of years of using Z shell.

And as I was doing, I'm like, "Oh, these are like-minded things, I'll stick these over here, and reorganize the file."

Like, "Oh, why don't I just put these in separate files?"

I'm like, "Oh cool, I've got like a collection of functions and I've got some aliases in another file."

And I'm just like, "I'll just load them all into one, just clean this up a little bit and have a nicer directory structure."

I'm like, "Oh, I'll just slap on a name for it."

And so I had another project called, Oh My Science, which was like a fun, little Twitter thing that I had worked on.

And I just kind of like, "Oh, I'll just call this, Oh My Zsh."

I put a README and throw it up in GitHub, and then on the following work day, I share with my coworkers.

They all installed it because it had the instructions and a little bit of documentation.

And then within a day, someone was like, "Hey, I want to change the color of my prompt."

And I'm like, "Why?"

And they're like, "Because I don't like the colors you linked, but I have the best prompts."

Like what are you talking about? Like, "Okay, how do we do that?"

So I'm like, "Oh, I guess what if we come up with the idea for themes."

So, all right, there's like a Carlos one, there's a Gary one and there's an Alison one and there's a Robby one.

We each have our own one in this directory for themes.

You can change the colors to your heart's desire and change the prompt.

That's how themes came about. So I didn't start off this project thinking, "Oh, I'm going to do this thing and share with the wider community."

It was like, "I just wanted my coworkers to install Z shell, so that we can pair and I would have all my aliases and shortcuts there.

So I succeeded. Now, there's a lot of people on the internet that have that.

So if we're ever pairing, I get that benefit I suppose now as well.

But that was how that started. It didn't have plugins, it didn't--

All the things that people love about Oh My Zsh didn't exist for weeks to months of when I first released it.

And, so I think it goes back to that scratching your own itch, but it wasn't even scratching my own itch.

I was just subjecting my coworkers to my preference for how to do things in the command line.

I don't understand how things make sense sometimes.

But anyways, so I didn't intentionally start something new there.

But when it comes to like having a band or running a company, I'm very nervous about starting pet projects, because I understand the long-term cost of it.

And I have a blog post somewhere, I guess on Medium or the Planet Argon blog where I talked about five or six different products that we created within Planet Argon, that we were going to release.

One of them was like a time tracking application.

It's probably the one that we spent the most time over a number of years working on.

We use it ourselves and we're going to take it to the market at some point.

And then I think it was about nine or 10 years ago, one night, was end of December, and I was like, "You know what? I'm killing this because I've looked at how much time we had spent maintaining it, and working on it."

I was like, "We're not going to go up and compete with Harvest."

We're not that company because it's just, we're a really good consultancy, we do this really well.

We're trying to figure out how to become a product company.

And I'm like, "This is distracting us as a business."

And so I was like, "I'm killing the project, sign up for Harvest."

We switched over. Nobody's complained.

And we've been more profitable as a business, I think since we made this decision.

So, whenever the team wants to talking about new fun projects, it's more like, okay, well what's the long-term cost of that going to be maintaining it?

We have a couple of internal projects that we use to do things like sync our time from Harvest to Jira tickets and stuff like that.

We've talked about maybe releasing that at some point, but I'm like, "I probably rather just open source and see people want to use it."

I don't want to be responsible for being accountable to anyone else for these projects.

So I think about it when projects, are we being accountable to ourselves, is this doing something to help automate something internally?

Or is this going to benefit? It's not something we're going to be taking to market.

So let's think about it from an open source perspective or something like, how do we share?

But even sharing something on open source comes with the consequences of being responsive and being good stewards of that code, as I've learned from starting Oh My Zsh, and seeing what happens after the project grows at the rate that it did and being like, "Well, this is way bigger than what I could handle."

So, I don't know that I have a really succinct answer to that outside of, I'm very nervous about starting new projects because I like to just take care of the ones that I've already started out on.

But there are times where I'm like, there's curiosities that I have, you mentioned the band as well.

I knew that, as a musician, I was feeling like I was in a lull for a really long time of not feeling inspired or I didn't feel like I was growing as a musician because I didn't have people to get real time feedback with.

And so there was a point where like, okay, I have all this equipment and either I'm going to get rid of a bunch of my music equipment because, I'm not going to be a musician like at the way that I thought I was, and that's okay.

Maybe I just need to have all this gear stop taunting me.

I'm not a gear junkie, I'm more interested in what I can do with the music.

Then, it's another part of like, the music world is not that different than the software world in the sense that, you can meet up with some really talented software engineers at a conference over lunch or something, and be like, so tell me a little bit about yourself.

And then they can't have any conversation that doesn't involve getting really low level into the code.

And it's like that in the music world as well, where I'd be like, "Hey everybody, I'm not like the greatest musician and I not a gear nerd, but I can't get away from having conversations about the tooling and what the new cool thing is."

And it's like, it's the same conversations, just about a different thing.

Patrick: Yeah. It reminds me of the quote that I've got a butcher around this concept that, when art critics sit together, they talk about form and style and theory.

And when artists get together, they talk about where to find cheap turpentine.

Robby: That's funny.

Patrick: Well, when it comes to tooling, the conversation around musicians talking about gear, and engineers talking about low level stuff.

I'm curious about your own philosophy of tooling.

And you can either answer it in terms of when you're creating tooling or when you were assessing tooling to use.

So I'd just love to hear what goes through your head as you're making those decisions.

Robby: Sure.

So, one of the benefits of running an agency is that I don't end up having to make a lot of tooling decisions on a day-to-day level, because I'm not the one usually coding on the projects at that low level on a regular basis.

But there is a-- The thing that we talk about internally with our engineers and we were navigating things, because let's just take the Ruby on Rails community as an example.

So we're using Rails as a tool, that's a no-brainer for them.

I don't think it's always what's makes sense for every type of scenario, but for a lot of types of projects that we talked to, it makes sense for.

And we've also helped companies escape Ruby on Rails to switch over to something else.

Like, "Oh, you didn't need your own e-commerce application using all this custom Rails."

You're probably fine with something like Shopify.

Let's help you get out of this and just something that's-- Someone else taking care of this, you don't need to spend all that money anymore.

So in that kind of capacity.

So I don't think we're definitely not all the time with that.

But when it comes to say, libraries, especially with open source, third party libraries like Ruby gems, in our ecosystem and in JavaScript and NPM modules and all those things as well.

One of the things that a lot of people are concerned about with, is tackling on debt by being reliant on someone else's code and not knowing how that's going to pan out.

And so there's a couple of different ways that ends up happening.

So you use a Ruby gem that say, integrates with your credit card company or everybody's using Stripe nowadays or whatever.

But let's say you're using some sort of Ruby gem and you do that today, but fast forward five years, is that Ruby gem still getting updated as Ruby is updating the syntax.

And as Rails API has changed over the years.

And how compatible are those continuing to be?

Oops, someone created a different version of that and now that person that was working on that is like, "Well, I'm not going to keep taking care of this one any one bit, well, I'm no longer supporting this one because this other one's now a good replacement. And that's what I would recommend you switch to."

Well, if you were keeping up already with what that developer was doing, and then you're like, Oh, you're finally getting a chance to go through that upgrade process, like with Ruby on Rails.

And you're like, "Oh, this Ruby gem isn't going to come with us. Seemingly they're advocating that we switch over to this other one."

So now we've got another project, which is not-- We have to reintegrate with a different Ruby gem, or should we have written our own in the beginning?

And then there's people that will argue for that.

But I'm not a big advocate for that because one of the things that's so great about open source is that, you can literally open up the source and then--.

So I'm always more of an advocate for, if the migration from one gem to another isn't too much of a hurdle, you can always fork that existing Ruby gem you were working on, and just at least assess the situation and be like, "Can you take over your own version of that gem?"

And be like, "Okay, we're going to update the syntax to make a compliant with the new version of Ruby and/or deal with."

So I'm like, "Is this something you can maintain if that person stops maintaining it?

So I think, because what ends up really happening, that's not just one Ruby gem when you get to make any of that upgrade.

You're like, Okay, we're going to make this jump in Ruby on Rails, so that's got two projects there, Ruby and Rails, and every one of your Ruby gems is potentially not going to gracefully update without needing to figure out what versions are, that aligns with and/or potentially needing to migrate away or fork them.

So that's becomes like, okay, now you've got 20 problems all of a sudden, and that becomes a barrier to moving forward, which means you end up with a lot of companies that are putting these on hold for a little bit.

Like let's put this upgrade project on hold for now.

We'll come back to it because this is a bigger rabbit hole than we thought it was going to be.

And we have those conversations with companies so often.

And so it's hard to get away from that sort of problem because the problem is exponentially seems to become more and more of a thing.

You're like, "Wow, then we're going to do that upgrade, but then when we got to the next version of Rails and now we're three or four versions behind, and that's a problem."

So back to one of the earlier questions about where Ruby on Rails is the community.

It's been nice to see that over the last, I think two years, there's been a lot more conversations within the some of the large companies like GitHub and Shopify in particular, spend a lot of time talking and sharing code for how they've improved their upgrade process because they had to go through that process themselves.

I know GitHub had a really, they had a large jump to go through and it took them a long time to do it.

And so we know that large companies like that are dealing with that.

So a small team that's seemingly like, I don't know that we have time to update and deal with 20 different Ruby gems and to navigate all those things stuff, and then all their dependencies as well, because it becomes this cascading problem.

So you could argue that building all those libraries yourselves is better because then you're maintaining it.

But I would also then counter that with, but the code is open-source, you can make changes to it, you can refactor it, you can clone it, do whatever you want to it.

Even the moment when you first introduced the gem, you were like, "We're just going to fork this now and start making in hours, regardless."

It's like, this seems to be working and we can take it forward.

And so, I think there's this the benefit of like, well, they're taking care of it over there, but you can never predict it for gem or any third party.

Open source library is going to be around in five years or be supported anymore.

So there's that part of it. And then, so the other thing we talk about is, when we're looking at evaluating say, third party gems is to--

I'm always worried that developers are too easy to dismiss something because they see that there hasn't been a commit on that particular library in like two years.

What does that mean that there's not been any commits on like, say the primary, like main branch or something up on GitHub.

Does that mean it doesn't work anymore?

Or does it just mean that it's feature complete enough that it doesn't need it to do anything?

What is the goal? What's the function of that gem like?

And I've heard my own team say this over and I was like, "Well, that's no longer supported or doesn't seem to be actively maintained."

I was like, "Well, there's no issues or doesn't seem like any of the issues are like security issues or huge glaring bugs. It's like, it seems to be doing what it's supposed to do. That seems okay."

I've always jokingly said, Oh My Zsh has been feature complete since I first released it.

People wanted some new stuff, Okay. Well, is this more of like, we have a backlog on introducing new things.

Some of them are bug fixes and is the performance improvements, but a lot of is just like, new little feature requests, bells and whistles, additions to the plugins and themes that we have.

So I'm like, "Nobody's missing them," like they had already been around or they've been hindered, we just have--

It takes time to go through and be like, this seems like it's not going to break everybody's computer.

Sure, we'll ship this out with it. So sometimes it's still like Oh My Zsh will be quiet for like several weeks at a time.

And I'm like, It doesn't mean that it's not being maintained.

We won't go a couple of years without it because I think this is too big of a project but--

That's a general approach to at least libraries is.

I'm always surprised by how often developers will be a little resistant to taking on something that doesn't seem like it's been actively maintained.

And I'm like, "Well, it's just code."

It's not like, how many different areas of our own code base have we not needed to touch in a long time?

Does that mean it's no longer being maintained?

One of the things that's fun when I'm pairing, especially with junior developers or interns, is when they're dealing with a bug that may be related to a third party library.

I'm like, "Well, let's see what's going on in the gem."

And their inclination is like, go look on GitHub and start browsing in the library to go find it.

Like, go look there. I'm like, No, no, no. It's just open it up in your code editor.

The code is sitting on your computer right now, you can do a gem open, after you already have your editors set on the command line.

And it'll just open up that directory of it, the exact version that we're running and like, let's go in, we can inject some logging in here, we can put a break point type situation in here.

We can just like pry, we can interact with it right here.

Make changes to it and see what happens.

Is it actually the gem or are we making an assumption?

So you can do that right now on our computer.

So they're always like, "Oh, you can do that."

But it's like, it's someone else's code. I'm not going to like--

It's the world's code at this point. And this is why open source is so great.

So I'm always trying to just encourage you to like, don't be afraid of other people's code, in the same way that our team is always inheriting projects from other teams.

We can't be afraid of messing with code because that's our job.

Patrick: So thinking a bit about, Oh My Zsh, I'm curious in the path from that project being something you built just for your own self, finding product market fit pretty quickly with your teammates, but scaling it up to more than 120,000 stars on GitHub.

What have been the key moments in that path?

Robby: In the first few months of releasing, as I put it on my Robby on Rails blog, I shared it out there and then I had some peoples start contributing their own themes and a few plugins.

Because it came baked with like a handful of Ruby on Rails, specific things, were just like, if you install Oh My Zsh, you had these Rails aliases that even if you didn't use Rails.

But most of my network of people that were probably reading Robby on Rails was, Ruby on Rails developers.

But eventually someone's like, "Oh, I want to do something for Python and maybe Django or something."

And so I'm like, "Oh, okay." That's what created plugins.

I think Rails was one of the first plugins because I just moved everything from one file to another file called Rails.

And I'm like, "Okay, we have plugins now."

But in terms of these key points, August 2009 is when I first released it.

And I think I do remember in 2011, I remember the Spring 2011, I got asked to be on the Changelog podcast to talk about it. And I was like, "Oh, people want..."

There's enough interest that-- Like an Open Source podcast wants to talk about Oh My Zsh.

I'm like, "Okay, cool."

And then at the time I remember thinking, I go back and listen to that episode recently and I was like laughing at myself because, I had said that, my goal is to keep the number of open pull requests under 100.

It was like a goal at the time. I think right now we're usually hovering around 500 open pull requests.

So, that was like a goal back then. I'm like, "Oh, if got this, I'm figuring things out."

It's fun and I don't spend a lot of time thinking about it to be honest.

And it was always hard for me to try to figure out, attributed where people came from.

Because it was like, not everybody was a Ruby on Rails developer, and that was my network.

And I tweeted about it here and there.

I guess another part of it was that, I started Oh My Zsh, I created a Twitter account probably pretty soon after, because I was probably within a year or two of Twitter first coming out, and then GitHub coming out around that same time.

I think GitHub was early 2009 as well.

So I think it being like one of those early projects, and it was on there and I had--

It attracted people across software programming languages in a way.

And so I think that part of, I think was interesting.

So it was this new thing and I think the thing that really helped pick up steam was people that were using it, speaking at conferences.

And not that they were talking about Oh My Zsh, but they would get the question after their talk of like, "I noticed when you were using your terminal or you, your screenshots, like you had some color stuff going on and you had like, your get branch in your command prompt and like, how did you do that?"

They're like, "Oh, I use Oh My Zsh."

And so speakers at conferences were already part of maybe in the Rails community.

And then I heard from a lot of people that were coming out of coding bootcamps, like, "Oh," like they--

Years later we had interns coming in and they're like, "Oh, you're the person that made Oh My Zsh."

Like, "That was the thing they made us since on our first day. I had no idea that I'd be interning with you."

And I'm like, "Oh yeah, that's just fun coincidence."

And I would say this, and I know I always, I tend to be a little humble for my own good at times.

But I think there is, I did have a lot of fun on social media and blogging about it in terms of like--

I'm like this, whenever someone was excited about it, I would retweet them, I would give them some praise and have created Oh My Zsh with a way to have some personality in a way.

Like if you ever read The ReadME that in my personal opinion, some of my best writing ever is like the intro on The ReadME for Oh My Zsh, because I felt like it was a way for me to give it some personality.

I'm like, this is a community project, almost all of the code in it, all the plugins and themes were all community contributed.

This isn't Robby's project, even though for a long time, it was github.com/robbyrussellohmyzsh until maybe a couple of years ago when we finally moved into its own organization.

And it was always like, this is a community based project.

And so I think people felt like they could easily contribute to it because they saw-- So like we've had over 1800 people contribute code to Oh My Zsh, which is pretty awesome.

And plus there's over 500 open pull requests right now, maybe 20% of those are additional new people that had never contributed to open source before.

So I think it's a project that's been a low barrier of entry for a lot of people, even though Z shell and shell scripting isn't necessarily seemingly the easiest to get your head wrapped around, but it's also not that hard to wrap your head around.

So I think a lot of people are like, "Oh, I can contribute some aliases or contribute to a new plugin."

Or like, "Oh, this is a new CLI tool that's available on Homebrew, I wanted to make something like a plugin for that."

There's a pattern like, "Oh, I see what someone else did. I can create a new one for this new thing and contribute that back to the project."

So, that's always been pretty great.

We've always been very receptive to new plugins for better, for worse.

Some people would also argue that it's become too much of a monster because of that as well, but I think it's been fun for that.

So I think that's part of it, but I think over the last five or six years, it's just comes in these cycles where I keep thinking like, "Okay, maybe another year or two of this."

And then people are going to be using something else like there's someone's going to come with a much better system like the Fish.

And there's like, Oh My Bash, which is basically Oh My Zsh inspired for Bash.

But then this last year or year and a half or so when Apple decided to make Z shell the defaults, people were like, "What is this?"

And then they searched for Z shell, and Oh My Zsh has seemingly has really good SEO.

A side little note there is, I know for a fact that there are people that are involved in the base core Z shell project, that loathe Oh My Zsh.

Because it's seemingly lazy type of tooling in a way, where it's like, that's bloated, it does too much, your prompt starts up a little slower than it could be if you just did these things yourself.

Where I have taken the angle with Oh My Zsh, I was like, I wanted it to be really easy for someone that's new to a command line interface to feel like they've gone from like zero to 60s super fast, like, "Ooh, I just copied and pasted this thing, now I get some pretty colors."

Things are like, "Ooh." Try to keep that onboarding experience for a new developer, as easy as possible.

And there's been a couple of points in the project where there was a fork at one point.

There was another project called Prezto.

And this, I feel like it might've been back like 2012.

There was someone that was contributing a lot to Oh My Zsh, and they propose some changes, which would basically require a whole new version of Oh My Zsh, because it wasn't going be backwards compatible.

We required anyone using it to level up their Git knowledge quite a bit.

And we went back and forth over it.

And I was like, you know what?

I'm going to have to draw the line in the sand here like, I'm not going to assume that anyone using Oh My Zsh knows how to use Git, outside of knowing maybe that they knew how to install it, but they're not needing to know Git just yet.

Maybe they're the person that's getting comfortable with Git, so I want it to be good for them.

And if you're already asking that, once they install this, they're going to have to understand or get some modules work, and things like that.

I'm like, "This is too complicated. No."

So it forked and they went a different path.

So it's a great alternative option for people that want to accept above Oh My Zsh, or a side or whatever.

But I feel like if I kept catering towards those new adopters to getting comfortable with the command line interface, and being colorful and just being fun about it, then I think that's resonated.

And so it's persistent in the social media and content and I'm just trying to be goofy there.

The tone of Oh My Zsh is delightful and friendly and trying to be encouraging.

One of my favorite things to do is when someone shouts, Oh My Zsh on Twitter, because they're excited because they just installed it.

Because the installer encourages them to do it and to follow us on Twitter, and to maybe come take a look at our swag online.

So, I've had people complain like, "Oh, I can't believe you're advertising to people like that."

I'm like, "It's a free thing."

I'm like just offering a link. It's got an auto updaters, so people feel like they're connected to the community.

I do think that was a pretty important thing because I don't feel like a lot of desktop apps have automated auto updating type things like when you load it up or whatever, or prompt you.

And so I was able to mimic that on the command line interface.

It's just a couple of, if, Ls conditionals in your shell scripting there.

But that I think, has been such a big thing to keep people connected because a lot of tools you'll install and then forget, or you have it there, you might take it for granted after a while.

But Oh My Zsh, it's almost like borderline on being annoying about reminding you that it's there, and like, you got some new things and you can disable that obviously in the configuration.

But it is encouraging you to or reminding you that there's a community, that there's updates.

And we've always thought like, how do we make the updating experience even better?

And we just rolled out some new changes of last few months with like showing a change log.

People hate change, so we got some flack for that, but I do think it looks nice and it looks great when you update it.

And it's even just something as simple as making the--

We've always had asked yard in there from the very beginning.

And I felt like that's been just a throwback to how my early era of getting involved on the internet type things and BBSs, and like, this is so interesting that there's always been this decorating my command line interface starts back to like 1985 when I had my first computer, and it was making my background sign where we had a RGB community computer.

And I'm like, "I want a colorful prompt."

And then we still getting to do that like 35, 36 years later.

So, I think that those are a couple of things that I've noticed over the years.

And then this engine keeps feeding itself or people keep tweeting about it, people blog about it.

And it's amazing. I go on YouTube and I see all these tutorials and install guides and Oh My Zsh is just like a part of someone's setting up a new laptop experience.

And I'm like, "Because of that, it's early part of your laptop setup or your computer set up, and it reminds you that it exists. And if you follow us on Twitter, we try to be fun and playful about it."

But I don't know where all these people keep coming from.

And so something like Orbit has been helpful and at least seeing the growth and spotting out people that are talking about on social media and the people that are contributing on GitHub and stuff like that, to help connect some of those dots there.

But I'm like, "I still don't really understand why it's growing at the rate it does."

It's hard too. Another thing about open source, it's like I don't have any idea how many people were actually using it out there.

And I've always wondered, because GitHub gives me some really basic information on the number of clones, and it's never been really clear.

I was like, "Well, is that a unique clone? And then when someone does a get pull, is that a different thing than a clone in the data? Or is it never show that?"

Or do they have stats? So there's some data there because I just--

There's no way to know. And so I can only look at the number of stars on GitHub and the number of followers like we have just over 40,000 people on Twitter following us, there's people that like it on Facebook all the time.

I get requests on Facebook from people because they want support or they're looking to know when their T-shirts going to arrive, or they post screenshots on Instagram.

There's all these different links up modes of how people interact with their technology and talk about it with their peers that I don't understand.

I haven't yet looked on TikTok to see if there's much there, but I wouldn't be surprised if there was some Oh My Zsh content there as well.

Patrick: So as a project gets to the scale and impact that Oh My Zsh has achieved, what do you view as your role in this, in the community, in the project at this point?

Robby: So one of the things that I was really smart--

We have another person on the project Marc, lives in Barcelona, who is the primary maintainer day-to-day.

And so he's prioritizing and deciding what the agenda is.

So we have regular monthly maintainer meetings and we have another person, Larson, who is also involved in helping triage things and he helps spin up discord for us last year and has helped grow in that community as well.

And we're also trying to make sure that we don't spread ourselves too thin in some of this.

It's been difficult for us to try to figure out how to think about our recruitment process for finding more people to contribute at that level, like on a maintainer level.

And so if anyone's listening, is interested in maybe talking with us about it, we would love to speak to you.

I would like to find some women before I bring more people on. So, that's one of my reasons I'm not just--

We've got offers from people, but I just didn't want it to be a ton of white dudes contributing to it.

And that's important, but not to be a reason why not to bring on some other people for the record.

But anyways, so my role is to be the evangelists.

Marc has been really happy with me like "You're promoting it, you're the one and engaging with people on social media."

And I chime in on some issues here and there and I'll contribute some ideas.

And I am working on a new theme right now that I'm going to be contributing soon, which was base off of just a suggestion someone whimsically mentioned on Twitter and I'm like, "Ooh, I'm going to do that exact thing because I think it's clever."

And I want to give that person on the credit for it.

So, that was an issue I wanted to scratch.

So it's basically to keep doing what I'm doing, which is more of just interacting with the community, making sure that we're keeping the tone consistent and keeping a vision where sometimes it will have conversations with the maintainer and our triage person about some ideas for things.

And there was a proposal about six months ago for some changes to be made.

And as we talked through some different things, I had to deal with our releases and we're looking at a beta tester group type of approach.

And then I basically had to pull out my back card like, "Oh, we need to go back and talk about the core values of this project."

I'm like, "It needs to stay easy for people to first install."

So if we can cover that, and there's a way for anyone that could take that extra step of doing something more advanced, I'm open to it.

But we need to keep the onboarding experience as simple as it is today.

If it gets more complicated and anyone has start making decisions when they're installing it, we're going to lose them.

Like, "Okay, do you want to do this?"

And they're like, "Ask any questions on this install."

They may not even know what we're asking them just yet.

So let's just get them installed, and then if they want to take that step further, we can figure out ways to do that.

So I think that's helped inform how we think about new features and iterating on some bigger concepts within that project, is to just keep coming back and touching on like loose side of that part of it because I don't want us to--

Because I know a lot of projects sometimes can forget like some of those core things.

And I feel like I need to own that and keep reminding and touting that and encouraging other projects to think about that as well.

What's the onboarding experience to use this piece of software that you're using, whether it be a desktop or a web application or a command line interface tool.

Let's make it simple.

I really wish everything didn't need to be like, "Okay, you're going to install this in your Homebrew, now you got to go read the how to the dash, dash, help and try to make sense of all these different flags. Do it like, "Let's make things simple."

I think this all comes back to again, Ruby giving me a lot of that. I love how readable Ruby and Ruby on Rails code tends to be, and I want Oh My Zsh to have a very similar vibe, considering the syntax of Z shell is not as glamorous as Ruby is.

Patrick: So what do you think is the secret to building things developers love?

Robby: I don't know what other developers love. I love nostalgia in light doses.

So I think in a certain way, Oh My Zsh, I like to think, there's a lot of people that are not allergic about command line interfaces from 20 to 30 years ago, because they haven't been on the planet that long.

So I know there's a lot of people in the Oh My Zsh community that have no idea what I'm talking about.

So, but I do think, at least speaking to maybe older develop engineers like "If you can introduce a little bit of nostalgia as things are growing new, and I think that can be fun and helpful."

And so like the ASCII yard and things like that.

But it seems like the younger generations are really excited about this retro vibe and like you're seeing people that are streamers and programmers that are live-streaming themselves and have fun colors and their keyboards are all more like hackery style keyboards, and they're geeking out about this kind of stuff.

So I think if you can be part of their nerding out geeking approach, I think, and be part of like a community, I think is maybe helpful to have to remind them that they're not alone, especially when we're in like a pandemic where everybody's alone.

I think if you have a software tool and you can build a community around it, I think that speaks more than just being like, "Don't speak to the solo developer that just wants to hibernate and just kind of focus on code and then that's it."

Because they're not going to tell anyone else about all the things they love, unless they're maybe occasionally stumbling over to Reddit or Slashdot or wherever the kids are hanging out these days.

It just be like be that one person that's just the annoying like "You should use blah, blah, blah."

That's not the tone that Oh My Zsh goes for.

And I don't think any project should be going for it.

So I think, it's interesting because Oh My Zsh doesn't have a commercial backing or anyone full-time working on it.

And it's always been like a pet project for me.

And I've been very intentional because-- I say that, but I'd be lying if I hadn't thought, "Well, maybe there's more I could do with this."

And then I realize, but I'm like, "Look, am I going to charge people for Oh My Zsh prom?"

I don't know, that doesn't seem like the right thing.

And so when we get some people that'll contribute and they do it.

GitHub as a nice little features to make your monthly contributions and stuff like that. So we appreciate, we were able to get some beers or coffee with that.

And so that's nice. And obviously it gets us all stickers and T-shirts and coffee mugs and stuff like that.

But that basically pays for a few hours of an office admin.

That's not a full-time thing. That's not like, "I'm not raking in the money on selling stickers and T-shirts."

It's more of like a--

I would be surprised if we were even breaking even to be honest.

So, I don't think about it that closely.

So it's just more about getting to interact with the community.

I'm like, "I feel like I get to connect with all these people by selling stickers and T-shirts and shipping stuff around the planet on a regular basis."

And to see those stickers pop up on people's laptops and sharing those photos, I'm like, "I love that."

So I feel like if anything, the project has allowed me to experiment with marketing different tactics, like in an open source kind of world.

And I don't know what I can do with that exactly now.

I've been able to apply some of that. I think if anything, it reminded me just how important it is to be authentic.

And so as I tried to be that way when I'm marketing my company, the more authentic I am, the more things that resonate with certain types of people.

And those might be really good clients for us, maybe.

So, it could also alienate really good clients. I always second guessing myself there.

But anyways, so I do think for Oh My Zsh's secret has been just to be delightful.

And I think keeping a little bit of nostalgia there, but also just promoting the people within the community more so than the project itself.

We're not always like, "It's rare that you'll find a tweet where it's like, check out all these new cool features about Oh My Zsh."

It's like, "I got so and so contributed."

Or when someone else notices it, I will retweet them and be like, "Look what someone else said about the new feature."

It was way more important than, look what we said about our new future.

Because more than likely, it was probably halfway written by another member of the community that wasn't on the maintainer group anyways.

So it not like us, it's the community's contributed to that.

So that just ends up being the ethos that we've continued to try to embrace as we're figuring out how to make sense of this and still maintain our normal day job as well.

I know that this is, I wouldn't say it's my passion project.

It's a fun project. I enjoy it, I can be whimsical about it.

But I go days without thinking about it, and I love that about it as well. And that's okay.

So if you are listening and you have a project and you feel like you owe the community something, you get to set that boundary yourself.

And I've known a lot of developers over the years, I worked on some pretty big projects, like especially in the Ruby on Rails community, there were some people that worked on Capistrano and some other tooling back in the days.

They got burnt out on being open-source maintainers.

And I'd be lying if I said that there hadn't been points on Oh My Zsh where I'm like, "Maybe I should just pass the keys over and say good luck."

But I'm like, "All right, I just got to find what I can do right now in the ebbs and flows."

There's periods of my life where I'm like, "Okay, for the next few months, I can't contribute more on the coding side of things."

But most of the time I'm just like, "This is project priority number six in my life right now."

It's not going to make the top five. And I'm okay with that.

And it might be surprising because I think a lot of people know me because of that, but behind the scenes, I'm like, "I've got other priorities and things I'm working on as well."

I wouldn't want to approach any other open source maintainer with the assumption like, this is all they've got focus on their plate as well.

They've got other things going, and we would have to be mindful of that.

Patrick: Well, Robby, you've been super generous with your time today.

If you wanted to send people somewhere online to learn more about all the things you're working on, where would you send them?

Robby: Yeah, you can find me @robbyrussell on Twitter, and my podcast is maintainable.fm.

Patrick: Awesome. Well, thanks again for coming on today.

Robby: It's been such a delight. Thanks for having me, Patrick.