The Changelog: Software Development, Open Source - ngrok and Go (Interview)

Episode Date: July 9, 2016

Alan Shreve, creator of the beloved ngrok, joined the show to talk about ngrok — what it is, why it exists, why he wrote it in Go, and ultimately why 1.0 is open source but 2.0 is not.

I'm Alan Shreve, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 210, and today Jared and I talk to Alan Shreve, the creator of the beloved Ngrok. Everyone I know uses Ngrok. We talked about what it is why it exists why he wrote it in go and ultimately why 1.0 is open source but 2.0 is not our sponsors today are rollbar and toptow our first sponsor of the show is rollbar rollbar puts errors in their place full stack error tracking for all applications in any language. And I talked to Brian Rood, the CEO and co-founder of Rollbar, deeply about what Rollbar is, what problem it solves, and why you should use it.

Take a listen. How do you build software faster? Like, how do you build better software faster? And there are tons and tons of aspects to that. And Ruby is like, you can have a better language, you can have better frameworks that help you be more expressive and more productive. So the flip side of that is after you've built something that works, or at least mostly works, how do you go about getting it from working

to in production and actually working? How do you cover the edge cases? How do you find things you missed? How do you iterate on it quickly? And that's kind of where what we're trying to do comes in. So we're trying to say, after you've shipped your software, you're not done, there's still work to do comes in. So we're trying to say, after you shift your software, you're not done. There's still work to do.

And we want to help make that process of maintaining and polishing and keeping things running smoothly be really, really, really easy. So developers spend roughly half their time debugging, right? So anything we can do to make that process better is going to have a huge impact. All right. That was Brian Ruse, CEO and co-founder of Rollbar, sharing with you exactly why it fits, why it works for you. Head to rollbar.com slash changelog. You'll get the bootstrap plan for free for 90 days. That's basically 300,000 errors tracked totally for free. Give Rollbar a try today. Again,

head over to rollbar.com slash changelog. And now to the show. Hi, we're here today talking to Alan Shreve. Now, Alan, he's made this thing called Ngrok and a bunch of other stuff. And Jared, we use Ngrok every week when we ship ChangeLog Weekly. That's right. Where did this topic come from? Obviously, we use it, but where else? That's basically where it came from.

So, I've been a fan of NGRAD for a long time. There's lots of tools that do similar type things. This one seemed to be a cut above to certain degrees in certain ways and just really appreciated it. Also noticed that it's gone through multiple versions and used to be open source and isn't open source anymore. So I thought, hmm, this could be an interesting story here. And we almost didn't have it on because of that. Yeah, we had a little bit of a debate and asked our members what they thought about it in terms of, you know, is that an interesting thing or not? Which the consensus was, well, let's

get Alan on and talk to him about it and find out what happened and see if it's interesting. So Alan, thanks so much for joining us. Thank you so much for having me. And thanks for the really nice intro. It's always a pleasure to hear about people who enjoy the software that I make. So, we'll obviously dive deep into ngrok. And like I said, we fire up ngrok at least once a week. I do, personally, to ship our weekly email but you know one thing we

like to do is figure out where where our guests come from so obviously you've got a lot of interesting things happen around ngrok you are a fan of go which we talked about our our go podcast called go time but uh take us back further like help us get to know who you are what what got you into software development it was it was kind of serendipitous uh how i got into software actually um my uh it started uh when i was going to high school actually i our our high school had a requirement that you had to take one uh computer literacy class because you know computers, computers were the up and coming thing at the time, right? Right, of course.

We wanted to prepare students for the future in addition to typing, of course, right? So you had your choice of a couple of classes, and one of them was a class that was called like, I don't know, it was like,, it was essentially how to use Microsoft Office. And so I actually picked that class, because I figured it would be easy, because I knew how to use Microsoft Office. And so I figured I would have to do no work to actually do that class.

And my best friend at the time, uh, when I told him that after I came out of the first class, he was like, what are you, what are you doing? You're like wasting your time in that class. Like come take programming with me. Um, so yeah, I listened to him and, uh, joined the programming class and, uh, like instantly fell in love with it. So I really owe a lot of it to him. It just seems like an unusual way to get into it. So obviously we all listen to our friends, but Microsoft Office, I mean, really? Yeah, I mean, that wasn't the title of the class, like how to use Microsoft Office.

It was like computer like business applications or something. But I quickly realized what it was the first class that I went into it. And they were like, create a PowerPoint presentation with three slides, something simple like that. I gotcha. I can recall feeling cool putting microsoft office on my resume at one point in my life really oh yeah of course like way back in the day when i had no understanding of course right yeah proficient with microsoft totally yeah i mean i can i can type nothing hardcore good stuff so i went i had a little bit of a similar path in college. So I went into MIS, which is management information systems, which is basically watered down computer science with some business stuff floated in there.

So I very much had like the intro to Microsoft Office type of a course. And it was just the most boring, worst, just terriblest thing in history. So I'm curious to find out how you started from there and then actually continued in towards, you know, writing software and not just switch careers at that point. Oh, yeah, I guess what I, um, I'm not sure if I explained it correctly, but basically I was in that class and my, my friend told me like, you're wasting your time in that class. So I transferred out of it, um, and into like a dedicated programming class instead. Um, to like satisfy the computer literacy requirement that we had in high school.

Um, and so it was in that programming class that, uh, I actually started to learn how to program, to program on Turbo Pascal to start with actually. Wow. Yeah. Turbo Pascal. What's the difference between that and Pascal? It's faster. It's faster. It's turbo mode.

Yeah. Have you guys ever used Turbo Pascal? No. No. Visual Basic I think was my intro and then straight into Perl and open source from there. Have you guys ever used Turbo Pascal? No. No, Visual Basic, I think, was my intro. And then straight into Perl and open source from there. And a little C and C++. Turbo Pascal is an interesting environment. It's really, really well suited to beginners because it basically had this really distinctive user interface too.

It was just like this blue screen with yellow text for the code, by default, at least. I never bothered to learn how to change it. So it felt very, I don't know, I guess it felt very 80s or 90s before my time felt, I guess. It was just this whole environment that it took up. It was, yeah, so it was just this whole environment that, like, it took up. It was, like, a full screen mode by default. It wasn't, like, in a window or anything.

So you're just kind of, like, immersed in the code. And then when you ran the code, there were, like, two options. One was, like, run the code, and it would, like, print to, like, a console window, like, what was coming out of standard out. And the other mode that it had was a debug mode where it basically just fired immediately into a step-through debugger with this big yellow line or big, I don't know, I don't remember what color it was, that highlighted the line of code that was executing. And it would just step through the whole program for you,

which as a beginner, having to never like learn any like i didn't have to worry about source control or have to learn how to organize a project or have to learn what a compiler was like it was just a a full environment where there was a run button and a debug button which was just it was really great uh to start out with take us from there to go and ngrok oh man there's a lot of stuff in between that well hit the island um yeah i mean i finished uh like i finished doing the programming course in high school I eventually like after I learned Pascal I learned C and then

kind of working the most basic knowledge of C++ not how to use it well of course but like how to define a class and stuff like that I kind of actually lost track Not how to use it well, of course, but how to define a class and stuff like that. I kind of actually lost track of programming for a couple of years before I got an internship working at a local software firm. My first job actually was interning for this local software firm that, no kidding, made Fortran compilers. And they still make Fortran compilers to this day.

Wow. Yeah. It's one of those things where you're like, wow, someone still does that as like their only line of business. It's crazy. Yeah. So I started there. I actually wrote about it recently when I was launching Equinox.

But I originally started there as an intern where I was actually packaging the software, which at that time meant physically assembling boxes and burning CDs and printing CD labels and stuff like that. Duplication, stuff like that. Yeah. What was it about that? Package managers that we talk about today back then it was like a you know

some tape and some cardboard right yeah i was the package manager that's a whole different version of it for sure i know right um you said you got lost from programming what what happened to get you lost and why did this internship pull you back? Yeah, I got kind of lost because, um, in between like finishing like the programming course and starting, uh, that job, which like in that job, I eventually like transitioned to writing code for them instead of just packing boxes. In between that, I had kind of outgrown what my instructor could teach me. And resources on the internet for learning how to code and going beyond what I had learned weren't nearly as good as they are today.

I mean, they're fantastic today. But it was really a struggle to find, not that there were no resources, but it was difficult to find like the next step. I always ended up finding things that were below my level or like way above it. And I couldn't find like materials that would get me like, that like understood what I already knew and could push me like gently into new things um so that was

that was actually kind of frustrating um so I kind of lost track of it uh for a couple years um while I was sorting that out I remember I bought a book on Visual C++, which was a horribly misnamed book. It was actually a book on how to write Win32 GDI applications. So I made my own paint clone. But it explained nothing about the underlying model of it. It like now you have to send a wm paint command and i was like okay i'll type the w like the code to like send a wm paint command i do not know why i'm doing this um yeah so that that was like it was just a very frustrating time so you still haven't gotten us back to go now so keep going we're we're following the path we've we've hit your internship you're met you're a manual package manager you're getting back into software keep

going so i actually started i wrote i started writing code for uh for that um company um and then i i went to college i studied uh computer science at college so i did a lot of um a lot of programming during college um and it it kind of took off from there um yeah i i don't know uh after like during college i did uh a number of internships like trying to find the kind of company that I wanted to work for. So I went through a couple of companies. I interned for VMware and Microsoft and Fog Creek. And I ended up learning essentially that the company that I, the ideal company that I wanted to work for was a company that was small. I didn't really enjoy being part of the giant corporate environment. But also one that was tackling really difficult technical problems.

So I was looking for some combination of small but very hard technical problems, which is not always easy to find. It's a lot easier to find now. But at the time, it was not super easy to find. So you interned at VMware and Fog Creek? Yeah. What was the kind of things you were working on at VMware? What year was that, roughly? VMware, I interned at VMware for two summers.

Those were my first two years of college. And I was working on the QA team for what they called at the time Virtual Center, but has now been rebranded into something as part of vSphere. i honestly don't know because they've changed the branding so much of course yeah so i was working uh doing qa for them um like building essentially like automated test harnesses that kind of stuff and then i did the next summer at microsoft where i got to work on the Windows 7 kernel. I actually worked on the diagnosing performance issues in the file system driver stack. And then I kind of transitioned away from that entirely, like interning at Fog Creek, where I actually helped them build the very first version of Kiln, which is like

their GitHub equivalent for Mercurial hosting. I ask that because you say that you like small companies with difficult problems and VMware is nothing like that really. Maybe you were on a small team or something, but maybe you found out what you didn't like

about a big company tackling, I guess, a hard problem too because yeah i mean that uh that intern like going through those internships was really like the learning experience that brought me to that like understanding before i really didn't know what i would enjoy um but like doing all of those things um was really helpful to like learn what it was that I was looking for. Those are fairly well-known names too, like household names, so to speak, at least for us, you know, when it comes to an internship, I think I'm camping on these questions and I know we're trying to get to your, your experience with go and how you got there, but I'm thinking like for the listeners after thinking, you know,

I want to get established somewhere, maybe a similar path that you're taking, you know, these are household names, so so to speak you got an internship there what was the process like or how did you go about getting an internship was it just that easy from a college standpoint like they made it accessible or did you have to like uh you know put you know kind of audition so to speak what was that like I mean, maybe how also how important that was, I guess you just said so, but how important that was to where you're at now. That's hard to say. Right. Um, but I, I think certainly it was important for me. Like, uh, I always felt, um, like having those things on my resume was really valuable. Um, as how I got those internships, yeah, we had career fairs at

college. A bunch of companies would come and you would talk to them. VMware had a booth there that I went and talked to. Part of it, of course, you know, nothing is always that cut and dried. Like part of it was kind of that my friend's brother worked at VMware at the time. So I had an in there. Nice. And so he was, you know, able to help like take a chance on me, um, which I'm, you know, internally grateful to him for, you know, sometimes lots of times. Yeah. And, uh, the other internships, I don't know. Uh, one of my friends interned at Microsoft, uh, one of the

summers and was like, you should try it there there like i had a really good time so that uh he like introduced me to those recruiters it's a good sales pitch i'm gonna try that yeah right um fog creek was the only one that i kind of went into blind where i just applied blindly to them um and they're like probably the smallest team sorry uh they're probably the smallest teams of those teams like i mean microsoft's huge vmware's huge tulio was small now they're bigger um you know that wasn't in your mention of internships but it's on our list of where you where you've been before but then fall creek seems to be maybe they're getting larger now sure um growing obviously but they

started out you know a fairly small team yeah i think they were maybe like 30 ish people um when i interned there uh 30 or 40 something like that uh like applying for the internship there was pretty easy though um because if you i mean like i'm not saying that it was easy to get in but uh as far as like doing all the right things, like they wrote up, Joel, I think wrote up a blog post of like, if you want to intern at our company, you should do all of these things. So like I read like that, you know, blog post and did all of those things. And that was, you know, they, they definitely made it accessible. And I think a lot of companies are trying to follow that example right like i've heard it's pretty commonplace for uh companies that you interview at these days to kind of provide you with um this is what you expect when you come into the

interview like these are the kind of questions that we're going to ask um and i'm really in favor of that kind of attitude of like, not just like taking candidates and bringing them in blind where they have no idea what to expect. But instead, like taking candidates and saying, like, we want to set you up to succeed. We're coming up close to our first break, so we still haven't gotten to go lane. We still haven't gotten to really where open source fits into all this so we obviously have to crack that nut open but let's take a break real quick hear from a sponsor when we come back we'll talk about maybe get a little closer to your path to go lang and then also how open source fits in so we'll be right back we love top towel and one of the interesting things about top towel is being able to

take control of your career being able to work on technologies you want to work with being able to work with companies you want to work with choosing your own salary being able to travel and i talked to asa alarenas the community manager for top town south america and i was blown away by what this guy had to say so take a listen. To be tied to a desktop these days is something that definitely I think that people should, it's not necessary for developers if there are still developers and I'm sure there are a lot of developers still tied to their desktops. I will let them know about Total, about this company that will give you like the opportunity to drive your own career. You can decide how much time you want to work, how much you want to earn, where you want to work

from, when you want to work. So what else? All that is possible. All right. That was Top Tiles Community Manager for South America, Asa Ayala-Rinas. He's living a dream. He's traveling the world. He's getting paid. He's's traveling the world. He's getting paid. He's doing what he wants. He's choosing his own path. And if that's what you want to do, call up on TopTal, T-O-P-T-A-L.com.

Tell them that ChangeLog sent you. If you want a personal introduction, email me, adam at changelog.com. And we're back from the break with Alan. We're talking about, I guess we're trying to get to to the open source path here obviously uh jared and i mentioned ngrok and that's an interesting project of yours obviously and you're a fan of go so where did where did your path to go begin at

what point did you get to to that i know Go has been out for like, what, six years now, roughly? Yeah. Somewhere around there. So at what point did you pick up Go? I picked up Go towards the end of my time at Twilio, actually. Not that it actually had anything to do with Twilio at all. It's just where I was working at the time, yeah. I guess it kind of had a little bit to do with the work that I was doing at Twilio. I was working with my friend Jeff Lindsay there.

And we were... We know Jeff. Yeah. Jeff's a great guy. We've had Jeff on the show before. Yeah. He's awesome. And at the time, Jeff was really into asynchronous programming in Python.

And we had a couple of services at Twilio that were written in Twisted Python. And Jeff was a big proponent for another asynchronous Python technology called G event. And so I had started like building some stuff with that at Twilio. And when go came out, you know, I was kind of eyeing it and I was like, this looks like it's the G event model, but not a hack on top of some other language, that this is that programming model at the core of the design. And that really appealed to me. So that's kind of what instantly got my interest about Go.

Just to kind of expand on that, the way that GeoVent works is basically it's built around, whereas like twisted Python or node are built around an event loop with callbacks when events happen. G event and similar technologies are built around the idea that the runtime should handle that for you. So you can basically spin up these things called green threads, user mode threads, that you would pretend like they were when you did I.O. or any other kind of operation that would block the event loop normally.

Instead of having to manage that yourself, you would actually make those calls as if they were blocking calls. But the runtime would be smart enough to realize that they were blocking calls and manage the event loop for you. So they would basically take that user mode thread that was about to block on a blocking call and put it on its own scheduler queue and then stick an async IO event into the event loop that it managed. So that's the very basic intro into how those technologies sort of work. And that was what Geovent did. But it was like a hack on top of Python, right? Because Python wasn't built for that. So it did really clever things

like manipulating the Python stack frames and stack pointers to actually do things like that. So when I saw Go, I was like, wow, this is like that model of like we should just build our code as if like all of these threads are blocking, but the runtime should handle that complexity for us. So that was what got me into it. It's nice when that's built right into the language as opposed to implemented in the library or added on later. Yeah. implemented in the library or added on later? Yeah, it allows you to do a lot of things better, right?

When it's just built in at that core level, right? G-Event always had these problems where you would worry about every dependency you brought in because if that dependency did any kind of blocking IO, you had to worry, did it actually block? Or did, like, GeoVent manage to monkey patch those calls so that it wouldn't block? Or did it do the IO in a C, like, in C somewhere so you couldn't deal with it at all? And you had, like, no visibility into these sorts of things, and it was a real pain um so go having all that built in was was really awesome so i started building like a couple um like just toy projects in go uh to kind of fool around with it um and then at some point i actually

decided that i i wanted to learn um to actually build a substantial thing in it. So was ngrok your big first substantial thing or did you have some prior art? Yeah, no, ngrok was the first thing. That's ngrok was originally a project built to learn Go. That was about it. One of the strategies, like the strategy that I really love for learning a new technology is to take an existing project and port it into the new framework or the new technology or the new language or whatever it is that you're

trying to learn exactly. So that's what I did with ngrok. The reason I like that is because when you build things, at least for me, I get all up in my head about what it is that I'm going to build, right? Suddenly it becomes like a product, and I have to make product decisions where I was like, should it do this?, should not do that.

Whereas if you port something, all of those decisions are made for you. It becomes more like an academic, like a class project where all the requirements are defined upfront. You like that entire cognitive load is gone. So that's, uh, and Grok was essentially that It was a port of Jeff's Tool local tunnel actually I recall talking about local tunnel Actually back on 99 if I recall

We talked about Flynn, Tent, local tunnel That's really interesting So Was local tunnel in Python? It was, yeah And so you were interested in Obviously learning Go but then porting something to it and making it a serious project yeah that kind of happened accidentally really um that it

turned into a serious project uh it was really just a project to learn go to start with and uh local tunnel was a project that seemed relatively small and well-contained and seemed, from what I knew, a decent fit for Go. Because it was pretty network-heavy. So yeah, I kind of picked it up and ran with it, and it just kind of spiraled out of that. Were you surprised by the success of it? I mean, I know when it first came out, which I can recall back, it was probably like, I'm guessing at least two and a half, maybe three years is my guess, roughly, as far back as at least I knew about it. And it seemed like an obvious problem for a large amount of people. So did it seem like a surprise to you that was successful uh yeah i guess it was surprising that it was successful because it was just a clone that was kind of what

surprised me um about it actually taking off yeah it was about three years ago now and grok is so much cooler sounding than local tunnel. I mean, I cannot begin to tell you how excited I was when I found a five letter pronounceable.com available. It was just, it was a beautiful moment. Yeah. And I'm just telling Jared in the back, I'm like,

I'm really interested in the name. Obviously N stands for network, but, but, uh, why GROK, I guess to understand the network. The one thing that I but, uh, why GROK, I guess, to understand the network. The one thing that I did, like, as I, uh, after like I had cloned it, I'm as happy with

it. I like started to like, think about other things that I would like in terms of the product. Right. So I worked at Twilio. So I was dealing with webhooks all day. And when we built, so I built a lot of Twilio applications for testing. And when you build a Twilio application, it was this really frustrating exercise,

because you would pick up the, you would write your code, and even with local tunnel or ngrok or an SSH tunnel, you would pick up the phone and dial a number or send a text message to actually pause Twilio to call back to your code and trigger it to run. And that was so you do that once, but it was always broken, right? So it would break, and then you would try to fix it.

And then you would do the same thing again. You would like pick up the phone. So I just end days with like a call log of like 40 calls to this one random number, you know, uh, just to like, try to get the application working. And so I started like thinking about the kind of things that if I were working on that, uh, type application, that would make it easier for me. And one of those was that I wanted to see all of the traffic that was flowing across the wire. That was really important, as well as being able to replay it. So yeah, like the introspection part of it was kind of new and or wasn't at least in

any of the other tools. And I like the idea of like being able to introspect things and look at them as they're happening. So the name is kind of just a play on the word, the word grok coined by Heinlein, which is like to understand. And because there are a whole bunch of other like network tools that start with N, it's kind of a play on ngrep. It's weird.

It doesn't actually mean that to me anymore. That was like the genesis of it. But to me, it just kind of is its own definition now. I think one thing about this tool that impressed me, there are a few things. First of all, you do a really good job of explaining its value proposition on the website. And so it's one of those tools that once you know you need something, you want to expose

your local development environment to somebody who's not on your network, right? You need NAT traversal, you need all these things. You may not understand exactly how to get all that done, but you're like, man, I wish I could just give somebody a URL and they could actually access my, this demo that I have on my machine. You do a really good job of explaining like, hey, this is what that tool does.

And so I think that was immediately impressive. And then the fact that it is just a single Go binary, drop it into your path and it runs, which has been kind of a flagship feature of Go for a long time. It's just the easy distribution. Makes for a good first experience. And then thirdly, there's a lot of little details that just are really nice, and I'll just give a single example.

And this might be ngrok 2.0, and it wasn't in 1.0, so you can help me sort that out. But for instance, when you're actually running the thing, it will show you there. There's a little display in your terminal that shows the URLs and, like you said, the introspection if you want it, what's going on. But there's an event time where it detects an upgrade,

and there's a new binary you can download, and it just says hit control u to update itself and so while you're running it you just hit control u and there it does goes out and downloads and upgrade itself and if i had to restart the program for it to to run the new version but little stuff like that that you just don't expect from an open source project and so i'm curious like where your attention to details come from like where why you put so much time and effort into this and uh just like you to kind of just speak to that yeah uh the updating thing i was i was really psyched about getting that working when i

did um it went through a lot of iterations, actually. There was an updating component to version one, too. Sorry, version one as well. Yeah, I don't know. As far as my strengths go in terms of building things, I think of myself partly as a software engineer and the other strength that I feel like I have is product design. And so a lot of that is just that attention to detail of just trying to round every sharp corner,

constructing error messages that are helpful and useful. I'm still really not happy with the error messages that ngrok kicks out. I've kind of been on a mission lately where it's my goal to have every error message that ngrok issues have a unique code number that comes out of it. So that with like a unique prefix for ngrok issues have a unique code number that comes out of it. So that with like a unique prefix for ngrok, with the idea being that if there's any error that you should actually it should be like a unique string that you can put into Google that will

only point you at that particular issue. That way, like, if someone like has that issue and tells me about it, I'll know exactly what it is or that I could write up documentation for each one with, like, this is what happened, right? Because you only have so much space inside of a terminal to actually tell people what went wrong and how to fix it. But, like, to be able to link to walkthroughs and guides or possible, like, reasons that this sort of thing happened

in documentation that would be really easy to find with a unique code. Yeah, that's a great idea. I think there's, I've seen a few projects starting to do stuff like that. I know Angular at some point started introducing kind of expanded, like their error messages would have, you know, short URLs in it. And it's like, here's like the brief description of this thing, but in the console, I click here and I'll actually just expand out to a full page that has all

sorts of extra information. And I think that's super useful. So have you achieved, have you been able to achieve the unique ID for every area or is that an aspiration? I'm getting closer. It's, it's certainly not all the way there but um it's it's probably about half there okay yeah uh yeah i don't know so i i really like i really love uh building product experiences that that people love and so a lot of the drive that i have in software is like to make to take really hard things and like solve them but make them really accessible

to people which is not i don't know there there are a lot of projects that i use that i get very frustrated with because they do really cool things, but the user experience is often really poor with them. So I've always wanted to, like, I always enjoy making things very polished and very nice. And the auto-updating experience was definitely part of that for ngrok. I spent a lot of time learning how other people did it and researching what would be the best ways to do it.

And I still got all those things wrong to start with, but I've been iteratively getting better at them. I recently actually just took all of that learning from building the auto update experience and kind of spun it out as its own product recently. I think there's some lessons to be learned here. You know, it doesn't just apply to open source, but, you know, for software development in general, especially when your target audience is developers, is when you sweat the details, it pays off, I think, in spades

because developers, probably more so than any other people because we know, we understand, you know, what's happening. Like we understand what's going on when, when an auto update is occurring or, you know,

when this happens and, and when you sweat those details, those little things that, you know, people may or may not even notice really set pieces of software apart from the pack, even if they're serving the same purpose. Because we appreciate the level of effort that goes into that.

Even if it's the value that it brings is minor, you know, I'm not saying that an auto update is a minor value. I think that's a pretty big value, but just some of the little pieces of, you know, the polish on the software, like you said, it was a clone. So it's not, it's definitely not a, a new idea. It's not a standalone product that nobody else is doing. And so it's like, wow,

this is singularly valuable, but it works well. And it's, it was crafted with care and your audience is, is developers mostly or network people. And we tend to care about those things. So, um, you know, a lot of success, frankly, in open source is, yes, can be serendipity, right. Right place, right time. Uh, those kinds of things. Sometimes it is based on merit. Sometimes it's not, but I think if you just saw the details, like have, Alan, I think you're giving your particular tool a better shot. Thanks. Yeah, it's really gratifying to hear because I care a lot about the details.

So I'm always glad when other people care about them as well. It's a good feeling. On the note of success, I would actually probably say that because I have some sort of background knowledge on another project that could have been or probably was just as good, and I'm just saying that lightly. I don't mean that for sure because there was a web service behind it, an installable client, things like that. But I had a friend, or I guess still have a friend,

we just haven't talked in a while, but a friend who roughly around the same time Ngrok came out had solved a problem like this but wanted to make it a paid service, mainly because they wanted to do something similar like you. They wanted to do something serious that was outside of their normal job that could potentially grow some legs

and do something interesting. But something about Ngrok, I would say Ngrok itself, but also the fact that it was open source. So I think my hat tip to you is like, I think that, and maybe you can agree, is that open source really was, or it being open source and being the way it was, and so available to people that solved the great problem very very well like jared's talking about was a core underpinning to success yeah i definitely think so um i think that a lot of people i mean a lot of people like open source uh for for a number of different reasons yeah um but there are a number of people who will give you the,

who just simply like it on principle. And so that's the only kind of software that they want to use. A lot of people like it for the hackability, right? That they can change things in it. And so being able to like tap into those developers by making a project open source is a really powerful way to get adoption for anything that you're building. I guess a side note, two of the other projects I mentioned is that the that project right now is is no longer. Oh, you win.

I'm sorry to hear that. It's not a competition. I know that, but I mean, it's just... Sad face. It's a sad face, but I think it's interesting to, at least for me, because I have a different perspective than you because you didn't know this before me telling you this, but all along I've been watching you two in parallel to a degree

and have seen you rise. And I imagine it's for the reasons we all know that open source is easily adopted and it's easily contributed to and you can go in and change it if you want you can you know work hard and become a maintainer or become a contributor or whatever and whereas a proprietary software that is i guess to a degree simple enough that should be open source maybe even better as open source because it is infrastructure. I'm just trying to say that I think maybe open source was the better way to go, obviously, for somebody out there who may be thinking, should I closed source this?

But now you aren't really open source anymore, so that could be the flip. That's true. I think that's a perfect teaser for the next segment, which is that you built this tool, made it open source, huge success. I mean, even to this day, Ngrok 1 has like 7,000 stars on GitHub, lots of people using it. People even bake it into their products too, like their software. It's sort of like, yeah, fire up ngrok to do this.

It's become a thing that people use daily. That being said, I happily upgraded to ngrok2 without even a thought because I was happy to use ngrok1. So let's talk about that after this break. The switch, ngrok2 closed source. What happened there? What was the decision? and all sorts of stuff around open versus closed after the break.

For those of you out there who are super fans, and I mean people who care about this show, listen every single week, care that we stay on the air, we want to invite you to join the membership community for just 20 bucks a year, and we'll give you an all access pass to everything we do. Access to our members only Slack room, exclusive discounts from our partners, 50% off in the ChangeLog store. And of course, you support us so we can support open source. Hit the changelog.com slash membership to learn more, and we appreciate your support. All right, we are back with Alan Shreve talking about ngrok one versus ngrok two open versus closed. And what was probably a big decision to release ngrok two as a binary and

keep the source to himself. So Alan, tell us about this decision, this change, where it came from and why you made it. Yeah, it actually was not like a decision that I made at any one point in time. It was kind of an overarching decision that lasted for like a year as I was building Ncroc 2, maybe a year and a half. It took a while to actually build that out. It's an interesting, it's a really hard half. It took a while to actually build that out. It's an interesting, it's a really hard decision. It was a really hard decision. It still is. When I started building ngrok2, the idea was like I'm building it with all the source code just in a private repository. And then when I get towards launch, like I'll actually open source all of it. So part of that was that when I started building Ngrok 2,

I started building it in a more modular way, in a way that the intention was to take a whole bunch of different libraries and open source them. So that all of these individual libraries that were used to build Ngrok 2 would actually be open source. And that actually happened. A lot of the technology that is used to build Ngrok 2 is open source. So one of the projects that I built for this is a project called log 15,

which is like a structured logging package for Go, which allows you to build like reusable handlers and reusable handler structures. So that ended up being open source out of it. And then another piece was the actual network layer that does stream multiplexing to actually run a whole bunch of virtual connections really over a single TCP connection. That's a project called Muxadoo that's on my GitHub as well. And both of those projects have been successful in one way or another, that they've been useful to other people, which I guess is a decent metric for success of a project. So a lot of the stuff actually did end up being open source. The actual product that was built on top of those libraries is kind of what didn't.

So it sounds like you've modularized the underlying infrastructure, kept that open source, and built what was before open source ngrok into what sounds like potentially an actual product that people will pay for on top of the open source that made ngrok one yeah that's uh it actually like wasn't built on top of version one it was essentially a complete rewrite there's almost zero code that's shared across them honestly why the big rewrite instead of just continuing to evolve what you had yeah i mean it was basically a result of a couple things one was that uh androck was a project to learn go and when you're learning things you make a lot of mistakes there are a lot of things that you don't

understand a lot of things that you think you're smarter than other people who have been working on it for a while. So I made a lot of mistakes, a lot of things that, looking back on them, that I'm not proud of the way that it was built. And the other part was that the scope was changing. The scope for Ngrok 2 was not this thing where there is a single like server binary that ngrok client connects to but I wanted to make it a very reliable service right one of the one of the other pieces of quality from a product design that isn't so much UX that I care a lot about and put a lot of work into and that you see very little of from a user

is reliability and stability of the service. And so a lot of work goes into that. And one of the pieces that went into that was building out the server component in a way that it was distributed across many machines so that it could tolerate arbitrary machine failure. And these days, actually, I actually just released this last week,

is that ngrok actually now operates in multiple regions around the world. So there are actually like HA setups in a number of different data centers that coordinate with each other to actually run a global ngrok service. And that's a very far cry away from uh there is one machine that runs the ngrok service sure so actually like re-architecting

it for that scope basically involved a complete rewrite so is it fair to say that the decision around this is financial yeah that's totally fair to say. There are, you know, I was building it out and one of the, it's mostly financial. There are some other things in it as well. But yeah, it's interesting. Like building a business model around open source is a tricky thing.

And there are a couple couple ways that you can do it. Like, there's the we do support model, right? You know, like, we give away all the source and then this runs some critical piece of your infrastructure so you pay us essentially insurance is kind of what it is. If it breaks breaks you have a direct line to someone who can help you fix it right um there's also like the open core model right where you like give away most of it but you charge you know large amounts of money for uh enterprise features like i don't know single sign-on or something like that audit trails similar to how like a sidekick is is in that model where there's the open source community version and then there's sidekick pro which

okay there's kind of there's derivations of that where you have kind of enterprise which has enterprisey features but pro sidekick pro is more like sidekick plus plus seems like that model could have possibly worked for you did you did you did you bat around all these ideas as far as different ways of doing it or did you throw your hands up in the air and say well i'm just going to keep it closed totally um the other model that was the one that i considered most seriously was the um the model that like sentry uh takes and and docker as, right, for Docker Hub at least, which is like all of the code is open source. There's nothing that's like a closed add-on, but we

run the service for you, right? Right. And so running the service is the piece that's like too complicated that you don't want to deal with, right? So you pay someone else to do it. So that was the one that I considered most seriously. And I ended up having problems with all of them. One of them was like the support model was, is based entirely around your product being core to like someone else's

production infrastructure. That's like the thing that you pay insurance for and ngrok right now is not that um it may be in the future but at the moment and certainly at the time it was a development tool and so if it breaks like your developers are kind of unhappy but it's not something where you're like, oh, man, we need to have Alan on the line, you know, in 30 minutes notice to help us fix it if ngrok goes down. So that one was kind of out for ngrok, which was kind of validated because I never really got any, you know, interest from people who were like, when it was open source, they were like, Hey, can we pay you for support? Uh, and the other model that was seriously considered was like running it as a service. And it kind of, the trouble that I had was with it was that it kind of put me at odds with making the product really great from a server standpoint. Um, I feel like a lot of companies that have this, like, well, you can run it yourself on your, like, or you can use our hosted service. Um,

don't put a lot of work into usability when it comes to installation on your own service, right? Because they're not incentivized to, they're actually financially incentivized to not make that good, right? So that you're more likely to be like, oh man, I don't want to stand up like RabbitMQ and a database and all of this other kind of stuff to like make this work. Let's just pay someone for it.

And ngrok was kind of in this interesting place where it didn't really require a database. It didn't really require any infrastructure. It was just a binary, right? The server installation was such a simple thing that I put work into making it straightforward and really easy. And so I had talked with a lot of customers who were basically like, yeah, I mean, we, we would, we could have paid you, but like, we basically had no reason to. And part of that is, is part of like the reason that that happens is, is partly because it was designed that way, but also like

the product itself doesn't have any like persistent piece, right. It doesn't like store your requests on the server or do any of those other kind of things that require more complicated infrastructure, like a database or a message queue or those kind of things. So I wasn't particularly happy with either of those options. And so when I launched it, it was kind of launched in a mode of, well, I'll keep the source closed for now,

and we'll see if it makes sense in the future, if there are like more pieces that I can open source, or maybe if I can find a way to open source the whole thing without jeopardizing the business model. Yeah, that was, that was kind of the thought around it. The other like piece of it that went into the calculation was if, if I made it open source and like, couldn't get paid to work on it full time right if like that wasn't enough money to to make it a sustainable business would it be better for the product and for its users to have it be to have it remain a side project right something that you know got my attention whenever it happened like whenever i had the time um or

would it be better for the product and for the users to be in a place where it was like i can work on this full-time and dedicate all of my energy to it so i guess i have two questions you can take them in order or take them however you like um the first one is where, where does the paid product begin with Ngrok too? Because like I said, before the break, I happily upgraded. I don't know which version you're running, but I wasn't taking advantage of any of the open sourcedness of it.

I was just using it as a, as a tool when I need it. And we're very casual users. I mean, like Adam said, we use it to expose a web server to campaign monitor so they can suck in some HTML and I'll use it to develop a webhook here or there. So we're very casual users.

So tell us where the product, the paid side, like what model you decided to go with in terms of the paid stuff that Ngrok 2 has. And then as a follow-up to that, if if you will give us some insight into how it's going and, and kind of the status of ngrok as a paid product. So yeah, ngrok too still has, uh, like a very generous free tier. Um, and most casual users never really break out of that free tier. the you know and that's that's been something that i've been trying to that i've been thinking about like over the past year is like do i want to consider that lead gen or do i want to actually um take more things away from it that it incents

people to upgrade but you know it's it's a difficult calculus. I don't want to cripple the product. I still want it to be like, I still want that really great initial user experience of you download it and run a command and it's instantly working. And there's no please pay sort of thing immediately, right? That you like immediately get value out of it. So the major, it's kind of all advanced features that people that are in the paid tiers today. So one of those is like Ntend encryption is a thing that Ngrok does that you can pay for. Where instead of Ngrok essentially like terminating your TLS traffic at its servers

and then re-encrypting it as it transfers over the tunnel then instead ngrok actually like inspects the incoming tls connections and multiplexes those to your back end so that you can actually do end-to-end encryption where ngrok is just a router, essentially, at that point on the internet. The one that most people tend to upgrade for is custom domains. Right now, on the free version, you always get a random domain when you start ngrok. Allowing people to pick a custom subdomain of ngrok.io or even being able to run a tunnel over their own domain name. Right.

So like dev.incontribable.com is like. Yeah. Kind of white labeling it to a certain degree. Yep. That's, that's a paid part of the paid features as well. As long as, as well as like some additional like uh businessy stuff like ip whitelisting is another thing that's part of the paid tiers things like that what's ip whitelisting do uh it basically lets you restrict the incoming connections to your tunnel endpoint to

a certain set of ips gotcha right interesting so question two just how's it going like give a give us a some insight intogrok as a paid product. You also have Equinox. You can talk about that in light of how you're doing it, making a business out of this. So the great news is that Ngrok is a sustainable business, which is awesome, which means that I get to dedicate all of my time to it, which is really exciting. And it's why it keeps getting better, really, is that I actually have all of my time to devote to it. And as far as Equinox goes, the work on that is actually,

it's kind of work on NROC in itself. Part of like... What is Equinox first? Sorry, yeah. Equinox is, we talked earlier about the auto-updating experience that Ngrok has where you can just like, it detects that there's a new version you press control U and it updates itself. So Equinox

is all of that functionality around building a self-updating Go program packaged into a service for you. So it does that as well as packaging and distribution. If you have a Go program, it will package it up into an MSI for Windows and a PKG installer for OSX, and it creates a custom homebrew tab for you

so that when you release new versions, you maintain all of those things. Equinox was kind of built out of this desire to make the installation experience better. Sure, there are a huge number of developers for whom you can hand them a zip and be like, here's the zip. It has a binary inside. unzip it and run it. And that works for a large majority of people. But ngrok's user base is huge. And it includes a lot of people who are not technical at all.

People who have never used the command line before. And so being able to be useful to them means a better installation experience, a better updating experience, all of those things. So Equinox is kind of the work that's been put together to make that better. And so it's been packaged up as a separate thing with the hope that it'll be useful to other people. I'm just looking at version one versus version two. It seems like 1.0, the original open source version, wasn't what you wanted it to be in the long term. And now with 2.0, you're able to open up a web interface to it,

obviously have custom domains, be able to look at traffic, things like that. I'm wondering if the web interface and the command line interface has a similar or mirrored experience. Yeah, so all of those things were actually present in 1.0, actually. There was an introspection interface as part of version 1, and there was a website website like a dashboard for version one as well um it wasn't as the website at least wasn't as fully featured as it is now um but there was one that existed as far as them being mirrored uh well i just mean like are they similar do they have similar features like do you get more if you use the web interface versus the mainland interfaces? Are things that just maybe common there, but it's not like you can exclusively use

the web interface to work with ngrok. If you want to start it, you do have to use the command line to start it. Once it's running, if you want to look at the requests that are going over the tunnel, that's the only thing that's really mirrored is the status interface that you see in your terminal

and that you see in your terminal and that you see in the local web interface. Those are pretty much the same, except that the web interface is much more detailed because it just has a lot more screen real estate to work with. And, you know, things like CSS and graphics, right? I have a hypothetical for you. And it's, uh, yeah, it's easy for me to say because it's your livelihood and not mine but what do you think would happen if you took what you currently have which is

NROC2 as a product that's being both used for free by some people and paid for by some people and you just took that and you didn't change anything in the model but you just hit you know open source on that repo, what do you imagine would be the fallout

or the change from that dramatic button click? That's a really great question that I do not know the answer to. It's one of those questions that I wish I knew the answer to that question. And honestly, maybe one like i will do that and i'll find out what the answer to that question is um well email us when you do and we'll have you come back on the show and talk about what happened yeah um that like that'd be a really interesting experiment um and i'd love to run it but that's kind of the

unfortunate part is it's one of those unfortunate part is it's one of those things where you it's one of those experiments that you can't run right yeah this probably is one of the first times Jeremy have had somebody come on the show that started open source and went closed source and is to a degree considering

going back to open source well so far as I've asked him to well it sounded like earlier he was saying that too like he was hoping that he can eventually to open source. Well, so far as I've asked him to. Well, it sounded like earlier he was saying that too. Like he was hoping that he can eventually potentially open source even the code, even though like paid features will be there. I mean, did I hear you wrong, Alan? No, that's totally right.

The goal is to find ways to open source parts of it. Maybe eventually the whole thing. Like, I've toyed around a long time with the idea of open sourcing just the client. Yeah. Which might be a thing that happens. Part of it might be actually taking just the protocol for actually, like, setting up the tunnel and actually exposing that as an open source piece as well. Or finding ways to, I don't know, maybe experimenting with something like what Sourcegraph has done where they have their own kind of modified open source license, which

still requires people to pay them for it. The fair source license, yeah. Right. Right. But Yang, actually, speaking of Sourcegraph, we're going to have requires people to pay them for it fair source right the fair source license yeah but yang actually speaking of source graph we're going to have being back on uh goats on we actually we're going to record with being but then it got rescheduled so he hasn't gone back on yet but we mentioned go time before and obviously equinox and this isn't go but that's a really good interesting a really interesting example because fair source the license there was written i think most licenses are written by lawyers at least to some degree but this one was actually written by a lawyer that's very familiar with open source and very involved in open source

that was trying to liberalize this license work and actually provide the right kind of things that open source needs but also the right kind of things a business needs, which is kind of interesting to think about that. I'm really excited about those kinds of efforts. Yeah, they're really exciting. I don't like I don't know how they're going to go, but I'm hoping for the best. Fair source. Well, if you're interested in that as a listener, I guess go to gotime.fm and hit subscribe.

Yes. You'll be hearing about Sourcegraph, and I'm sure they'll be talking about Fair Source on that show as well. Alan, let's get to our closing questions. Unfortunately, we're getting near the end of our time here. The first one we have for you, which is one of our favorites, is programming hero. So if you had to name somebody who's been a mentor or an inspiration or a hero of yours in programming, who would that be and why? It's a hard question. There are so many programmers that I look up to and respect. One of the, I guess, more famous people that I've looked up to is,

that I guess I'm really impressed with, is John Carmack. I don't know if you guys have read Masters of Doom or know too much about him. I have that in my Amazon wishlist, but I have not. I haven't pulled the trigger on it yet. It's a fantastic book. Really fascinating, especially if you're

into video games or ever played doom or want to know the history of id software but um yeah just just a guy who is a technologist like through and through and is not afraid to tackle problems that everyone else thinks are impossible and is still doing it right uh i don't know if you read this story about him in minecraft about how he basically like got himself access to the minecraft source code so that he could port it to oculus because he was dead set on it running on oculus wow really yeah it was it was truly fascinating right and this is a guy who like and he's been doing this for i don't even know how many years now um and is still like at the forefront of his industry like leading it um and doing amazing things uh so i don't know he's he's

definitely one of the people that i looked up to well for those that listen to the show too this is the sixth time that I can at least tell by our notes that John Carmack was a hero too oh wow a big hero that's interesting though to think that he was that set on hoarding it over yeah that's a fascinating

story to me. Is there any licensing issues with that? Is that like legit? Is that a cool thing to do? That was kind of the crazy part, at least in the article that I read about it. They basically said that, you know, Carmax lawyers looked at the contract that they handed him and they were like, you're basically just doing this work for them for free. Like, you're not going to have any rights to it. He was like, I don't care. Like, it just has to exist like I'm so excited

about this yeah so what came of it I'm not entirely sure like I think they demoed it at some at some presentation but I'm not sure where the status of that is right

now so one other thing we like to ask Alan at the end of the show is, is radar. You know, we like to, we have a weekly email. We call it change long weekly. It's our editorial as take on our radar.

And so when we have a guest on, we love to learn about your radar. So what's out there, whether it's a technology or open source, what's out there that if you had a free weekend, you'd play with it, something you want to play with that you haven't had a chance yet? I'm really excited about all of the emerging languages.

So I'd probably be playing around with those. Like I would be excited to try working with Rust some more, to try working with MIM or elm or any of those sorts of things um what's mim elm elm okay yeah uh all of those kind of uh new and emerging languages that are approaching problems yeah elixir? Yeah, Elixir. They're all pretty exciting to me. So I'd take a look at those. Another thing not in the language sphere

that I've been meaning to take a look at for, man, I don't know, maybe over a year now, is Nix, NixOS, as a better way to do configuration management. The ethos around it is really appealing to me. So I'd like to spend some time actually like trying it out and seeing how well it worked. I feel like we've heard of NixOS, Jared. Have we mentioned this recently or sounds familiar?

I think it's probably probably you probably see it in changelog nightly a couple times i've definitely heard of it but we have not featured it in weekly nor have we done a show on it so i think it's kind of it's a good one for radar because it's now now it's just bubbled up again on ours all right well alan i think that's uh it's a close for a show we would obviously love to talk to you more deeply about your fun trip down open source winning with NGROC. I mean, it's kind of interesting to see it start the way it did as open source, go closed and potentially come back as maybe fair source.

Who knows? But I guess if we can consider that open source, I guess it's kind of a good story. Are you still out on that one? It is still kind of, I mean, it depends on how you define open source i guess it's kind of it's still out on that one it's it is still kind of i mean it's in that gray area depends on how you define open source right if it's right i can see the code then it's open source if it's it's uh free open source uh then i don't think it is at least yeah any closing thoughts from you before we close out anything you left unturned that you want to mention to the listening audience i mean i i just really want to thank you guys for having me on here like i'm it was

just such a pleasure talking to you cool man it's like thanks yeah man we uh we'll have to get you slotted on go time too since you're such a go fanatic and you have to listen go time.fm yeah i will definitely check it out that sounds awesome alright cool and with that that's the show so let's say goodbye everybody

goodbye thanks Alan for the great tool goodbye everyone thanks for having me on We'll see you next time. you