I think of myself as a collaborative software developer. I enjoy producing open source projects with other people in real time because they can offset your weaknesses and make you better. It’s about collective team strength. I’m the first to admit that I’m not always the strongest developer in any given project by any means. Even on Oh My Zsh, I’m the second highest contributor. Working with other developers helps you level up. When peers offer feedback and iterate on your ideas, you produce something better.

For me, the same holds true in music. I’m in a band, The Mighty Missoula, but for years I felt like I couldn’t focus on creating new music, and when I did, I would hit a wall. What I’ve found is that my skill set as a musician drastically increases with collaboration. I work best when I learn with and from other people, and vice versa—which is very similar to being a software developer.

I’m not a software developer just for the sake of being a software developer. I enjoy the process of creating something with others, and using software to get a task done and serve the end user. In many ways, I ended up creating software that does just that.

A home-brewed improvement with big potential

I’m the CEO and co-founder of Planet Argon, a software development consultancy based in Portland, Oregon in the United States. The company has been around for 18 years, and we’ve had employees for 15. My co-founder, Allison Beckwith, and I had to figure out how to run a business and lead a development team at the same time (without any experience doing either).

I was an early adopter of Ruby on Rails, so we hired a lot of Rails developers for our team. The first four or five years we had a lot of really interesting projects and talented developers, including some early GitHub employees (we were actually one of the early companies to use GitHub from a software development perspective in 2008).

We were all closely connected, experimenting together and writing lots of interesting custom snippets. Some of us started using Zshell versus Bash, a terminal shell environment. Others were resistant because they didn’t know enough about it. I’m the kind of developer who’s comfortable getting something done with a surface level of information and moving on. But I know other developers prefer understanding how things work at a far deeper level before they use or experiment with it.

This difference in styles came up when I first announced the project to my team. It was a combination of Zshell features I home-brewed myself and collected from peers that made me more efficient on my own computer. I wanted to be more consistent and optimize our efforts when we were pairing—regardless of which computer we were using.

In an effort to help, I suggested everyone copy and paste my configuration so they could take advantage of it on their computers. When I saw it was a hard sell for many of them, I went about packaging it better. In doing this, I realized I didn’t deeply understand half of it because it was all culled together from different people and ideas and tools (like GitHub Gist). But going back to my comfort levels with surface-level knowledge, I knew enough to know it was an effective solution for the issue at hand.

I took a few hours to reorganize it with a README file, throw it in a new repository and put it on GitHub. I even named it; for better or worse, I didn’t really put much thought into “Oh My Zsh” as a name. It was a play on a pet project I’d worked on with a co-worker called “oh-my-science,” where we’d take science-related tweets and rewrite them for people. I don’t know how much the name has affected project popularity or adoption, but there was no master marketing plan behind it.

Starting small and expanding to the sweet 16

When I created Oh My Zsh, it was for the 12 people I was collaborating with in the office every day. There was no roadmap, no long-term plan. I never had the intention of making this the most popular framework for your command line. It didn’t even occur to me as something to aspire to. It was just for fun.

Within the first day, everybody on my team had installed it—and within 24 hours, they also wanted to change it. They preferred different colors, which I didn’t understand. My aesthetic was the correct aesthetic (or so I thought)! But in the spirit of collaboration, I organized code related to styling and extracted it into a file called “themes.” That was one of our first feedback-driven features.

I was an active blogger then, so I shared a post with the people who followed me, primarily the Rails community. They started adding Rails-specific shortcuts and extra functionality to make our lives as developers a little easier. And that’s when I first started sharing it more externally.

Within the first few months, we had 16 themes submitted from different people. I think one of the first contributions from someone I didn’t know was a theme, actually. Everybody was getting creative and changing the way their command line environments looked because it was so easy. We got to that “sweet 16,” and I thought this was the future of Oh My Zsh: a collection of themes.

But then members from the Python community wanted to add functionality for their language and tools. So we created a concept around plug-ins for different programming languages and different frameworks. And things started organically growing from there. This was late 2009.

Finding the right audience and knowing when to fork

At one point, a few contributors pitched some really big changes that would transform how people set up and updated Oh My Zsh. This is when I started thinking about my target audience for the first time. At first, it was my team of mainly Ruby on Rails developers; then GIT users; then those using different programming languages.

These new changes felt drastic. Maybe they’d speed up performance, but they’d also narrow the focus to a more sophisticated audience, and I didn’t want to manage or even be part of that project. So it forked into Prezto, which is a touch faster than Oh My Zsh. I was okay with that, and still am.

One of the great things about Oh My Zsh is that anyone new to the software industry can quickly install and take advantage of it in under 90 seconds: beginners, junior developers, mid-level developers. It’s certainly not a tool you need to have, it’s a nice-to-have, and I want the experience to always be fun, positive, and easy. The minute you install Oh My Zsh, it transforms your perspective on your command line. If you outgrow it, no problem. There are other tools out there for you.

Learning to trust contributors

Before Oh My Zsh, I was known as “Robby on Rails” because of my blog. I was an early Rails developer, which was primarily how I made my money (and still do) as a software engineer. At some point, there was a shift, and more people started to recognize me as the creator of Oh My Zsh.

Personally, though, I don’t consider Oh My Zsh as one of my top five projects outside Planet Argon. I have employees, a personal life, I’m in a band. It’s just never going to be a top priority for me. I didn’t have anyone else helping on a maintainer level for far too long, and I know it was detrimental to the project. Unfortunately, the community just had to deal with it until a few contributors decided to take more decisive action.

In the beginning, I wasn’t sure if I should accept contributions without reviewing them because I always had this fear I’d overlook something. People were using Oh My Zsh on a daily basis, and I was admittedly nervous to hand over the keys; I didn’t want to potentially screw over thousands of developers’ computers because I didn’t pay close enough attention to what someone else was doing. I felt a sense of responsibility and desire to understand exactly who was working on it.

A couple years in, some especially enthusiastic contributors, including Marc Cornellà, helped shape and improve the underlying aspects and framework of the tool. Marc was really clever and proactive and would consolidate big collections of pull requests for me to approve all at once. He inserted himself into the project in a kind of a workaround way, and did all the grunt work—likely to get his contributions out quicker, I think. But I started to trust him. Finally, after about a year, I gave Marc access to merge things on the main branches with a clear set of three parameters:

• Oh My Zsh was created for people new to this environment, which means it should always be simple to install, use, and update.

• Documentation should be user-friendly and easy to read.

• We need to stay mindful not to merge anything that might blow up everybody’s computer.

Since then, Marc has taken over as the primary maintainer, and has worked through way more pull requests than I ever could. I might spend four hours here and there contributing or merging a few things. Occasionally we’ll have calls to talk about next steps. But nowadays, my involvement is more about promoting. We have an online shop where we sell stickers and t-shirts—which is funny because in the ’90s, I started to learn how to be a web developer so I could sell stickers online. I obviously failed at that business, but accidentally created an open source project that now sells way more stickers.

A little mystery and a lot of enthusiasm

Over the last few years, I’ve come to the realization that I’m more of a software mender than maker. Our community focuses a lot on shiny new technologies and learning how to build new things. But we really need to talk about its long-term challenges. As a team (at Planet Argon) we decided to produce a new podcast called Maintainable, which I currently host. On the show, I have conversations with seasoned practitioners who have helped organizations work past the problems often associated with technical debt and legacy code (like Eileen M. Uchitelle on upgrading Ruby on Rails At GitHub). Spoiler alert: They aren’t always the technical problems that we need to work through.

With the business, the podcast, and everything else, I’ve had to learn how to not feel guilty about de-prioritizing projects that I know can continue on without me. I might find a handful of hours a month to work on Oh My Zsh, but I don’t feel an obligation to pour in 10 hours a week. It’s nice to know Marc and the other maintainers can take care of it.

If someone were to ask me how I got other people to use Oh My Zsh, I’d say that I started by focusing on the circle of people closest to me. I wanted the people I was literally in the same room with to immediately use it. It organically grew from there. And for the record, I have a number of open source projects that no one’s ever heard of. This was one of many, and I clearly had no idea it would take off. I’d say there’s a little bit of mystery on how exactly this happens.

Since I run a software business, I’ve also had the luxury of experimenting with marketing open source projects. And I think the key is to be enthusiastic. I show a lot of enthusiasm for Oh My Zsh. As silly as it sounds, there’s a really friendly little message that shows up in your command line prompt when you install Oh My Zsh. I was able to bake in some of my personality and humor into the software code and README.

You want your audience to feel delighted and happy when they first experience your project. You want to establish a relationship with them. Given that we don’t get to know everyone who downloads and uses your software, this is just one way to build a connection.

I love to promote other people’s excitement, too, so there’s a lot of retweeting and partying on Twitter. For example, if someone posts an Oh My Zsh tweet, I’ll try to immediately retweet them. And often these are junior developers who have 15 or so followers. So when I repost their tweet, all of a sudden they’ve got 50 new people liking or retweeting them. I love that I can do that with this audience and give them that kind of access. Everyone feels like they’re in it together.