Looking at the major events in our lives, we can often trace them back to turning points -- decisions big and small that had outsized effects. In this episode the dudes reflect on some of their major decisions, good and bad.
Full Transcript:
Starr: So I was like, "Okay, we've got no heat now. We're just going to have to slaughter the horses and crawl inside of them or-
Josh: You guys have horses in Seattle?
Starr: Slaughter the neighbor's horses.
Josh: I thought all the horses were in Kirkland.
Announcer: It's like Steve Jobs and the dude had triplets and they built an app. This is Founder Quest.
Starr: I got back the work from the Barney guy. The Barney guy is going to do our intros and it's all pretty great.
Ben: Cool.
Starr: It is excruciatingly difficult for me to listen to it though. I don't know why but.
Josh: Let's just clarify. He doesn't actually sound like Barney. I assume like he is [crosstalk] voices right?
Starr: No, he like sounds like announcer dude. Yeah. He sounds like sort of cheesy announcer dude but it's excruciating. I was listening to these introductions that this guy recorded for us and I'm like, "I have to listen to this so I can spot errors and stuff" but I'm just clenching my fists. I'm kind of in a fetal position because it's so painful to listen to this professional man who has been the voice of Barney amongst many other roles, reading out the really stupid shit I ask him to read. So anyway, I'm sure I'm making you guys feel great about the future direction of this podcast.
Josh: I'm sure it's going to be awesome and I mean by the time people are actually hearing this, they're going to have already heard the announcer. So I guess they'll know whether it's shit or not.
Starr: Oh yeah, that's right. Maybe.
Josh: I mean they can tell us. I guess.
Starr: One thing that I get asked a lot and I'm sure you guys get asked a lot too is how do we do it right? The three of us have this pretty cool little software company. We build things we like. We do it on our own terms. How did we do it? Because a lot of people are interested in doing similar things. So I thought it would be fun to have a show where we talk a little bit about that. So what would you guys think about that?
Josh: Yeah. Sounds good. I mean I think it's just pure blind luck obviously. I don't know about you but.
Starr: Oh 100%.
Josh: I don't know how I the hell I do it.
Starr: Show is over.
Josh: Show is over.
Ben: There may have been a little bit of work involved.
Starr: I guess I should start out and explain a little bit about what we have right? So the three of us started Honeybadger about like, how long ago was it?
Ben: Yeah, we started in 2012.
Josh: 2012.
Ben: Yeah. So it would be seven years old in the summer.
Starr: Oh Man. What grade is that like second grade?
Ben: Yep.
Josh: I just don't. I don't want to see Honeybadger when it's a teenager. I don't know. I thought that's going to be pretty scary.
Starr: Yeah. So seven years ago we set out to build this app to monitor our web apps for errors. We were using an old service that does a similar thing called Hoptoad. Eventually turned into a thing called Airbrake and it just wasn't doing it for us. It had a lot of problems. It had a lot of service degradations and we eventually just kind of got fed up and decided to build our own thing and fortunately for us, a lot of other people were thinking the same thing. So we had a lot of early customers out the gate who were Airbrake customers originally and looking around for a more stable replacement that was being actively developed instead of just kind of milked like a cash cow.
Josh: I think one of the things that we did, I mean that kind of just came naturally is that we were solving our own problem or I guess they say scratching your own itch, but it was something that we really wanted ourselves and that was a big in doing it in the first place. I mean we did want to build a product and sell it but we also really had this need that we wanted to solve for ourselves and we kind of did that. That was the initial motivation, how we chose what to actually build in the first place was we used ourselves kind of as guinea pigs.
Starr: Yeah, because we were like freelancers for a long time and we weren't really in the same company, but we worked on similar projects and we all used Airbrake. Actually at the time that we started on Honeybadger Ben and I were working at another company as employees and we used Airbrake then too and it was just not doing it for us.
Ben: Yeah. I think the thing about scratching or itch is you can have a lot of itches, right? And there are some that are more interesting than others and some that are more painful than others. And you've heard that phrase like, "Is your product a vitamin or is it an aspirin?" Right? Is it solving a real pain or is it something that it's kind of nice to have and I think one of the things that made a difference was we felt that Airbrake was a painful experience. We were really pissed off about how the service had degraded and we decided that we had to fix that. So we felt the pain keenly. It wasn't just, "Oh, it'd be nice to have this thing". It was like, "We gotta have this thing".
Starr: Oh yeah, totally. I remember this and this, you might say that one of the things that set me off being interested in Honeybadger was a mistake on my part. I was having trouble with Airbrake. I was having an issue and so I posted a question on their customer service forum which was literally the only way to get customer service. And maybe a day later somebody responded and it was kind of a flip, non-response answer. And that just made me so angry that these people who I'm paying or my boss is paying I guess are writing me off like this and not even giving me a decent customer support answer and it was only a couple of months later when I went back and realized, "Oh man, that was just another customer". They were in the same boat as I was. That wasn't even Airbrake support but I guess if they would've really had support in the first place, that wouldn't have happened. So it's still their fault. Screw those guys.
Josh: Yeah and I mean it's too bad because I mean I think part of the reason why we were passionate about this thing in particular too was because we were such big fans, at least I don't know about you guys, but I was. I was a big fan of Airbrake for a long time since Thoughtbot had originally started them and stuff and they were acquired after that, which I think was the turning point but I was a huge fan of their and it was incredibly useful to me which made it really hurt when it started to stop working and there were ... you'd have errors coming in but you're not getting notified or you're not getting the details that you need and at the time I was still freelancing, so I was having my clients pissed at me and stuff when their apps would stop working. So yeah. I felt pretty strongly about the fact that it wasn't working like it used to.
Starr: So yeah. We had a bunch of people in the same boat as us and I just remember having this moment where I thought, "Okay, we have to build a competitor to this because it sucks. There's so many people who want it. We have to build it right now". So from then on, I think it was kind of like a mad dash. It was me and Ben at first who were going to do it because we were talking all the time. We were taking lunch breaks together and working together at this other company and so we started working on it and then Josh was in the Campfire chat room that we used and I think-
Josh: Because we just never left.
Starr: Yeah. We never stopped hanging out in the same Campfire chat room. Yeah. It was such a small start up that Ben and I were at that there were no other developers to talk to. So we had to talk to somebody right?
Josh: So you had to talk to Josh.
Starr: Yeah, we had to talk to Josh. Why else would we want to? No.
Josh: Yeah. I think your biggest mistake was actually talking about Honeybadger in the campfire chat room because if you hadn't then I would've never forced you to let me build it with you.
Starr: I don't know. I think it's been a net positive.
Josh: Yeah. I think so.
Starr: I think you've pulled your own weight.
Ben: Yeah. I'm just basking in the memories. You've gotta pour one out for Campfire. I mean, but I remember when we got started and we just had too much to do right? And so we said, "Oh, let's hire Josh to do some stuff. He's still freelancing. We'll pay him" and Josh declined and we were like, "What? What's the deal?". And so-
Josh: Yeah. I was like, "Oh, no".
Ben: And so I turned to Starr and I'm like, "You know what Starr? If he doesn't want to get paid and he wants to be a founder, he wants to join us. So let's cut him in on it" and so I mean that's an easy decision. So that was awesome. I think that has been great. Having the three of us has definitely made it possible to do it. I realized that there are certain levels of problems that you just can't take on. To take on certain kinds of businesses you have to have a certain number of people, right? You have to have a person who can do x, y and z and there are plenty of businesses that you can do by yourself and there are other [inaudible] of business that you can't and I think had Starr and I just done it by ourselves, I think we wouldn't have had the success because I think we needed those three opinions, those three voices, those three contributors to the project.
Starr: And plus man in addition to what you're saying Ben. I love you dude but you and I would have just murdered each other at this point.
Ben: Yeah.
Starr: I think Josh has been a good influence.
Ben: Totally. Yeah, I think that's something we've talked about before and definitely having the three people and the different personalities that we have definitely helped smooth over differences that we've had as we built product.
Starr: Yeah. It's nice having a tiebreaker.
Ben: Yeah and it's nice having someone as easy going as Josh.
Josh: Yup and sometimes like ... well, I was gonna say I feel like I do end up kind of being a tiebreaker a lot but sometimes it changes too. It's nice to always have a person that is kind of, if the two people have a disagreement, the third person can jump in and try to understand where both sides are coming from and try to smooth that over or whatever. At least that's how I've tried to look at it over the years and yeah, I think it's worked out pretty well.
Ben: Yeah, I think so. Yeah I've always been, I guess amazed that we have an ownership structure of the company that's a third even right? All of us have a third of the company. It's 33.33% and you always hear stories of someone has to be in control. There has to be like a 51/49 kind of thing so someone can make the decision and we made it work with that even Steven probably mostly because of Josh helping us get along.
Josh: Yeah. I think that us all being equals has been a really big, a really important factor in that and I'm personally a strong believer in equal equity splits. At least in serious partners for that reason. I just think it helps avoid a lot of jealousies and it helps you, at least even in your own minds, be on equal footing as peers.
Ben: Yeah. A question I've gotten several times is with three founders who are all developers, how does that work? How can you have a business? And I think that one of the key advantages that we've had is that we can all contribute equally because we all are three developers. No one feels like, "Oh he's not doing anything" or feels like, "I can't contribute right now in a way that's useful". Plus we're all business-minded and I think that's what saved us. If we were just three developers who are just writing code all day long and that's all we like doing, then we would have flopped because we would've never done the required marketing and stuff that you gotta to do to make a business work. Being freelancers beforehand, we knew you have to do some sales in order to get business and we weren't allergic to that.
Starr: I'm still struggling with that one.
Josh: Yeah, well it's a learning process but yeah, I agree Ben. I mean I don't know about you guys. The reason I was freelancing in the first place and I freelanced pretty much my entire career. I was freelancing over 10 years by the time we started Honeybadger was the fact that I was interested in creating a business and it took me a while to figure out how to actually do that but that's all part of the process too. So yeah. If I was just looking to just be a developer or just do development, I probably would have had more jobs but I think that kept me ... I always wanted to start a business and solving business problems has always been really interesting to me.
Ben: I was just going to say, the short version is if you just want to be a heads down developer, don't start a business.
Josh: Yeah because I mean yeah, best intentions. You just can't. There's so many things that you have to do and it really helps if you like to do that stuff.
Starr: So here is a fun idea guys. If Honeybadger is a home run, how many non home runs have we had between the three of us? Personal, together, it doesn't matter.
Josh: That's a good question.
Starr: Personally I can think of three, maybe one of which was shared with Ben.
Josh: Yeah. I probably got a couple under my belt at least.
Ben: I guess my number would be like four or five, maybe six, depending on how you count.
Josh: Yeah, Ben has been doing this a while.
Starr: So between us we've got at least 10 projects that were not as successful as Honeybadger before Honeybadger.
Ben: Right.
Starr: That's something. That's something to think about huh?
Ben: That's a [inaudible] right there.
Josh: Yeah, that's experience. Yeah. I think in some cases you have to have that experience before you can really find the one that works.
Starr: So we made a good decision we already talked about by deciding to enter the market when we did. We focused on Rails. We focused on a group of people who were very unhappy with their current situation and were actively looking for something new. So what other turning points do you think there were?
Ben: One of the things I think you mentioned briefly, but I just want to dive in a little bit on was you mentioned paying customers. There was a product already in the market that people are paying for right? So you weren't just building something out of thin air and just hoping people would come to it right? We already knew there was a demonstrated market for that particular product and so we just took something that was existing and we improved upon it. We added better customer service and we added better functionality. So I think that's a key.
Josh: Yeah and Starr kind of alluded to it but we did highly focus on a niche market at the time. I think that was the first big thing we did and I don't know if we did that, I don't know if that was our genius that led us to that or just the fact that we didn't have the resources to pursue the entire market but I think focusing on Rails and Rails developers, which we are, we know very well and I think it allowed us to, even from a marketing perspective, speak to that group of people a lot better than we could have if we were trying to just be an error tracker for web applications or something.
Ben: Yeah. I remember that helped Starr keep the product really focused right? Because I remember he could make decisions that were just perfect for a Rails developer that may not have worked as well if we tried to sell to every developer on the planet but focusing on that small market, that small group of people was one of the lessons that I learned from one of those five or six not so successful side projects that I'd done before. Catch the Best I built starting in 2007 and it's still running but it's not making a whole lot of money. It's just a little cash machine but one of the mistakes there was trying to go after a really big market. Like small to midsize businesses you are hiring right? So I learned from that. Focus. Focus on a very small market and you can make a lot more noise in that small market.
Starr: Yeah. I think the best decision that we made was choosing a market that one, existed and two, we could talk to in a way that was a cost effective for us and was welcomed and appreciated by the market. Like with your Catch the Best example, the market is really big and so it's really difficult for you as a solo developer to go and talk to that market as a whole. How do you even start to do that? That's the sort of thing that people have enterprise sales teams to do but as Ruby developers, we knew how to talk to Ruby developers and we ... man, at the time there were like 50 Ruby conferences in the United States. So we just went to all of them and at the time it was like you would talk to people and you would say, "Oh, we're making an Airbrake replacement" and people, their faces lit up like you were their savior. They were so happy to talk to you about this.
Josh: Yeah. If we had say pulled a product out of thin air for just a large market that we didn't know as well, we probably wouldn't have even known that they had that problem in the first place. So understanding them that well gave us the specific knowledge of what they actually wanted and needed at the time which helped that it was also what we wanted and needed. So.
Ben: Yeah, that helped I think too with my deciding what was going to be in and what was going to be out of the product. Being able to scratch your own itch, being the developers that we wanted to serve, we could say, "Oh, this feels good. This feels like it should fit in the product. I think other developers will like this" and then we added later on a bigger expansions like uptime monitoring and check ins. It all came back to like, as a developer, what do I care about? I care not just about my errors happening, but I also carry that my site is up right? And I care that my [inaudible] are running. So being customer driven is easier when you're your own customer.
Starr: Yeah but that also led us to one of our big canards I think. You might call it a mistake. I have the privilege of being the person who I think was most in favor of doing this and then the person who suggested getting rid of it.
Josh: I don't know but I was like, I may have been the most excited about actually ditching it.
Starr: I just realized I haven't said what we're talking about. We're talking about-
Josh: Metrics.
Starr: ... metrics.
Ben: Sad, sad metrics.
Josh: APM. Rest in peace metrics.
Starr: So a little bit of a background information on this. So we started out with our product doing, well, only exception monitoring right? Your application throws an exception. We catch it, we let you know about it and that works great. That's still the majority of our business and then later on we started adding other features and the first, I think this was the first extra big part of the app that we added was metrics, sort of a New Relic thing. There's lots of apps that do this now and it's huge business but we ran into some problems because, well, there are whole companies to put into this, right? And we're just three guys. We were like the dog who chased the car and we finally caught the car. It's like, "What do we do with it?".
Josh: Yeah.
Ben: Yeah I think it was one of those classic, it was a good idea at the time. We thought there were so many people who were buried in the complexity of New Relic for example, and they just wanted few things. They just want to know what the performance, how many requests are you getting? And so we thought, "Well, if we could just build that 10% or that 20% solution, wouldn't that be cool?". And it was until it wasn't.
Josh: Well, it was just too much for us to handle at the time I think and I think we've joked about even bringing it back someday and I'm never saying never on that. If we have the people to do it, that's fine but I think to do it even up to our standards, even to address that 10% that you talked about well, we just didn't have the time to be able to do it right and I think that because we're kind of perfectionists in our own way, it drove us crazy that this thing wasn't really fully up to our standards and that's kind of what led me, that was the big thing for me when I was thinking about just pulling the plug on it.
Starr: Yeah. So we ended up with a metrics feature that works but not a ton of people used it. I think we did some analysis on that and we found that maybe fewer than 10 people actually use it, but it ended up contributing, what was it? It was more than half of our server usage was just handling metrics.
Josh: And just development time too because, I mean to collect that data you have to be able to collect it on every single platform we support, which means modifying every client package that we have to be able to do like application performance metrics, which is like diving deep into framework code and stuff and pulling out numbers which is a lot of work. So New Relic, for instance, has a multi-person team to do that just for Ruby. So us doing it with one of us dedicated to that task was kind of, yeah, it was starting to become a problem I think.
Starr: Yeah, so eventually what happened was we decided to look into dropping it. Then we did some research. Found out that only a handful of people were using it. We emailed them. They weren't too sad to have it go away. So we dropped it because it was ridiculous the amount of effort and money we were spending on this thing.
Ben: Yeah. I think in the end there were a grand total of two people who were sad that that feature went away.
Starr: I know all that work. All that work for two people. What could we have done different? With our main product, the exception tracking, we built that based on a need that we knew existed but with the performance monitoring, we just built it right? We didn't really get a ton of feedback from users. We didn't have people calling us saying, "Why don't you add this to your product?" Or, "I just can't wait to get rid of New Relic". We just assumed that people would be interested in it.
Josh: I was thinking earlier as we were getting into this, one of the big decisions that I think we made early on was to focus on our customers and I think that's something ... a lot of the features that we added to Honeybadger shortly after we launched with an MVP, a lot of them were customer feature requests and a lot of the things we've continued to add to the product have been pretty much entirely customer driven and so I don't know. Maybe this is one area where we dropped the ball on that and maybe that's why we were seeing, it didn't quite take off like we hoped it would.
Ben: Yeah, I agree with what Josh is saying that I think this is one area that we weren't as customer driven as we had been with all the features. Like, "This is something that I thought would be cool and so let's build it" and our customers just weren't that interested in it. So, yeah.
Starr: Yeah. I mean to be fair, we all thought it was cool.
Josh: Right. I was into it. I mean for the record. Yeah, it is cool. It's just, yeah, there's a lot of things that are cool though.
Ben: That's true. Well, my philosophy about business is it's just one big experiment. Nobody has it all figured out, right? And every business is different and you just learn as you go. That's part of what you do as a business.
Starr: So you're talking about experiments. Another experiment that we did recently, maybe a year ago was that we switched to meter billing and that worked out in a big way for us. Let's talk about that for a minute.
Ben: Yeah. Well that's almost two years because it was summer. Yeah summer of 17.
Starr: Two years ago?
Josh: Is it?
Ben: Yeah.
Josh: Wow.
Ben: Yeah, that was a great call. We started initially with unlimited traffic. That was a big thing that Starr wanted because one of the things that really irked him about Airbrake was how they limit you on number of errors per minute. From a developer standpoint, you're thinking, "I'm having the worst day of the year when my app is falling over because all the errors that it's getting. The last thing I want to worry about is I'm going to go over quota on my error tracker. So now I can't even see what's going on in my app?". And so we resisted that and that was a great decision I think for the initial part of the business but then over time it just got too much for us to take on. I think we saw too many customers who were making hardly use of that unlimited allotment. And the-
Starr: It's like economics. It's when you make something free, people who need that thing gravitate towards it, right? So we ended up with a lot of customers who were really sending us tons of errors because we were the only company that wouldn't bill them thousands of dollars for receiving those errors. We ended up with a lot of really big customers sending us a ton of errors and paying us what? 20 bucks a month?
Josh: We're such nice guys.
Starr: I know we're such nice guys.
Ben: We're softies.
Starr: And oh my God, we rang our hands over this, didn't we?
Ben: Yeah.
Josh: Mm-hmm (affirmative).
Ben: That was one of those rare disagreement things, right? Because we just did not, could not really agree on how to proceed and finally we just said, "Well, let's just try it". That was the point I think in the business where we decided, "You know what? Let's just stop talking about stuff and let's just try something and if it doesn't work out, we can just roll it back". And I think that definitely involved some nail biting but in the end it's been awesome for the business and I think it has-
Starr: If you recall, it almost didn't, it's not that it almost didn't work out but there was definitely a roller coaster ride there because the first thing that happened after we implemented metered billing, because we didn't make everybody upgrade to it, only the people who would be paying less money under metered billing upgraded to it. Only the people who were on our larger plans that let you set up lots of projects, moved over to the meter billing because you had unlimited projects. Whereas the people who were paying 10 bucks a month and sending us millions and millions of errors, they're not going to move over to metered billing so fast. So revenue started dropping and it really freaked me out personally. It really freaked me out.
Josh: No, it was scary. Yeah, that was one of the scary times in the business, I would say.
Starr: Yeah but then we had a meeting. I think the thing that turned it from a scary downhill ride to an exciting uphill ride is that we decided that, "Hey, we just really need to ... if we're billing people based on their usage, we really need to enforce that" because again, we were being nice. We were saying to people, "Okay, you went over your errors but we're still going to let you send us as many errors as you want but we're all adults here. Please pay us the amount of money that's appropriate to the amount of errors that you're sending us" and people just didn't do it. I mean I'm not saying they're dishonest. They're probably just busy and didn't have the time to think about it. But yeah, nobody was doing that. So eventually we just had to say, "Okay, you're sending us too much errors. We're going to give you lots of warnings. We're going to give you lots of information about it so you can plan better but eventually we're going to have to cut you off guys".
Josh: I think the way we've solved it and the way Ben has solved it really is still a lot nicer than a lot of the other options that are out there on the market too. We're pretty generous, I feel like in how we do it, but it's enough so that it's equitable. We're not getting the short end.
Starr: Yeah and we managed to develop a system that lets people send us sort of spikes of errors and stuff like that, that is fair to people in cases where they're just having a bad day but that charges more to people who legitimately send us consistently more traffic. So I think we ended up with the best of both worlds.
Ben: You know talking about experiments, one of the other experiments that was interesting and I guess one of the nature of our business is sometimes one of us gets very interested in something and the other two just don't care that much about and so that one person just goes off and does it right? And the other two people are like, "Yeah, we'll support you but good luck with that" right? And I think one of those things was GDPR. I remember being very interested in GDPR when I started learning about it. I'm like, "Oh, we gotta do this" and I remember Starr was like, "You know what? I just don't care" right? "You want to do that? Go right ahead". Now I may be remembering that incorrectly. You can correct me if I need to Starr bur-
Starr: In the beginning at least I sort of lumped GDPR into the whole corporate certified compliance. There was tons of these certifications have long acronyms that basically you have to jump through all these hoops to prove that you're trustworthy to be used by some sort of enterprise company and they just seemed all so much BS to me. I guess we should say what GDPR is in case people don't know. GDPR is a, I don't know if it's the name of the law or whatever, but essentially the European Union is saying that companies have to provide certain guarantees to their users, to their customers about the data they collect, about their online usage and stuff.
Starr: People can ask the companies to provide a log of whatever information they keep and to delete that log. There was a whole right to be forgotten and stuff in it and we as a service that captures errors for people sort of end up right in the middle of that, right? Because we're actually logging information about people's users and those users might live in the European Union and so they might be able to contact our customers and say, "Hey, I need to know all my information". And then those customers have to be able to get that from us if we have it. Also we need to make sure that we're not doing things that are just kind of verboten which is just things like logging people's IP addresses and keeping them around forever for no real reason and stuff like that.
Ben: So it was a good chunk of work and it was definitely a headache dealing with the legal side of it but being able to choose what we want to work on, even if that thing isn't so much fun that day, I think it's a great way that we've enjoyed running our business.
Starr: There's new regulations coming down the pipe from California, right? I forget the name of that. Do you guys remember?
Josh: The CC something. Yeah. Ben probably knows.
Ben: Yeah. It's got a bunch of C's in it. That's [inaudible] remember.
Starr: But it's going to be essentially like the GDPR but for California residents.
Ben: Yeah and like with car emissions, probably what California does is what other states are going to end up doing. Right?
Starr: Exactly. So privacy is a huge deal and it's going to become even more of a huge deal. In these frameworks, in these privacy frameworks you really need to have complete control over the data that you're collecting for people and you have to get people permission to opt in if you're sending their data to a third party service like Honeybadger. So this kind of leads us, we've been talking a lot about open-core. We've been talking a lot about self hosted apps because we're wondering if maybe self hosted apps are going to make a little bit of a comeback, right? Everything's been moving to the cloud to software as a service type models but if you have to be super strict about where you send your users' data, that's really something in favor of running your own infrastructure, isn't it?
Ben: Yeah. It's simplifies things quite a bit. I think one of the things that we discovered in that GDPR process was that you have to have that chain of responsibility all the way down to all the other providers that you're using. So like in our case, we use Google Analytics, right? So we need to have that agreement in place with Google which of course is just a very simple form that you fill in because they deal with so many, but you have to have that with every provider that's touching that data that you're handing down. Whether it's your user data or your customers' use your data. So being able to say, "Okay, this set of data we know is under our control. It's not going anywhere". It's definitely helpful for complying with those privacy regulations.
Starr: Exactly and it's my understanding that say, if you have a user who opts in to tracking with Google Analytics or whatever and then you want to switch to a different analytics provider that's run by some other company, you've got to get that user to re opt in essentially whereas if you switch to an analytics platform that you're running on your own hardware, that you're running yourself, you don't have to have the user do anything because that's just considered your company still. Yeah. So that's really interesting. I think we've been interested in open-core stuff recently. It's really fascinating to me to see how a certain companies have been able to leverage this idea that the core of your software is open source so people can install it, they can distribute it freely, they can do whatever they want with it and for a small team like us that seems like a really attractive model if you can build something that people legitimately want because yeah, because we just don't have the resources to go in and do marketing enough to own a market.
Josh: It allows a lot more community involvement I think because the core, a large part of it is open source and people can take it in and use it and then contribute to it as well. So I think like there are a lot more opportunities for things like community building or the entire construction of it becomes a little bit like a marketing type of thing too. Like where you can engage with the audience too as you build it.
Starr: Yeah. It kind of takes on a life of its own almost. Yeah. If you're building a product out in the open, you can talk to people about it the whole time. You can get people's feedback, you can get them to contribute. Whereas if you build something behind closed walls and then you get it done and you release it into the world and nobody has heard about it, that's a real uphill battle that a lot of, I mean, most companies face and it's really hard to get over that.
Josh: So what are we talking about here? I think what we're saying, we're interested in these directions. I think we're kind of interested in building additional products within our company I think is what we're getting at and these are kind of models for thinking about what that might be. Is that kind of what we're saying here? I was just going to say kind of like to tie it all together with kind of the open-core model of distributing an application, we think that kind of ties in back into some of the privacy regulation things that are coming down the pipeline where in the future it may make a lot more sense that it has in the past even to run certain types of applications on your own infrastructure. Open-core is a good potential way to do that and so we're kind of exploring technologies that can like be distributed along those lines.
Starr: Yeah. That's why Erlang is so interesting to me personally. If you're going to distribute a Rails app for people to host on their own hardware, not only do they need to be able to run the Rails app, they have to run a database. They've got to probably run Sidekick. They've got to run Redis. Maybe they've got to run Memcached. If they want WebSocket, they've got to run a WebSocket server.
Josh: Right? Yeah.
Starr: Yeah. So in Elixir you get all that stuff kind of baked into your application. So if you want to distribute a single executable that has all this functionality baked into it, then that just seems pretty awesome to me. Yeah, also with the way that Elixir does packaging or I guess the way the Erlang does packaging, you can distribute your app as a single self contained package. You don't have to do what you do with like Ruby, which is you download Bundler. Then you have Bundler install a bunch of things and hopefully they don't collide with any of the other things that you've had installed by other Bundlers on your system.
Josh: And all that ties in, like you get a lot of this from just features of the language, but all of this revolves around the fact that it's in a virtual machine. You've described it like you're basically, you have an entire ecosystem that you don't have to call out to other services.
Starr: Yeah. A lot of languages have their own VMs but beam is a lot different because it's set up to run different bits of code as sort of standalone processes and they can interact in ways that is very similar to servers interacting on network. Yeah, so I've said before, it almost feels like you're programming and almost as like a serverless environment. Like programming on AWS where you just reach out and throw something in cache or throw something in database. You can kind of do that just inside Elixir or Erlang itself. Anybody else want to add anything, any final thoughts?
Josh: I don't think so.
Starr: All right. I'll talk to you guys next week I guess then.
Josh: Sounds good.
Announcer: Founder Quest is a weekly podcast by the founders of Honeybadger. Zero instrumentation. 360 degree coverage of errors, outages and service degradations for your web apps. If you have a web app, you need it. Available at Honeybadger.io. One more from the founders. Go to founderquestpodcast.com. That's one word. You can access our huge back catalog or sign up for our newsletter to get exclusive VIP content. Founder Quest is available on iTunes, Spotify and another other purveyors of fine podcasts. We'll see you next week.
S1E3