This week we talk with Mike Perham, CEO of Contributed Systems and creator of popular Ruby gems such as Sidekiq and Dalli. Mike covers the zen and art of naming open source projects, what the sweet spot for pricing is and why value lies in the experience behind projects. He also covers why empathy is key when interacting with your project’s community, his model for building a business around open source software, and much more.
Listen to the podcast in the player above, or click here to download it directly. Subscribe on iTunes or do so manually by using this RSS feed.
Show notes
- Mike Perham: Website, Twitter, Github
- Sidekiq: Website, Twitter, Github
- Inspeqtor: Website, Github
- Contributed Systems: Website
Transcript
Alexis: Thank you Mike for taking time out of your schedule to join us here on the podcast.
Mike: No problem, thanks for having me.
Alexis: So before we get to Contributed Systems and Sidekiq, tell us about your background.
Mike: Sure. I’ve been programming for the better part of 20 years now and I’ve been building server-side applications and websites for about 15 of those years. I’ve been doing Ruby for about seven or eight years now and just recently started doing a lot more Go. I did Java for the first seven or eight years of my web career. I’m a long-time programmer and I’ve been moving from language to language, but mostly staying server-side.
Alexis: I have a feeling we’re going to hear a bit more about Go in a couple of minutes here potentially when it comes to new products or that kind of thing.
Mike: I think that’s a fair –.
Alexis: Assessment?
Mike: A fair guess, yeah.
Alexis: Before we get into work, into specific types of experiences you’ve had – when did you learn to program? What was the impetus?
Mike: Well, when I was in high school, I played on BBSs all day, every day, outside of school. This was pre-Internet, back in the stone age of the early ‘90s. I started on a 1200 baud modem, call up dialing into BBSs and chatting with people and playing various games in those BBSs; downloading software and uploading software and that kind of thing.
When I went away to college, I heard about this new thing called the Internet and so I started playing with that, and FTP, using Gopher, Archie – all these different protocols, Telnet. And then my sophomore year, this thing called the Web – I heard about the Web for the first time when my friend showed me Mosaic, and I programmed my first HTML page on a DEC Ultrix using vi, and it was basically just <html> <body> <p> Hello World!
At that time also I started doing computer science, so I did CS101, CS201, got into Assembly language, data structures, operating systems – all your standard computer science academia. From there, I did internships at PeopleSoft in Microsoft and worked on the NT team – NT, Networking Team – at Microsoft for summer, and then got recruited out of college to go work for an enterprise software vendor in Austin, Texas.
Alexis: Alright.
Mike: So that’s where I started doing Java. From there, I just – the Web sort of took over the world and I followed along.
Alexis: What were the first open source projects you dipped your toes into?
Mike: Interesting question. The first project that I sort of did on my own, I just naturally did open source. I don’t know why. I think it was because if you don’t have any way of selling it or monetizing something, you just naturally view it as valueless and you just throw it out there to share with other people – at least, instinctively, that’s kinda how I were.
The first thing I built was in 1995 – it was a little Windows tool, a little applet that you’d run. It was called AppBar. I just built it to teach myself Visual C++ and Win32 API programming, just how do I build a Windows executable. So I threw that out there and then the second open source thing I did was a couple of years later – I did a clone of Napster that I wrote in Java. I built a Swing UI; I didn’t analyze the protocol, but another guy had analyzed the protocol so he had documented how the protocol worked. I just wrote a version in Java that I could run on my Linux system; at the time, I was running Linux on my desktop, and obviously couldn’t run Napster on Linux so I wrote a Java version that anyone could use. And of course I released that as open source also.
The third thing I did a couple of years later was I started working with Maven, because I was working with a Java system that had a lot of big build process, so we were using Maven for the build. I started working with Maven and just was contributing patches to them, and they eventually asked me to become a committer. So I was actually a committer on the Apache Maven project for a year or two.
And then GitHub happened, and at that time I’d switched over to Ruby right before GitHub came out. I started working with a bunch of Ruby gems and GitHub made it so easy to collaborate with other people that I was able to quickly take over a bunch of Ruby gems. I was able to start my own Ruby gems and my open source work sort of multiplied ten-fold because of the ease of use of the tools and the workflow.
Alexis: So folks listening to the show would probably know you from your Ruby work and your open source Ruby gems; tell us a little bit about them.
Mike: I mean, I started with Ruby seven or eight years ago probably at this point, and just naturally through my work – we were trying to build systems and we were relying on these gems. Some gems worked great and didn’t need any work at all; other gems needed some love and nobody was stepping up.
For instance, there was memcache client that was native Ruby at the time and it had a number of issues. And so I asked the maintainer if I could take it over and sort of really spruce it up, and so I did that. I sped it up by about ten in order of magnitude by finding a bunch of places where it wasn’t optimized. From there, I did a database sorting library called DataFabric. I did a little gem to deal with services on OSX called Launchy. I did a Bayesian filtering gem called bayes_motel, which is a pun on Bates Motel from Psycho.
Alexis: Right, right.
Mike: I did sort of half a dozen different gems, but the big ones that really took off was Dalli, which was my second-generation memcache client, which has become the de facto standard in Ruby now. And then of course the big one that I’m known for now is Sidekiq, which is a background processing gem that, like Dalli, has taken off, and a lot of people really like and think it’s the best one out there. I like to think it’s the best one out there, too.
Alexis: Now before we make the jump to talking about Contributed Systems and Sidekiq a bit more, there are a few threads that I’d like to pick up on. First of all is open source naming. You’ve got a good knack for giving things names [chuckles].
Mike: Well, yeah. The key thing these days is you need to be searchable, right? People need to be able to Google you; people need to be able to search on Stack Overflow. If you name your project – I’m just going to throw out random words here, don’t think I’m naming any projects, but if you name your project Chef or Puppet – just thinking of random words off the top of my head, of course – it might be very hard for your users to Google and get help and find relevant content.
Typically what I do I is I take a word and I tweak it so that it’s spelled incorrectly. With Sidekiq, I used a ‘q’ instead of a ‘ck’ at the end and it’s worked out incredibly well. When I do a Twitter search for instance for Sidekiq, 99% of the results are relevant to my gem.
Alexis: Well I have to say, I hope that nobody makes a movie called Sidekiq with a ‘q’ because as a Django developer –. When Quentin Tarantino’s movie came out, I had to minus Quentin Tarantino or –movie to filter all that.
Mike: Yeah, there can be a six-month or a year period where your search results become far less useful.
Alexis: Yeah [chuckles].
Mike: Dalli was based on Salvador Dali’s name but with two l’s. What I didn’t realize though is that there’s an EU politician also named Dalli, and so about 50% of the results for Dalli are for people talking about this politician.
Sometimes you win, sometimes you lose, but it’s better than nothing I guess.
Alexis: There’s an in-between part – before you get to Contributed Systems at The Clymb, tell us about a bit about your role and your involvement with them and who they are.
Mike: Sure. The Clymb is an ecommerce vendor, sort of like Gilt Groupe. If you know Gilt, they do daily flash sales. Every morning they announce a new sale from a brand and you have a 72-hour period to buy any product attached to that sale – that’s what’s called a flash sale because of the limited time. Ideally, you get really good prices, really good deals for this; oftentimes there are going to be blowout on old inventory, but sometimes it’s just limited edition merchandise. But every day you get something new. From our user base standpoint, they were just excited to see new sales every day – it was more of the same every single day.
So that’s The Clymb, and The Clymb is focused on outdoor and active wear. You can buy skis, you can buy bikes, you can buy yoga clothing and apparel, hiking boots, jackets – anything you’d want when you’re outdoor camping or doing any sort of outdoor activity.
Alexis: Okay. And so you worked with them just before you stemmed off to do Contributed Systems. What was the point and the impetus for making the jump?
Mike: I was Director of Infrastructure at The Clymb, which basically meant I was in-charge of the site and its reliability and its operations. I was, I guess you might say, Director of Technical Operations. I also ran the analytics team for a short while, ran the IT department for a short while.
The impetus was I had started this experiment with Sidekiq to see if I could make my open source work financially viable. That is, if I could actually start making money – a reasonable amount of money – for all the hours that I was putting into my open source work.
I actually created this new thing called Sidekiq Pro, which I decided to sell for a nontrivial amount of money to see if I could get enough customers to where I was actually getting a decent amount of recurring revenue, to where I could do open source full time. Ideally, that was my goal – to support myself and my family doing open source full time.
For the last two and a half years, I worked at The Clymb but working on Sidekiq and my open source stuff in my spare time. In over the last two and a half years, Sidekiq Pro has just kind of gone up and up. At this point, I am making enough to support my family and myself on my own with a good, full-time salary just through Sidekiq Pro’s sales.
Alexis: Congratulations!
Mike: Thank you.
Alexis: You made the jump in the dream [chuckles]. You made the jump in July, right?
Mike: Yeah, I made the jump about three months ago. The Clymb basically was going through some changes and offered me a new role, or to leave the company with a nice severance package. And I decided to leave the company with a nice severance package and to make a go at the full-time open source thing.
So I founded my own company, Contributed Systems, and the mission behind contributed systems is to build awesome products for application developers that are based on open source. There is a core that everyone can see, everyone can contribute to – thus the name – but there’s also a commercial side to pay for me and anybody else who I want to hire to maintain this stuff full time, to support my customers.
Open source is not just throw a couple of commits or a PR at a project; it’s also supporting that project and that product 24/7. If your customers are emailing you needing help, there needs to be somebody who’s there helping them out.
Alexis: I noticed a bit of a change in tone from earlier. You mentioned that your first open source project, “I’m just going to put it out there; it’s valueless. People can use it” – what was the point when you realized, “Holy crap! People can make money on open source projects and still keep them open source, still keep close to the ethos of open source, but managed to support themselves and the project at the same time”?
Mike: I think a lot of the value comes with the people behind it. When I started doing open source and I considered my thing valueless, part of that was because I didn’t know what I was doing. I had no idea if this is the right way to do this – I’m just learning.
When you are just learning and building something for the first time, you consider it valueless, right? It’s a prototype – you’re kind of building something just to learn and the value in it is just inherent in the knowledge you get. However, I’ve been doing server-side applications and open source development for two decades now, and so I know what I want. I know the right way to build it. I know how to make a very efficient, reliable, extremely useful product, and that is where the value lies – is in the experience behind the project.
My experiments two decades ago might have been valueless, but what I’m building today is based on my experience, is based on trying to build a better mouse trap than what’s out there today, and people are willing to pay for that.
Alexis: Are there any projects you draw – open source projects – that also have a commercial component that you draw inspiration from?
Mike: I hate to say it, but there’s a lot –. A lot of what I’m doing is me off in the wild myself. There’s really none that I can offhand think of; I’m the only person in the world that I know that’s selling a Ruby gem.
Alexis: Right.
Mike: Maybe there is. Of course you’ve got projects like RubyMine and NetBeans for a while – Sun was trying to sell the NetBeans IDE. But again, those are more Java-based, focused on the Ruby community, but of course they’re Java-based. So I don’t know of a lot of open source projects which are just trying to sell. There are a couple if you look really hard, but I can’t think of the names offhand. I don’t recall them.
So no, unfortunately, there’s not a lot of inspiration out there, and I’m trying to change that. I mean, I’m trying to inspire others to take the same approach. Open source, I think, is an incredibly – it can be solely merit-based and something that anyone can achieve if they have the time. The key is that you have to have a lot of time, of course.
Alexis: We’ve mentioned Sidekiq a couple of times; we haven’t really delved too deep into it. Tell us what it is and why you created it.
Mike: Sure. Sidekiq is a Ruby gem for executing tasks in the background. That is to say, if you have a website and the user clicks ‘submit’ to submit a form with some data, oftentimes the processing behind that form submission might take seconds, minutes, hours. That’s where Sidekiq comes in. You don’t want to make the user sit there and wait for seconds or minutes or hours. What you do is you create a job which says, “Here’s the data that I was given, process this job.” So what you show to the user is, “Thanks! We got your submission” or “Thank you for your order” or whatever, but in the background, Sidekiq is now starting to work on this process. It might be contacting your database; it might be contacting third-party APIs to verify credit charges; it might be contacting – who knows what kind of third-party APIs it’s talking to? The point is it happens in the background so the use doesn’t really care about it.
Three years ago, what was state-of-the-art was, in my opinion, kind of cobbled together. You had to cobble together a whole bunch of Ruby gems to get a decently workable background job system, and I didn’t like that. On top of that, it was extremely inefficient. From a technical viewpoint, it was a single-threaded process which is just not very efficient in terms of memory usage, taking advantage of your CPUs – that kind of thing.
What I decided was that I wanted something really efficient, and I wanted something that was very simple that gathered all the required functionality into one, clean package, and that’s what Sidekiq is. It’s my opinion on all the different functionality you need to really do background jobs well and it’s all simply tied together in a very clean, easy API to use.
That was the logic behind my creating Sidekiq, and it just sort of took off as people saw the same value that I was trying to – the value that I was trying to create, people really saw that.
Alexis: Speaking of it taking off, how did you spread the word at first and how did it gain traction?
Mike: Half of open source is actually writing the code and the other half is telling people about your thing, right? Because if you build it, they will not come.
Alexis: [Chuckles] So true.
Mike: You have to evangelize it. For the entire time I’ve been a Rubyist, I’ve been on Twitter, I’ve been blogging. I’ve been building up a set of followers who know me; they trust the technical content that I write; they trust the Ruby code that I write, the gems that I build, and so as I built up this audience, it became easier and easier to sort of evangelize my new thing and to immediately get hundreds of people trying it out and seeing it and then evangelizing it to their friends also.
It’s a network effect, but you have to build that network up and you start by just evangelizing yourself and evangelizing what you’re building as really valuable to those people.
Alexis: At what point did you start to do this blogging and you realized, “I’m creating an audience further than just ‘I’m just blogging here’”? Was it from the very beginning or –?
Mike: I’ve been blogging for probably a decade now with a mind of, “I want to build up a name for myself so that people trust me.” What that does is – the reason I did it initially was I wanted to always be able to get a job.
There was a period in 2003 when the economy tanked where I had to search hard for a job for a month. I was unemployed for a month despite being a very talented developer; the economy was bad enough to where I could not find a job. So I vowed to myself that I didn’t want that to happen again, and so the best way you can do that is investing in yourself, to constantly be learning, and to also constantly help others learn – because they remember that. They remember who you are; they’ll start to trust you as a person.
If you then say, “Hey, I’m looking for a job,” they’ll know “This guy’s smart; he’s valuable as a programmer.” And so your odds of finding a job even during tough times become much easier.
So I’d always blogged to educate myself and to help others, to educate others, about what I was learning, with the mind of always having a name for myself and to never struggle to find a job again. And so that blogging built up an audience and built up that network of followers – this was pre-Twitter, of course. You had your RSS followers, and so that sort of naturally gravitated toward Twitter as the tech scene all jumped on to Twitter. I was able to promote myself on Twitter and the blog posts that I wrote.
Now I’ve got several thousand people following me and that’s a natural network for me to evangelize my own work.
Alexis: Was there ever a pivotal moment where it’s like, “Okay, I have made it! I’ve amassed a pretty big following” or is it just more of a gradual kind of build up?
Mike: It’s day by day.
Alexis: Day by day.
Mike: Unless you’re retweeted by Lady Gaga or something stupid like that, you don’t go from 50 followers to 5,000 followers overnight. It’s an every day slog to get ten more followers that day.
I take my followers’ time – I try to take it seriously where I don’t try to tweet too prolifically. I don’t want to waste people’s time. There are some people that tweet a lot more than others, and I find myself having to curate who I follow just based on how often do they tweet, are they filling my timeline with tweets. I try to take my followers’ time seriously and tweet stuff that is useful to people.
Alexis: You’ve mentioned your monetization model a couple of times now and Sidekiq and Sidekiq Pro. What’s the difference? How did you decide, “This is going to be open source –.”? Is it all open source, or do you have a closed source, or –?
Mike: Sidekiq Pro is a library that sits on top of Sidekiq. Sidekiq itself is open source; Sidekiq Pro is not technically open source.
Now I do have a couple of exemptions for that. One, when buy Sidekiq Pro, you get a gem. The gem has my code in it, so you see the code. So yeah, it’s not open source, but the code is there for you to use. If you need to modify the code in the gem for some reason, you can do it.
What was I going to say? You asked, how do I decide what goes in what. That is the $64,000 question. That is a struggle, for sure. Every single feature that is in Sidekiq Pro, somebody or other has said, “This is stupid and should be free – not in Sidekiq Pro. Batches? Oh that’s critical functionality; it should be in Sidekiq and not in Sidekiq Pro. Reliability – that’s stupid. You’re playing with your customer’s data. That’s not right. That should be free.”
There’s a kernel of truth in all that. The reality though is that I need to pay rent and I need to be able to support all my users, and for that, people have to pay for what is valuable. All that stuff is valuable, and so I charge for it. That’s the long and the short of it. You have to sometimes make those hard decisions. It’s not easy, but neither is paying rent, sometimes.
I don’t have any better suggestions for that; you just have to make the call. I will say though that you have to remember that the open source version that you give away for free has to be, itself, very valuable or people aren’t going to use it.
Sidekiq itself has a lot of inherent value, and Pro itself, I think, adds a lot of value on top of that. I hope that people want to use Sidekiq and hope too that they consider upgrading, because itself adds a lot more value.
Alexis: Now you don’t have pricing available on the website, I don’t think, for Sidekiq Pro. Am I wrong or –?
Mike: It is on the Sidekiq Pro page.
Alexis: Oh, Sidekiq Pro page. Okay.
Mike: At the very top, there’s the price right in front of you – that’s $750/year.
Alexis: So walk me down your decision to price it at that.
Mike: Sure. $750/year is about $60/month. When you think in terms of “This is a core component to my application and a core mechanism to scale my business and my website to thousands, tens or hundreds of thousands of users – millions of users – 60 bucks/month doesn’t really seem all that much. That still doesn’t answer your question of “Why don’t I price it at $10,000/year then?” or “Why don’t I price it at $50,000/year?”
Alexis: Eenie-Minnie-Miney-Mo – that one! [Chuckles]
Mike: I mean, pricing is tough. What I’ve tried to do is one, duck under the radar of needing to get a VP or a CIO approval to buy something. When you’re talking hundreds of dollars, usually a director has that kind of leeway. A dev team, if they say, “We want this tool” – if you’re talking hundreds of dollars a year, it’s usually a no-brainer. Sure, buy it for them. I wanted to grease those wheels to make it very easy for someone to decide, “Yeah, I want to try this out.”
Because going back – I think I mentioned it earlier – when I started Sidekiq Pro, I had no idea if people are going to trust me. Are people going to actually want to buy this thing? I had no idea. As I did mention, I’m the only person I know of in the world selling a Ruby gem, so nobody does this. For a Ruby development team to say, “We want to buy this Ruby gem” is itself a very bizarre act [chuckles], a very nontraditional act. The price is me trying to not get in the thousands of dollars where you have to go to somebody and try and justify it, but at the same time not too cheap to where I can’t live off of it full-time if I get enough customers.
Sidekiq Pro, at this point, has over 300 customers; I think I just went over about 350 customers recently. A lot of those customers bought in the early days where the price wasn’t reoccurring. But now the price is actually reoccurring, and so I have, at this point, 100, 200 customers or something like that that are paying me, reoccurring.
Alexis: Very nice.
Mike: So now Sidekiq Pro is at the point where I’ve got of six figures of reoccurring income for it, and that’s the point where I can make it a full-time job and support it, and support all those customers. That’s why the price is what it is. If you’re talking 100 bucks/year, you really need to scale up to thousands of customers before you can make it full time, and I wanted to get to the point of a couple hundred customers.
Alexis: You mentioned some of those customers – you said about 300 or so – they include Groupon and Heroku and Discourse and some big names in there. And Oracle, even.
Mike: Digital Ocean. Oracle actually has three licenses now [chuckles].
Alexis: Not divisions?
Mike: Not because I tried to scam them but because they bought one and then two startups that they purchased also have bought Sidekiq Pro licenses. They probably bought those licenses because Oracle in general will not buy a startup if it uses anything with a GPL License. They probably bought the license –.
Alexis: Just to buy the company.
Mike: Because they knew that they were being courted by Oracle.
Alexis: That’s pretty funny.
Mike: So I want to thank the people of Oracle for paying my rent last month [chuckling].
Alexis: So in addition to – you pay the 750 bucks/year, but you also get support, right?
Mike: Yeah. My policy on support is, if you’re on the open source package, everything – all your support must be held out in the public. You must use the mailing list; you have to use GitHub Issues; you can ask questions in Stack Overflow, but the point is –.
Alexis: Or happy hour.
Mike: What’s that?
Alexis: Or your happy hour.
Mike: Or happy hour – good point. That’s available to any Sidekiq user. But I will not speak privately with a Sidekiq user, and that’s specifically because I want my public support to be indexable, to be searchable, and for other people to be able to find it and read how another person solved their problem.
When you buy Pro, you get that private channel to me – you get email support, you get a guaranteed response. My response policy is two business days, but typically it’s more like two hours. I mean, I’m sitting in front of my desk 9 to 5 everyday, answering emails and answer Stack Overflow questions, GitHub issues – that sort of thing. This is a full-time job and I treat it like that. I’m there to support my customers.
Alexis: And if folks have something that they want maybe a custom feature built, or they need some intensive help with integration, you also do custom support or work?
Mike: That’s right. Since it is a full-time job, I’ve got hours to spare if people want to pay for it.
Typically what I offer is things like review of your application to make sure that you’re scaling Sidekiq correctly, to make sure that your code is thread-safe, to make sure that you’re not contending on any global –. A lot of people, for instance, use memcache totally, and they’ll have a single Rails or Sidekiq process with a single memcache connection and so all of your threads are contending on that one socket.
That’s a common thing where I will review your code and say, “Oh yeah, you’re contending on that and that’s why your memcache performance is miserable. You’ll need to use a connection pool there.” That kind of thing, I’ll charge people my hourly rate but it may be costing them thousands of dollars a day in terms of having to spin up more Heroku instances, having to spin up more EC2 instances, because their code is so inefficient. There’s a tradeoff there, right? You pay me a little bit of money, hopefully you can save yourself a lot of operational costs.
The support and consulting is one offering that I have now that I am full-time on it.
Alexis: We’ve discussed pricing and you’ve made it clear that it’s not an easy thing to do, but if you have one pearl of wisdom that you’ve learned from pricing that you could share with other developers, what would it be?
Mike: It’s either set your one-time price very high or make your price reoccurring.
Alexis: Okay.
Mike: If you sell a license to use your software for the rest of your life, that means that that person can email you a support question 10 years from now.
Alexis: That’s true.
Mike: If your customer is using your software 10 years from now, they should be paying you 10 years from now. That doesn’t mean they should be paying you a lot of money – $60/month in the scope of a company like Oracle or whatever is peanuts, but it means that the always have an open channel to me if they want to go straight to the source and say, “Hey I’ll have a Sidekiq problem five years from now.”
So you need to make that call of, do you want to set a really high, one-time price? When I say “really high” you’re talking four figures, five figures if it’s a complex thing. Either way, the point is to make sure that that user – if that user is using your product for 10 years – that they are paying you some reasonable sum over the course of that 10 years.
So someone uses Sidekiq Pro for a year and then moves on to something else, they can just stop paying me after a year and it’s done. Their subscription is cancelled and I don’t have to support them anymore; I know that. Since support is such a big part of your tasks when selling software, I think a subscription model is necessary.
Alexis: What’s changed over the years with interacting with the Sidekiq community? What’s been tough? What have you learned? What advice would you give to other folks?
Mike: When I first started, I – in fact, this is true five, six, seven years ago – I was not nearly as empathetic to people as I am now. And I think a lot of that is because if you’re doing open source and you’re making no money at it and people are constantly pinging you with questions, it just grinds you down. It really does, and you start really sniping at people; you get tired of answering the same questions over and over and over.
Alexis: Read the docs.
Mike: Exactly! It’s RTFM every single day, and that’s why I say do the subscription thing. Make people pay you for this, because you’re going to be answering the same dozen questions every single day. Ideally, that informs your design – issue 2.0, issue 3.0 – to design around these questions that your users are asking so that they don’t have to ask them anymore. Make your API design smart enough and simple enough to where the user doesn’t have to ask those questions anymore. That’s a huge part of designing a valuable, usable, simple component – taking that feedback that you get from supporting users every single day and putting it into version 2.0, version 3.0.
But really, you have to be empathetic and you have to treat people with respect and be very careful with how you write back to people. It’s so easy to sound very short with people, very sharp with people, when just responding with a sentence or two. That’s a potential user and a potential customer that you’ve now alienated, and growing that network is all about building people’s trust in you and building their confidence in using your product.
Alexis: On a more personal note, you mentioned that it really grinds down on you having to deal with a lot of these kinds of similar bugs and that kind of thing, and you’ve managed to institute a system in your workflow where you fixed a lot of that. I’ve asked a couple of developers before how they deal with burnout when they’re working on the same project. How do you keep from burning out? How do you decompress?
Mike: That’s actually a really good question [chuckling]. I don’t have a good answer for that.
I love doing open source; I love building code, I love writing code, I love building tools like Sidekiq, like this new project that I’m going to be introducing next week – I love building things. I love the creativity of programming.
The burnout – I actually don’t get burned out much anymore just simply because I treat it like a full-time job and that these are my customers and they’re paying me and therefore I have to answer their questions – and users too.
What I will say is if I find that I want to answer a question with a snipe or sarcastically, I oftentimes just simply won’t answer the question at all. If it’s a Stack Overflow question it would be that, like “How do I do this with Sidekiq?” That kind of open-ended question is something where I can spend the next four hours going back and forth with them. That is simply too much, so I just won’t answer those questions.
The questions that I can answer and help them, even if it’s a question that I’ve answered over and over and over, I’ll remind myself that “Hey, be patient. This is all part of supporting your product.”
Alexis: I imagine you use a lot of text expander.
Mike: It’s not that bad. Every person’s problem is slightly different. Generally, every answer I give is custom-built for you [chuckles].
Alexis: It’s a limited edition.
Mike: Exactly.
Alexis: So you’re currently a one-man band, right?
Mike: Right, yes. Exactly. I do it all here. I’m the Chief Janitor, CTO, Accountant – I do a lot of bookkeeping, which has been fun. Yeah, it’s been interesting starting your own business.
Alexis: Speaking of, I was going to ask about hiring but before we get to that, what’s the hardest part of being a lone gun? What advice would you give to people doing the same thing?
Mike: Well, it’s the social interaction that you get with a team. I enjoyed working with my team at The Clymb; every day you go in and you’ve got a dozen engineering folks to shoot the breeze with.
Alexis: Share gifs. [chuckles]
Mike: Ask them how their weekend was and – yeah, exactly. Exchange memes and gifs and that sort of thing in Slack or Campfire.
It’s been tough from that standpoint. I do have sort of a daily routine that I go through so that daily routine kind of keeps me sane. I work from home in the morning right now, and then in the afternoons I go to a coffee shop and I’ll work from the coffee shop for two or three hours on my laptop. That kind of routine is what you need to stay sane.
I started my business in July – three months ago. It’s September now, and I’ve been told that as winter comes in Portland, it gets darker and darker, and it really starts to grind on you as it’s cold and dark. We’ll see. I’m going to take a deep breath and dive into the winter and see if –.
Alexis: If you come out the other side.
Mike: If I come out alive next spring. But yeah, I’ve got a routine and I keep to that and so far, so good.
Alexis: Speaking of Portland, have you been there all your life or did you decide, “I want to move to Portland”? What’s the –?
Mike: My wife and child and dog and cat and myself moved here two and a half years ago, actually just when I started Sidekiq. I started Sidekiq because I had left my job at Carbon Five, a consulting company in San Francisco, and had two weeks off before moving out to Portland. I just started building Sidekiq. So I’ve been here that two and a half years.
So far, I love it. The winter’s a little rough, but it’s a small enough town to where you can bike pretty much everywhere, and it’s not too expensive to where you can’t live on it on a decent tech salary. So yeah, we’re really happy here, so far.
Alexis: Your next products are currently under development, and since this podcast is being recorded about two weeks or a week or two before it’ll be released, I think you can spill the beans if you’d like.
Mike: That’s right. Part of the opportunity of leaving The Clymb was to – Sidekiq Pro was making enough money to support me, and it still is. But the other part was I had this idea for a new product, for a new open source project, and then a commercial add-on, of course, in the exact same vein, and so I wanted to make a go of it. I figured –.
Alexis: That’s a hint!
Mike: Yeah, exactly. I’ve been wanting this product for the last five years, and for the last five years I’ve been using another open source product that’s kind of similar to it but was maddeningly incomplete in some areas. I have spent the last couple of months learning Go, which is a different programming language from Ruby, because it has the language traits that I need for this new product.
The product is called Inspeqtor with a ‘q’, sort of like Sidekiq with a ‘q’, it’s Inspeqtor with a ‘q’. I’m still trying to come up with the proper –.
Alexis: Tagline, right.
Mike: Exactly, because you got to have succinct way of describing it. In essence, it is application infrastructure monitoring. It comes out of Monit and other similar type of systems where you want to install daemon on every machine you run to monitor your processes to make sure that they’re up, to make sure they’re not using too much RAM, to make sure they’re not using too much CPU.
Monit can’t do it – well, I don’t think it can – but Inspeqtor can monitor a whole bunch of daemon-specific metrics. You can monitor MySQL replication lag; you can monitor your Redis fork time, your memcached, number of gits that you’ve gotten in the last cycle – all sorts of daemon-specific metrics. The idea is to have one thing that you can use to monitor all the moving parts of your server-side application.
Alexis: Your recent blog post on daemons now makes more sense [chuckles].
Mike: It does, yes.
Alexis: In laying the foundation there.
Mike: Yeah, and the reasoning there is I’ve been trying to get people to use their init system because Inspeqtor will only inspect things that are controlled by the init system. That is a conscious decision that I decided to make when I was building this thing, is I wanted to not only build this tool that was useful, but I also want it sort of like Sidekiq. I want it to encapsulate best practices to tell people, “This is how you should be doing and designing your applications.” I don’t want to support every single, hacked up, BASH script that people can build as a one-off to run their thing; I want them to invest the time to properly start it with their init system. Because that’s how you build a reliable, robust, server-side application.
Inspeqtor does take some of those tradeoffs and it makes some hard decisions, and it preaches a little bit to the user to say, “Hey, this is the right thing to do. Here’s why. Please do this.” Hopefully people appreciate that rather than think it’s overbearing.
Alexis: There’s some curiosity here – you’ve developed – Inquisitor, was it?
Mike: I’m sorry?
Alexis: The Inquisitor – Inquis –?
Mike: Inspeqtor.
Alexis: Inspeqtor, sorry. I’m inventing a whole, new name for a different project.
Mike: I’ve got a new – I got more competition now. There’s a new thing called Inquisitor – yeah.
Alexis: Inspeqtor, you developed it pretty quickly in a couple of months. Is that going to be your modus operandi for the next couple of months? You’ve got another project idea that you want to put under the Contributed Systems’ umbrella?
Mike: Short answer is no. What I’ve built in the last four months is the MVP.
Alexis: Alright.
Mike: This is what I’m willing to go public with, to say –. Remember also, for the last four months, I’ve been learning Go. My first stab in Inspeqtor sucked, and you recognize that as a programmer, right? You are going to write some bad code, initially, and the more experience you have – I’ve got two decades of experience now – the quicker you can come up to speed with languages, idioms and how it works.
But that doesn’t change the fact that it will take a couple of months to sort of get familiar with the idioms, to understand the way things should be designed – that sort of thing. I’m still not convinced at all that Inspeqtor is a 100% great Go code, but what it is is it’s –.
Alexis: It’s surmisable.
Mike: Four months of full-time Go – idiomatic Go code. I’ve had some Go people, some people that I trust; I’ve given them access to Inspeqtor to take a look through it, and they’ve given me some bullet points of feedback which I’ve gone back and iterated on. But for the most part, people have been very positive and said, “Yeah, this stuff – it doesn’t look too bad. Throw it out there. It’s ready to go.”
After a month or two, it was not ready to go. I still had to iterate on refactoring a bunch. I still didn’t have enough features to go public with, but it’s at that point now. I told myself I was going to give myself at least three months to build this thing, and that’s what I’ve done.
Alexis: Quickly, what’s the breakdown in terms of what is open source and what’s commercial?
Mike: There’s a lot – I think a lot – of value in the open source already. There is a huge amount. Everything that I described when I initially described Inspeqtor is in the open source package. There is an Inspeqtor Pro; it is almost ready to go. I have the Ubuntu and Debian version ready in its – the Pro version is ready to go. I don’t have a Red Hat, Fedora, Pro version yet; still working on that. But when I introduce this thing next week, I will also be introducing Inspeqtor Pro.
That’s a long-winded way of saying Inspector pro has in it things that would be more valuable to larger engineering teams and features that are not necessarily best practice. Inspeqtor will only monitor things that are started by modern init systems like Upstart or SystemD. Inspeqtor Pro will monitor init.d – old-school PID file-based daemons. It won’t start or stop them; it’ll still use the init.d script to start or stop them, but it can use a PID file to monitor old-school daemons.
Alexis: Alright.
Mike: So if you’ve got legacy daemons, Inspeqtor Pro is the way to go. If you want to send alerts to various, different people in various, different teams, you need to use Inspeqtor Pro. Inspeqtor will only send alerts to one email address.
Alexis: In your three years of doing Sidekiq and in your three months now – I guess, roughly – of doing Contributed Systems full-time, what is one mistake you’d rather not repeat?
Mike: The biggest mistake that I made with Sidekiq Pro was not going to a subscription model initially. Initially, I was selling a one-time fee, so I’ve got about 150 customers that paid 500 bucks one time for Sidekiq Pro. That is revenue that is essentially lost – it’s revenue under the bridge, so to speak, now. That’s 150 customers that I have to support for the rest of their usage of Pro, but they’re not paying me reoccurring income.
Moving to that reoccurring pricing model was the best thing that I did, and that’s really the key to enabling me to do this full-time, is having that more predictable revenue stream rather than just knowing that “well hopefully, people will buy it next month.” If I know that I’ve got $50 or $100,000 in annual income, then I have a lot more –.
Alexis: Stability.
Mike: Confidence and stability, exactly. That was a big one, moving to the subscription model.
Alexis: I usually ask the flip side of that question, which is, what’s one decision that you’re particularly proud of? I think I already know that it is going to the subscription model, but if there’s another one –.
Mike: No, I would say the one thing I’m most proud of is doing these financial experiments in the first place. Everybody in the Ruby world – well, in the open source world in general – they just create these really complex projects which they spend a lot of time on but they make zero dollars off of it.
If you’re building – the way you do open source these days is you either are paid by your company to do open source, or you spend a lot of your spare time doing it. And I think that’s wrong. I think that if you care about that project – I’m thinking of something like a really complex system like Kafka. It’s a really amazing, message queuing, streaming system that is built by LinkedIn. A lot of the core Kafka developers are LinkedIn people, but a lot of people are using Kafka around the world and deriving a huge amount of value out of it. Those Kafka developers at LinkedIn aren’t seeing a dime out of that except for their salaries, and that’s a shame to me.
To finish up what I was saying, I’m proud of these financial experiments that I did where I decided to, say, not only do I want to do this open source, but I want to try and derive value directly out of it, to get paid directly for my hard work. And then I can focus on that thing as a product itself and not as a side effect of my employee at some company.
Alexis: See now is where I would insert a Binpress ad, but I’m not going to do that [chuckling].
Mike: Well I think Binpress is really valuable in a lot of cases. I don’t use you guys because the distribution model does not make sense for the things that I build. At least, that’s my understanding, but I don’t want to sort of –.
Alexis: We have a kind of white label thing where you can post the sales on your own website. I’m not quite sure about recurring revenue, but I can check on that for you.
Mike: Well when I say the distribution model, I mean, I’m selling a Ruby gem. I want people to be able to just change their gem file of their Rails app and, say, bundle, and that the gem just comes down immediately.
In the Ruby world, you don’t download a .gem file and then put it on your file system somewhere; that’s just not done. I had to control my own distribution mechanism, so that’s what I built.
Now I understand you guys are much larger in sort of the iOS space where you’re selling Objective-C libraries where you download and then throw it in your Xcode. That make sense, right?
Alexis: Yeah. I mean we’re trying to expand wherever there’s interest, but you’re right. Right now it’s iOS and mobile development and Android are big slices of the pie.
Mike: Yeah, that sort of distribution model makes a lot more sense. Sidekiq is distributed as a Ruby gem so I have to control that, and then Inspeqtor is distributed as an .rpm or a .deb file. For distribution there, I’m using packagecloud, which is a really nice package distribution system that has a free component for open source binaries, and then also has a commercial side where you can have private packages for your own company. They’re solving the .rpm, .deb distribution problem for me.
In both cases, both of the commercial offerings that I have, I’m having to sort of roll my own distribution mechanism because that’s just the way those types of things are distributed.
Alexis: One final question that I like to ask everybody: what is your text editor of choice? And I think it might be Vim, because I heard mention of it.
Mike: It is. I use Janus, which is a distribution of Mac Vim, that does a lot of – it’s got a lot of Ruby-centric type stuff. Yehuda Katz and Carl Lerche were the two guys that – they go by carlhuda, I think it is on GitHub. It’s kind of a funny thing, but they built this Mac Vim distro, which is very focused on Ruby on Rails development and has since then branched out into JavaScript development, Rust development. I’m not sure how much Go support it has, but I’ve tacked on some Go support also. But yeah, it’s Mac Vim.
Alexis: Alright. Let me slink in one last question here: what is one open source project – not one of your own – that you have your eye on and have piqued your interest?
Mike: I’ve been looking at a lot of Go open source stuff recently, obviously, trying to emulate better projects than mine to find idiomatic code and that sort of thing. Two ones that I’ve been looking at were VoltDB and InfluxDB, which are both different types of databases that are written in Go.
And of course I can’t not mention HashiCorp’s and Mitchell Hashimoto’s various Go-based projects – Packer and Terraform. He’s got half a dozen of them; I can’t even keep track of all of them now.
Alexis: He was on the show a few weeks ago.
Mike: Yeah. I mean, he’s a prolific and an amazing developer, so I’m happy to have him as one of my open source peers.
Alexis: Where can we find you on – where can we find Contributed Systems and Sidekiq on the web?
Mike: Contributed Systems is contribsys.com. The new website will be going live with the product launch next week, so contribsys.com will actually look nice and not terrible a week from now, hopefully. Sidekiq is sidekiq.org, and I think that’s about it.
Alexis: Alright. Where can we find you on Twitter?
Mike: Twitter is @mperham, so M-P-E-R-H-A-M.
Alexis: For us, you can find us @binpress and @alexissantos.
Another one last question; I feel like Colombo here. You mentioned the design of contribsys – you’re totally a developer. Where does this design come from? Do you also dabble in design stuff, or do you hire a third party, or –?
Mike: Oh god, no. I’m the worst designer in the world. I rely on either the kindness of strangers for Sidekiq. Sidekiq’s design was totally done by open source people who just decided to contribute. They were amazing.
Contribsys, since I was a business, I decided I couldn’t very well rely on the kindness of strangers, and so I found a designer and I’ve been working with him for the last month to iterate on some logos, some various designs. He’s also doing the Inspeqtor logo also, so he’s got sort of an Inspeqtor brand and logo that he’s built up. Hopefully it’ll all sort of mesh together and work well.
Alexis: And before I think of another question to take up more of your time with, we will catch the listeners next week.
Oh but before that, I need to thank Derek Carlson for leaving us a fantastic review on iTunes. “Fantastic,” frankly, doesn’t even begin to cover it.
Thank you Derek, and to all the folks out there who I’ve been begging to leave us a review, head on over to iTunes; subscribe if you are of the iTunes persuasion, and leave us a review.
Thanks again for coming on the show man, really appreciate it.
Mike: No problem, thanks for having me. Talk to you later.
Alexis: We’ll catch you listeners next week!
Author: Alexis Santos