The Changelog: Software Development, Open Source - DOUBLEHEADER — 24 Pull Requests and Libraries.io + Flynn (Interview)

Episode Date: December 25, 2015

We have a special doubleheader holiday show for you. Andrew Nesbitt joined the show to talk about 24 Pull Requests and Libraries.io, and Jonathan Rudenberg is back to catch us up on Flynn.

welcome back everyone this is the changelog and i'm your host adams d'koviak this is episode 188 and today is a special show it's a combo show we have two shows in one just for you for christmas holiday hope you enjoy it the first part of the call, we're talking to Andrew Nesbitt about 24 pull requests and also libraries.io. And in part two, we're catching back up with Jonathan Rudenberg, the creator of Flynn, a next generation application platform.

We had four awesome sponsors for the show, CodeShip, TopTile, DigitalOcean, and also Harvest. Our first sponsor is CodeShip. In the new year, TopTile, DigitalOcean, and also Harvest. Our first sponsor is CodeShip. In the new year, January 12th, they have a free webinar you have to check out. CodeShip's engineer, Laura Frank, is going to give an overview of Docker's ecosystem,

Docker Compose, Docker Machine. She's going to talk about containers, and you'll learn about Docker images, why they're so powerful and how you can start running services in containers. And when it comes to web apps and Docker, you'll understand how to develop your web apps using Docker, working with images, registries and running services in containers. The link to this webinar is rather long, so I'm going to put it in the show notes,

but you can also go to resources.codeship.com and look for webinars in that list. And it's going to link to the same webinar I'm talking about. Or head to the show notes and click the link there. Again, totally free, January 12, 2016 from noon Eastern Standard Time to 1 p.m. Eastern Standard Time. That's one hour. And now on to the show. Hey everyone, we're here with Andrew Nesbitt.

Andrew is an open source software developer, has done lots of cool stuff, 24 pull requests, libraries, IO. And Andrew, you've got a longer list than I can even say here right now, but we'll talk about some of these things. But when you come on a show like this how do you introduce yourself? As I guess like an open-source enthusiast okay I've been I kind of built my career off the back of lots of other people's open-source work so kind of the kickstart for the whole thing was WordPress and teaching myself some Ruby on Rails. It feels like I've been kind of standing on the shoulders of giants for a long time. And I've got to the point where I feel like I can now start to really contribute back and kind of give back based on the things that I've been using for years to the point where I try and do that all the time now, if I can.

Let's get a little history of you then. I guess, you know, sometimes what we like to do on this show is figure out where someone came from to kind of make sense of and even establish more credibility to what they're doing now. So where did things begin for you as a programmer? So I originally didn't get into programming. I went down the robotics route okay at university i thought i'll try and do something slightly different than just computing and robotics

turned out to be basically just advanced math all the way through every part of it uh is just comes down to math which at the time I didn't find particularly interesting. I ended up actually kind of setting up a blog and then wanting to customize the blog and basically self-taught myself enough kind of web programming on the side of doing my robotics course. When I finished the university degree, so kind of involved in the web stuff that i was doing just getting into ruby on rails about nine years ago and it kind of went from there like i was able to pick that up much easier than the robotics kind of very industrial very uh

hard to get into which it's definitely changed now, but back nine years ago, it was very difficult to really get your teeth into and learn in this way that open source helps programmers to pick stuff up really easily just because so much code is available. In the robotics world, it's really not like that at all. Yeah, it seems like robotics might be a little bit easier nowadays,

and some might even call that Internet of Things or what have you. There's probably, robotics is obviously one term for it, and then attachment to that might be IoT or whatever. What do you think about it now? Do you think, man, I've got all these other skills now, considering your path with Ruby on Rails and Ruby and the things you've been involved with. Have you had some second thoughts about going back to robotics?

So over the last couple of years, I've definitely dipped back into it, especially around the NodeCopter movement, where you can get a para ar drone and it essentially it runs a little busybox linux uh install on board and it's a wi-fi hotspot you can plug like connect it with your macbook turn it into it and there's a nice uh kind of api that you can talk to over UDP. There's a little node module for essentially telling it,

like, take off, land, do flip, and you can even stream the video back to a web browser. All of this stuff is open source, and it's really easy to get into. Obviously, you still run into, like, the fact that physics isn't very easy to program against, and the real world has a lot of things that are much harder to program for than in a browser environment. If you run out of range and your drone hasn't been told to stop, it just carries on NodeCopter.com and Felix Geissendorfer has been on this show before way back in the day it's been probably 130 shows

since we've seen the likes of Felix around here but I also see you as the core team so you're part of that yeah so I started I managed to get a number of drones basically by getting companies to sponsor a drone for an event. Right.

And I ran a number of events around the UK, the UK being much smaller than like the US. I could drive from one end of it to the other in a day. And I would kind of lug 10 drones around, take them to a big space, like a sports hall, and then say like, okay, 30 programmers a day, see what you can do with them uh fix them up at the end of the day and then drive them off somewhere else so part of this big this give back

mentality you have just kind of thinking is this something when they sponsored did it is it something that you were doing as like a paid thing or was this because you were just in love with robotics in the community it's just a brilliant brilliant kind of small community of lots of people who had never really had that experience before and to enable that. We did a number of things with Coded Dojo as well, which was basically like kids who had just enough JavaScript to be dangerous, just unleashed them on the drones, give them some example code, and then let them

change and copy and paste bits so that they can actually start the drones doing kind of like maneuvers and trying to fly them around in a square in the room you can imagine how crazy it starts to get when you've got like 30 kids flying 10 drones in in one room yeah with javascript well especially when you think about things like you'd mentioned before, where, you know, you can, I'm familiar with,

with a node copter, the project and, you know, the syntax and whatnot. Like if you're just telling it to, you know, to do a clockwise turn or to go forward, you know,

10 feet, you don't know if there's another kid there or another copter or a wall there. So it could be kind of dangerous. Yeah. So that's where the kind of, yeah yeah the robotics aspect starts to come back into it once you've got the basics then you're like okay well i need to learn about feedback and then i need to learn about control algorithms and you get quickly back into that math that i was talking about earlier that uh the initial kind of your first time at a node copter event is great because you can do you can start to do the simple things but when you really start to get into it

your kind of progress slows down you hit a wall of like oh actually some of this is really hard so the open source side comes back and kind of saves you where people have with more experience have built things that you can then go and read the source and go, oh, okay, I understand a little bit how this works now based on what someone else has actually already done and shared. Whereas in the traditional robotics community, it's all kind of proprietary enterprise software that is written in C++ and not particularly user-friendly. So when I'm at your homepage, which is your last name.io, and we look down your, at least the code you have listed here,

I'm not on your GitHub repo or your GitHub profile, but libraries, IOS on there, split, node SAS, 24 pull requests, contributor, first pull request, which is kind of interesting, first pull request, broodler, Xbox controller, Hipster News, and Lanyard, an unofficial wrapper for the Lanyard API. I don't see anything in there for NodeCopter or anything on the robotic side. Is there any plans for anything on that front for you?

So I've done different pieces. A lot of the code that I wrote for that is on my GitHub account and is quite experimental it's like the uh the basics to get you started with say plugging uh an xbox controller into node and then using the output from that to control the drone so rather than uh contributing directly to the node copy code i did a lot more essentially working with other people, pairing with them to get them started,

which doesn't really show up on my GitHub account so much. Right. What is your current situation now with NodeCopter? Anything happening there? Any new events coming up? There isn't much happening right now. The core team has kind of disbanded off in different directions. Felix is doing a lot of go and lots of this. There's still a lot of good node copter related things going on. Uh, Chris Williams of JS conference got the, the new parrot drones. I forget what they called. It's like, I think it's the rolling spider, much smaller, more affordable drone. I was thinking

bibo or the bembo or something like that yeah well those ones work on the same protocol so yeah that's it with the uh kind of wide view camera on the front of it uh they all work over this this new protocol and the rolling spiders are Bluetooth, which is much harder to reverse engineer than the Wi-Fi kind of UDP protocol that you could just listen to. Right. That's interesting to hear your take

and background in robotics and NodeCopter. It's a shame that the core team's kind of disbanded, as you mentioned, because I was always a fan of that project. And several times on this show, the hero of people has been Jim Weirich, and he's had a lot of influence in that front, too. And it's just a really fun project. And I didn't know about the Coder Dojo piece where you're actually working with children and kids doing this stuff. I think it's just like a fun way, like you said before, of having that heart of giving back, you know, whether it's just open source, but also to people too, you know. And for a kid, rather than like a console log as your output to actually get like a robot to

take off and hover in the air, even if it's almost identical code, it's just the most engaging way to get someone interested in programming. Absolutely. I mean, it's, you you know you talk about real world response you know an actual thing they can touch and throw or play with or whatever that they can you know later on when they're actually programming it they can actually still hover it in their own hand like they would any toy but to be able to actually write a few you know characters on a screen screen or new words they're learning and bam, it starts working. That's cool.

Let's tail off to that and talk about your project, 24 Pull Requests. That's 24pullrequests.com. This show is coming out in the Christmas holiday season, so I thought it would make sense even though we're kind of late to the ball,

so to speak, because the basic idea of this is to send 24 pull requests between december 1st and december 24th um right and that's such an such an interesting idea i think it's been around for at least three or four years if i can remember so what's what is this project to you yeah so this is i think it's the fourth year it's been running and it started out as not even really like, it was more of an idea and a challenge, just as like, why don't you try and do this? It didn't have any kind of code behind it.

It was just the original webpage. You go back and look at like the first commit on the repo. There's a single HTML page that just says like, try and do 24 pull requests between like on the 24 days up to Christmas. Uh, and that came from a, uh, a blog that only runs, uh, in those same days for 24 ways. Yes. I thought that might be influenced by that. Yeah, absolutely loved it. Uh, but, uh, as a developer, a developer, which they've got a lot more developer articles now, but back four years ago, it was very much design focused. And as a developer, I kind of felt like, oh, I'd love to do something like this, but maybe a bit more code related. ring to it can i get people to send 24 requests like that's quite an ask but if we can get lots of people doing it then you're more likely to go like yeah let me let me try and do this as well

like everyone else seems to be contributing back um and it's kind of every year doubled the amount of people and the amount of poor requests uh since since it first started which has blown me away i didn't expect it to have that kind of response. So, I mean, I guess if you did it on a whim, so to speak, in a way to pay some homage to 24 Ways, what was your initial, you know, just your initial expectation? What were you thinking at first? I really just wanted to see what other people thought of it. Is this a crazy idea or is it something reasonable to actually give... If you've been using all of this open source code throughout the year to actually try and go,

okay, well, I'm going to try and contribute back a patch to all of the maintainers who have been supporting my work throughout the year. Can I help them by fixing a bug or making an improvement to one of the libraries that i use which then will in turn help me by improving the quality of the code that i depend upon and you make it pretty easy too because you have logging with github so uh pretty easy credentials there and i think you ask for some very, very sparse, I guess, what do you call that? Authentication back to GitHub. Yeah. Asking for like your basic public profile.

It's not even asking for much really in terms of, you know, clicking one button, using your existing GitHub profile and getting access to this dashboard, which shows off various languages and ways that I'm assuming that you're probing the community based on what they prefer. You're saying, hey, these are projects out there that could use some help. Exactly. So when you really, the GitHub login is something that came along like after a little while when people said, well, we're already doing doing this all the work is happening on github like if can we start tracking and kind of showing this as some kind of an advent calendar so you get like on your profile page a little calendar that shows the pull requests that you've sent on different days and we detect the languages that you've used on the repos that you have or that you've contributed to on github and automatically suggest projects

that match with the languages that you're you have some experience with and the projects are submitted by the community or the maintainers themselves so it's you can do a pull request to any github repo and that will that will count but the ones that we send an email to you to go oh would you like it there's so many days left till Christmas. Here are three projects that match languages that you've said you're interested in. Why don't you try and send a port request to one of these today? I think it's really interesting too,

especially the fact that you were fetching stuff I've already contributed to and saying, well, hey, because I didn't even notice that, but you'd selected, I'm more of a front-end developer than a back-end developer. So you got things like, you know, SAS and CSS related, JavaScript related. And I didn't even quite notice that those,

I thought they might just be smart defaults, but they're actually based on my behaviors on public activity in GitHub. Yeah, yeah. So I used to work at GitHub. I worked there for almost a year and kind of had a good, it was actually how it kind of got me the job because I'd been doing all this good stuff with 24-pro request. And so it hooks nicely into the bits of information you have without being too kind of over the top and going, oh, I know all about you and we're not going to pull way too much information in. I think what's interesting too is you've got some, at least now it seems, you've got some sponsors to help make this possible. So what kind of sponsors do you have and what

roles do they play in making 24 pull requests possible each year? The majority of the sponsorship comes around the services, third-party services that we use to keep the site running. So Heroku, specifically Heroku Postgres, has sponsored it every year to cover the bill during December. Outside of December, the site basically shuts down. It stops tracking for requests. It stops running any background tasks so i can

scale it down to one free dino and a small database and it doesn't cost any money but over the past few years it shows up on hacker news and suddenly the traffic goes wild uh had to scale it up to a couple dinos or add in a little bit of uh caching and Heroku Postgres covers most of the cost of those things. DN Simple jumped straight in on the first kind of week and said, do you want to use our DNS? We'll cover the cost for, I think they've covered the cost for like 20 years or something of DNS and domain name.

And then we send a lot of emails. I think last year we sent kind of close to 100,000 emails and domain name. And then we send a lot of emails. I think last year we sent close to 100,000 emails during the 24 days. So got in touch with SendGrid last year, and they sponsored, they basically covered the cost of sending those emails through SendGrid, and they've come back and covered it again this year.

That's awesome. So it covers the, the costs aren't huge, SendGrid, and they've come back and covered it again this year. That's awesome. So it covers the, the costs aren't huge, but it means that no one has to worry that there's like any kind of financial pain that could happen from the site getting too popular. Right. Well, I mean, most importantly, you know, this is something that you've started as a, as a part of your love for giving back to open source and just finding more and more ways to include people and share. And it would suck to have you have a $500 bill every December to make this possible while you may or may not be able to afford it. to see the in simple bug snag send grid roku postgres and uh and the last one here is sci-fi js just to see them step in and say hey we care enough too to to get these services free yeah

yeah loads of uh support and not necessarily always financial support but having uh people from each year there's a few people who step up to kind of help triage the issues and the pull requests that come in. We've had so far, looking on the GitHub page, 175 contributors to the 24 pull requests repository, the main project, which is kind of overwhelming during the period of December, the amount of activity that happens on the repo for what is essentially a side project. It's certainly an interesting project to us. Like I said, I've been watching it for a couple

years now and every year I'm thinking, I don't think about it until December and then it comes around and it's like, I would love to talk to this guy. Finally, we were were able to, you know, four years later sync up with you and sort of cover this. It's great. I remember listening to the changelog way back when Wynn was on it as well. Yeah. Good times. Good times.

Yeah, we miss Wynn around here. He's at GitHub doing his awesome stuff on the API, being an API junkie, as he likes to say. So we miss Wynn around here. He's at GitHub doing his awesome stuff on the API, being an API junkie, as he likes to say. We misquint around here. He's fixed a few bugs for 24-hour progress where we try and get the best way to pull in

the pull request for a user over a given time period, which there's different ways of doing it but and now we're using the like the github firehose the event feed to try and pull in 20 like your pro request as soon as you open it which is pretty neat as soon as within maybe like 10 seconds of you opening your progress on github it shows up on 24 requests well cool let's uh let's take a break real quick when we

come back we're going to talk a little bit more about contributing what that means in 24 pull requests how that kind of works we'll come back we'll talk a bit more about 24 pull requests and then we'll move on to libraries.io and all that is going on with package management so we'll be right back our friends at toptow launched a scholarship program for female developers to support aspiring female computer scientists developers and software engineers to help achieve their goals through financial support and also mentorship each scholarship winner will receive a five thousand dollar scholarship that can be used towards education and professional development goals you can spend this money on anything you want from coding boot camps to online programming courses,

textbooks, you name it. You also get one-on-one mentoring, an entire year of weekly one-on-one mentoring with a TopTile senior developer. And this person is going to help you with topics like project guidance, choosing an academic or career path, and also preparing for interviews, head to

topti.com slash scholarships to learn more and also to apply. All right, we're back again from the break with Andrew Nesbitt. And we've been talking about 24-point requests, an interesting way to give back to open source during the holiday season here at Christmas. So between December 1st and December 24th, Andrew and the rest of the gang that's a part of this is asking everyone to find ways to give back to open source that matters to them. So Andrew, the next part I'd like to talk about on this is ways people can contribute. On your contributing page, you have guides and things like that.

Like where did this come from and how do you guide people into contributing? Is it like people who are new to GitHub or new to open source? You know, who are you trying to reach when it comes to this? So initially it was aimed at people who use a lot of open source. And I kind of felt like as someone who's a lot of open source myself that I should be actively trying to contribute to some of these projects um but it's kind of moved towards much more of a way of making it kind of okay for to get into open source because so many people are doing it at the same time and sending their first pull request as part of 24 pull requests that it's moved towards like, okay, well, you can

get started here and then continue. And we've got a Gitter chat room, which is full of really friendly people. So people will hop in and go like, I'm not sure where to send my first pull request. Can you give me some tips here, like some things that I'm interested in? And other people will be able to point them in the right direction, help them rebase their branches, and do all the kind of the different,

learn about all the different pieces involved in contributing to a project. I see also has some other ways to find projects. So not only just ways that 24-port request is using that GitHub login to kind of get to know who's logging in and allowing them also to choose their own ways, but you also mentioned some of the places like CodeMontage, CodeTriage, and a couple others.

How do you find this list? And if someone out there is like, hey, I have a similar site, how do they go about getting in touch with you? Is the site forkable? Can someone update the site themselves and send a pull request for this? Absolutely. The, all of the pages are part of it.

It's a Ruby on rails application. And there's kind of a static controllers section that has all of this content in it. So you can if you have some kind of uh site that will help people to be able to get into uh sending pull requests contributing to open source definitely open up request um or even just an issue and say like can you add this to the contributing page uh all of the projects that are listed on the contributing page also get shown on the homepage when it's not December. So because 24 Progress doesn't really do anything for you outside of Christmas, it goes, here are some other different ways of getting involved

or finding out about projects that might be useful for you. You mentioned that another way this has kind of morphed over the years or change of the years is originally it was sort of focused on those who use a lot of open source and encouraging them to give back during the season and now kind of transitioning into a way to help people get involved in open source and you have another project called First PR which I actually used about a month ago when I first kind of picked up this conversation internally here. And I was like, that's pretty interesting. And I went and looked at my first pull request and I was like, that's embarrassing. So I don't know about you,

but my first pull request is kind of embarrassing. It's a good way of seeing what kind of your heroes, how they got started sending their first pull request. And that may not be their first ever open source contribution. It only works from the introduction of ProQuest 2.0 on GitHub, which is, I guess, kind of like five years ago or so. But for a lot of people, it will be their first time that they've contributed code to a project or documentation if it's part of their GitHub repo, which I think a lot of projects have started to move their documentation out of wikis and into repositories so that don't care for how the wikis are actually set up. I actually prefer an actual repo for it.

And that whole method, to me, just seems a bit better for docs. Yeah, definitely. And it aligns with all the similar kind of things. You could set up essentially Travis tests to check for typos and different things if you wanted to, or have those docs automatically published to GitHub pages when you merge the pull request. So before we transition this conversation to libraries.io, is there anything else about 24 pull requests

that the community needs to know about that we didn't cover? I think we covered most of it. If you're interested in actually helping move the site forwards or implementing other functionality, I'm always open for that. Most of the code now is being written by someone else for the project. I like to say that I've lost control of it. And if you're interested in either helping triage issues or kind of make improvements across the site,

especially for translation. The site has been translated into like 16 different languages, completely done by open source contributors. And if you want it in your language, then dive in. It's using standard Rails, like I18n translation, so it's easy to pick up that one file and translate it into another language and enable that for everyone else

who speaks that language to have a better experience with contributing to open source. Very cool. And that's on its own org too. So it's github.com slash 24 pull requests slash 24 pull requests. That's where the actual Rails app repo's at.

All right, let's talk about, well, obviously there's some pricing here, so I can't tell if this is your startup. What is libraries.iosu? The libraries is, I've been working on it for about eight months as another side project, which is kind of like, how can I, given the incredible range of open source libraries,

if I want to compare incredible range of open source libraries, if I want to compare a load of them to work out what is the best Redis client, if I'm writing some Node, that was kind of how it initially started. I wanted to index every open source library into one place in a standard format so that I could have a good quality search that bubbled the best projects to the top so that I could be sure that I was making the right decisions when picking a dependency. And from there, it's kind of wildly expanded and gone off in lots of different directions. Now, pulling out the dependencies for every library as well, and essentially building out a graph of the dependency network for each package manager.

And I think it supports about 29 different package managers at this point, and about 1.1 million different libraries. That's quite a bit. Yeah, so it's slightly grown beyond a side project, but it currently doesn't really make any money to support itself. So I've just started to look into ways of making it be able to support itself so that I can spend more time on it with some private repository tracking. So how that works, and it works exactly the same for open source

and is completely free. You can log in with your GitHub account and it will, given any repository, it will pluck out all the dependencies across every different package manager that it supports. So you might have a package.json and a gem file and maybe even a bower.json. It will find all the dependencies in that repo and it will tell you whenever there's a new version

of one of those things that's released. But rather than just doing it at that snapshot, it will also hook into GitHub and go, whenever you add a dependency or remove a dependency, I'll automatically start watching that as well. So you've got this kind of real-time view of everything that your application depends upon, and then you can be notified about anything that happens related to those dependencies. So say that one is marked as deprecated, or it has a license change, or potentially even removed from the package manager.

So there's like a good 7,000 libraries that have been removed from NPM since I started tracking NPM about seven months ago, which is crazy. You think I'm just going to do an NPM install and something is gone. Imagine if that happens whilst your machine is auto-scaling, say it's making a new version of another server in your cluster. If it does an NPM install during that process, that is just going to be a huge pain. Libraries just tries to give you that total view of everything that you use in a way that is essentially only going to tell you about things when they change rather than you having to remember to go and review your dependencies on a regular basis.

Can you talk about the real world example? I'm assuming there is some sort of pain you personally felt. You mentioned the original version of the idea and how it's scaled since then, but when you started to get towards more of the model it's in now, which is tracking all these different package managers and dependencies and all that you mentioned that it does, what are some of the real-world problems that you faced yourself that led you to build this? Well, so running a number of open source projects like 24-per-request and a number of Rails apps as well,

having either internally or as private repos or open source projects, the amount of times like, oh, there's a new version of Rails. Which applications do I need to go and update to make sure that I pick up whatever changes are made? Or potentially there may be performance fixes that unless I'm actively going to look for all of these changes,

like there's no good way for me to know when something moves in the transitive dependency tree of that application. And over time, especially working in Node projects, the size of that dependency tree is getting bigger and bigger and bigger. People depend on more and more libraries, and those libraries depend on more and more libraries. I just didn't feel like I had good visibility on all of the code that I depend upon.

So if one of those things breaks, I really may not even realize for a good few weeks before I actually go back and review those things. So I felt like I had no idea of all the code that I was dependent on. And I wanted to be able to kind of get a hold of that and then start to automate it because otherwise it just becomes kind of a collection of scripts which are useful to me but they should be useful to everyone else as well right at the same time picking all that data up and using it for the search engine so it feeds in things like the number of projects that depend upon a particular project. So it will highlight the projects that are highly depended upon in a community.

For example, imagine you're looking for libraries to convert XML to JSON in Node, that there could be 10 different options to do that. Probably the one you want is the one that is dependent upon the most by the community, which works basically the same as the Google PageRank, where the site that gets the most links to it is essentially being kind of crowdsourced as the source of, it's a trusted website.

Yeah, that makes a lot of sense. And then that passes down as well. So if Ruby on Rails depends upon a small library, website yeah that makes a lot of sense and and then that passes down as well so if ruby on rails depends upon a small library like mime types then you can pass a lot of that authority that ruby on rails is a trusted high quality project therefore if it depends upon mime types that must be pretty good as well even if people don't depend on it directly as much. Interesting. And so with it being a discovery service, I'm just going through the UI itself.

It seems like it's a lot of manual drilling where you can actually search. How do you feel about where it's at right now? What is the utility of going to the site and searching or poking around? What is the true value there for those that are listening going there and checking it out the real valuable bits that i see people using is given any application you can see a snapshot straight away of all of the dependencies without having to go poke around in different files and work out which versions of what thing I'm currently using and potentially any warnings.

So you can go to, if you're logged in, or we can look at the 24 progress repo. And basically the URL structure is libraries.io slash GitHub, and then the owner slash name. So it mirrors the GitHub URL structure after that first segment. And that will show you the list of dependencies for that repo, along with any potential warnings, the licenses of those things, the current latest version. So you can get a good view of if you've got anything that's out of date or potentially has a conflicting license, which is a whole area that I've only just started to touch on, but say MIT projects that depend upon GPL libraries, which is a gray area, potentially means that that project needs to be relicensed as GPL, considered like a

derivative work, or that it needs to swap out-licensed as gpl considered like a derivative work or that it needs to swap out that dependency with something else and for companies they they're kind of like license and licensing compliance stuff can cost a lot of money to have that reviewed manually or even get like a lawyer involved that if you can get a good view of like oh we seem to have like a conflicting license here let's just swap that out soon before we become really dependent upon that particular library i'm also noticing in the explore area in your footer you have a bus factor oh yes that's a fun term to throw around anyways. It's, you know, so for those of you listening, what is a bus factor? At least the way I know it is, is if you're the only person that has onus of something,

that if for some reason you got hit by a bus and you couldn't come into work today, how would we pick up and carry on? Is that pretty much what you mean by this? Exactly. Yeah. How many people in your team need to get hit by a bus before the project is essentially disabled or can't move any longer so when you pull back this list of improve the bus factors does that mean that there's not enough contributors not enough uh yeah so it looks at the number of contributors to that library which basically connects through to github uh and will go and it'll order by the projects that are depended upon by the most either other libraries or applications and then ordered by the number of the lowest number of contributors so most of the time it will show like here's a project that's depended upon by

200 projects and has one guy who's done all of the commit, which basically means if he stops working on it or if he decides to delete it because he's burnt out, then that's 200 projects that could potentially just be made unusable. So it's a good way to kind of go like, ah, well, here are some places that essentially are a weak spot in your dependency tree. Maybe you should like offer a helping hand or try and get him to share the commit bit with a few other people just to make sure that

this is like a key piece of infrastructure, essentially in the open source world that we need to make sure continues to work. Even if that guy is not interested in looking after it, that someone else can come along and, and make sure that continues to work. Cool. Let's let's take one more break. When we come back,

I want to talk a bit about the API and the docs you have for that. Cause it kind of dovetails from that conversation we just had into this. Cause I'm thinking if you can pull back searches for bus factors for example you know there must be the sky's the limit so to speak if you've got you know enough creativity in your mind on how you can actually use libraries.io to to kind of pull all these different dependencies and package managers to to really have some fun with it So I'm imagining that the API is going to power a lot of that. So let's take a quick break. We'll come back and we'll dive deeper into this cool project and the API of it.

We'll be right back. I have yet to meet a single person who doesn't love DigitalOcean. If you've tried DigitalOcean, you know how awesome it is. And here at the Changelog, everything we have runs on blazing fast SSD cloud servers from DigitalOcean. And I want you to use the code CHANGELOG when you sign up today to get a free month. Run a server with 1 gig of RAM and 30 gigs of SSD drive space totally for free on DigitalOcean. Use the code CHANGELOG. Again, that code is CHANGELOG.

Use that when you sign up for a new account head to digitalocean.com to sign up and tell them the changelog sent you all right we're back with andrew talking about libraries.io and we talked a bit about the bus factor and what that is and interesting ways you can probe and kind of fine-tooth comb what's available out there in the open source world. And you have this pretty awesome API. Can we talk a bit about the API? How does it work? What do you expect to happen with this?

Yeah, so there's a few different kind of APIs going on at the moment. For all of the searches, there's an RSS feed version of the search. So you can keep track of, say, any new libraries that work with Twilio that are written in CoffeeScript. And that you could plug into your RSS feeder or programmatically consume that to find out about new things that happen. Or there's the more traditional REST API, which is pretty new. And if anyone has any feedback then, or any feature requests, things it's missing, please do let me know because it's really only existed for a couple of weeks and I'd love to get more people kicking the tires on it. That would let you essentially pull out all the information about every different library across every different package around here in a very standard way, which is exactly how I envisioned, like, if I wanted to work on an API that worked with all these different kinds of libraries, that I'd need some standard way of talking about them.

So it tries to normalize out the differences between different package branches. And there may be some information missing for some package managers, like Bower doesn't really have a good concept of versioning in that everything is in Git tags, in GitHub. There's no real like active publishing of a new version of a Bower library. But I've tried as hard as possible to make it completely standard.

So you can essentially look at the same, use the same tools against different package managers. So if someone builds something for one language, then it can be useful to everyone. Rather than kind of a siloed effect of people building, say, things just for NPM, all the other communities can also benefit from those kind of things. And during the break, we had a kind of an interesting conversation too, about I guess ways this API can be extended and just different fun things. And we talked a bit about in a way, kind of linting a repository or a pull request whenever someone contributes back. And we talked a bit about some hypothesis, some future ideas, something that maybe it's not even quite there

yet. Where do you see this going? Yeah, so the nexus of where I'm moving towards, the kind of other pieces I'm trying to put into place with the deprecation warnings and the license conflicting warnings and the security vulnerabilities, which are pretty close to getting shipped, is to be able to do that on a snapshot of a branch or the difference between a branch and master. So you can imagine a service kind of like Travis that hooks into your ProRequest and goes,

okay, you've opened a new ProRequest to this repo. You've added a dependency, and let me review that new dependency and see if it matches the different options that your organization has decided, like, we're going to follow these. So that might be, we're not going to let you merge any new dependencies that have security vulnerabilities that match that particular version that you've included or that have no license that we can find for them or say have a really high bus factor like there's only one contributor to this project that's not necessarily a good thing to depend upon because there's no one else there to support it and you can imagine actually having like the the red green come out of that where it goes yes your dependencies that you're adding look fine or no they don't you can't merge this pr

because it's red and i can see that being a really helpful thing for open source as well to kind of it you would at least i personally don't review every dependency that i add to an application manually or to look at its transitive dependencies and see like is there something that i should be worried about in any of these things we should be able to do that fairly automatically and then warn you kind of proactively don't add this thing to your application because it might cause you pain further down the line do you have any ideas for how someone might list or manage that will be there will there be like a library's file for example almost listing somewhat somewhat similar to like a gem file for example kind of saying this

is what we want to keep or we want to avoid you know gpl3 for example because we're mit you know whatever it might be yeah most character code or whatever you know however you can kind of like throw in there how was that going to work So I imagined it working by essentially an org level that you'd configure it inside of the libraries.io dashboard. But you could also do it on a per repo basis with like a.libraries.io.yaml file. Very similar to the way that traffic works, where you can go like, for this repo,

actually it's all running inside a firewall. We don't need to worry about security related things because this is running completely internally and not a problem. Then let's skip all the security warnings. We don't need to worry about that. Or for this project, it's public domain, open source project.

It doesn't matter if there's DPL things here or whatever, the whitelist of licensing things here as a little config file that you could overwrite the org-wide setting. I think that's a really interesting take towards it too. I mean, I really, I have to admit I was slightly skeptical at first, like, okay, this is a pretty useful thing, but I wasn't really sure how many people out there would actually, you know, maybe go to the site and check dependencies. And then

I was also going to ask questions about the notification process, but I really see the utility in having it, you know, at the developer level where you're, you know, in the command line, you're already, you know, doing pull requests, you're already pushing to your CI server or whatever it might be, and having that real-time feedback whenever you might even be doing a pull request, I really see a lot of usefulness in that utility part of it. gem file as soon as you saved it i i haven't quite worked out if that is a feasible thing but the the api would allow you to to do that anywhere that you would run any other kind of linter it just might take a little bit longer uh because it's got to go past but depending on the language some programming languages have really nice uh formats like all their manifest files are written in json or toml or yaml other ones need like to actually run the code in the language that it was written in things like lua and closure all of their manifest files are written in lua or closure which is difficult to reject out of all

the dependencies we've been talking about a couple of these features, and some of them are there, and some of them seem like they may be dreams of yours. How far are we away from this linting world as we've been talking about it? The linting is working internally, and so libraries tracks its own dependencies, which is pretty neat to get the project to be able to kind of eat his own dog food and it will it uses

a lot of the webhook API as well so it will open an issue on github and the webhook API is pretty poorly documented on the site at the moment but there's a lot of little open source gith GitHub projects on the library's IO GitHub org that show you different ways of doing things. So it will rerun its tests automatically every time there's a dependency updated. It will open an issue if there's a dependency that's not a pre-release that's been, the version has been bumped. And it will even potentially,

you could have that tweet or post to your Slack room to say, hey, there's a new version of this thing. I've got it tracking and kind of reviewing the dependencies that I add to the project itself, but it needs work mostly around the configuration of the options, as you say, like there needs to be that YAML file, be able to say,

here's the things I care about, which may not be the same as other people. And I reckon it's probably another a month away before that live on the site. So this is a open source focus, but it's not an open source project, right? Not at the moment. No, I'm trying to work out exactly what to do with that. I'm kind of halfway between the two I haven't landed on. Do I open source it all as, say, like a GPL, or do I continue to run it as a proprietary bit of software? A lot of the pieces of it are open source,

but the main Rails app is currently private. It's certainly interesting, especially whenever you start talking about, I know so many developers and teams are using Slack and obviously using Twitter. So those two mentions of like tweeting to, you know, that seems somewhat okay to me, but I think, you know, maybe a lot of ears perked up when you said Slack integration potentially. okay to me but I think you know maybe a lot of ears perked up when you said slack integration potentially so I know for us you know anytime we have you know here at the change law we have a private kind of activity area where if things happen things get triggered and it's an area where Jared and I and the rest of the team we kind of keep an eye on it and those are like critical

things happening so if those things if something gets posted there we know it's not a good thing it's somewhat of a bad thing and we get on it right away. So I can kind of see some utility in that too because it removes the bus factor, so to speak, whenever something bad happens. And if you've got a team and you're kind of triggering notifications back into Slack or via email, I'm kind of less interested about email because I think people get a lot of that. But I think Slack seems to be like the next better thing to an email response on a notification. Yeah I haven't written a Slack box for it yet most because

I'm working on this on my own most of the time and I didn't feel the need to hang out in my own little Slack room so I have it open issues on GitHub for me instead but that's definitely something that can be built on the webhook API that's there already.

I just really need to write some documentation for the thing. And then you can have that either only post me like major versions or like new big versions updates, or maybe even only go like, I just want to post about any potential security vulnerabilities that are announced on the things that any application across the whole GitHub org depends upon. Well, I'm not sure if you heard about it yet, but there is a brand new repo as of yesterday when Slack made that announcement about the app store they're having and stuff like that and this ecosystem and whatnot. They also released a thing called BotKit.

Actually, I don't think it was them directly releasing it. It was a team or I think it's an org on GitHub. And I think it's just Howdy, but it's H-O-W-D-Y-A-I. And so on that user, so it's that namedy but it's h-o-w-d-y-a-i and uh so on that user so it's you know that name slash bot kit is the repo so there's a bot out there for you know a toolkit for building bot applications for slack so they may have just made it so much easier for you okay so maybe by the time that this podcast goes out there may be a libraries.io Slackbot available. There you go. Well, we love that.

So, I mean, it's also available via NPM. So you're already familiar with that. So it seems like it's, you know, we're actually thinking about doing something like that ourselves around here at the ChangeLog. I was telling Jerry this the other day. I was like, it would be pretty interesting that if we can have something where it integrated into slack and rather than just subscribe to what we do here at the change law between our podcast our email things we tweet and different stuff that we plan to do in the future i was like it'd be kind of interesting to be able to pipe that into some sort of slack bot and allow people to subscribe to it yeah and

so i think that's a really interesting way that teams are hopefully it doesn't get too spammy that's my only concern, honestly, with that. If it becomes too noisy, you just fuzz it out in the background. Yeah, exactly. So I think there's a happy medium that we have to all be mindful of. And that was my only worry with it was like, should we do this? Are we like just enabling, you know, not that we're spammers, but are we enabling us to become known as maybe spammers because somebody integrated us and another person's like, well, I'm tired of the changelog. You know, I don't know.

Who knows what? But just always got a toe line of, you know, too much noise, not enough signal. And we always focus on signal around here. Yeah. Maybe having the ability to have the Slack button tell you about episodes of the changelog that are about a particular language. See? So I could just go, I'm not interested in any Java-related changelog episodes. So don't tell me about that to try and reduce the amount of noise.

Yeah. Well, what else could we cover that we may not have covered well enough for libraries before we tail off the call? I think we've covered things pretty well. So I've not got to the point of I'm balancing on whether to actually turn it into a real business or to turn it into kind of – because it's built on so much open source and the data should all be open source, should it be an open source project? How can I make it continue to support itself? Because it gets quite a lot of traffic now, I think, 50,000 visitors a week from Google, which ends up costing money. So I need to have some way of running it.

Do you have any ideas about how I could potentially support that? A couple ideas might be to potentially find somewhere, I guess, not so much to be employed, but somewhat where it's almost a partnership. So this would benefit someone else really greatly, you know, and they may essentially foot the bill of you being the developer of it and kind of bankrolling and you essentially become an employee. That can have its own pros and cons. You might even do other ways where you have sponsored things where you're not really, but it really kind of depends on your motives, right?

Like if I don't know what you do for your day job or what you're doing for freelance or how you earn your living. I do freelance application development and performance tuning and things like that, which is fine. But I'd really like to spend more time on libraries, especially around the side, kind of the area of the bus factor. And there's also like an unlicensed libraries page, ways of producing calls to action for, in a similar way to 24-hour requests with more focus, like here's some pain points in a community that could be solved or helped

with, or here's some maintainers who might need some help because they're completely overwhelmed by the amount of people using their project. Be able to use the, harvest the data inside of libraries for ways kind of as a force multiplier for open source, given these projects we know are depended on by a lot of people, can we, what ways can we support that project or like expose it to people? So they're more aware that this project might need some help. Yeah. It's a, it's a borderline public service, borderline utility for enterprise or commercial.

So there's several different angles for it, for sure. Yeah, there's definitely that angle of enterprises seeing those projects potentially as a center of risk. And so if we can encourage enterprises that really heavily depend on those projects to maybe give some financial support or some developer support, if they have a team of, say, 200 developers, I can, one of those developers help to maintain that library for a certain amount of time.

Right. Would be a great way to potentially help solve this current. And I'm pretty sure it's going to get worse, the problem of open source maintainers kind of burning out from essentially giving out all their time for free and getting very little support back. It is a tough problem to solve. And I've heard before that if it's a hard problem to solve and you're already trying to solve it, it's good that you're trying to solve it. That's also meaning that you could be heading in the right direction because anything that's easy isn't worth doing. Yeah.

Which isn't exactly a perfect saying, but what I mean by that is if it was easy, everyone else would do it too. So it could be something that's very profitable to you. It could be something that's not, but you got to put in the work to do it. And it seems like you're doing, you're heading down the right path, that's for sure. So I think that I don't have any particular exact advice I can give you here,

but what I can say is that if there's listeners out there that have some ideas, how can they get in touch with you? Is it an issue they should open up or? Yeah, so there's an open source GitHub repo on the Libraries.io GitHub called Support, which is essentially just an issue tracker. Probably the best way to kind of publicly put out those ideas. Or you can get hold of me on Twitter. Cool. We'll put the link to that repo and issues in the show notes. So if you're listening now,

head to the show notes, you'll see a link there to get in touch if you've got some ideas. I mean, I think it's really, really interesting. I'm sure there's people listening to the show now thinking, that's really interesting. How you can turn it into a business, that's the hard part. Well, here's a chance for you to highlight somebody that's been really influential to you.

We asked this question on the show. It's, who is your programming hero? And so who's been really influential to you? We asked this question on the show. It's who is your programming hero? And so who's been really influential to you? I was pondering this today, and there's a few people, but one person stands out in my mind. It is Jespo. She's a developer based in London, and she also helped a lot with 24 Progress

a couple of years ago. And she started a project called CodeBar, which is essentially a movement to help diversity and kind of underprivileged groups to get into programming, focused in the UK. But she kicked it off and kind of completely open sourced

everything she was doing and has turned it into like this movement, which is sweeping across the UK as a way of saying like, how can we get more women and more kind of underrepresented groups into programming by producing lots of free um courses and tutorials and everything has been done and kind of she set herself up as a way that it wasn't dependent on her so it's spread and it's i think she's got like five or six groups now running around the uk on a regular basis they're introducing more and more people into programming.

And I think it's just amazing if I can have that kind of impact. Yeah. So I didn't catch her name exactly, but it's CodeBar.io if you're listening. What was her name again? Despo. How do you spell that for me? D-E-S-P-O. D-E-S-P-O.

She's on Twitter and GitHub as Despo as well. All right. We're going to put a link to her Twitter account and her GitHub account in the show notes. So if you want to check out Despo, I'm curious to know her full name, her real name. Maybe she's being anonymous for a reason. I like real names. But if you're curious about her and what she's doing, you can go to CodeBar.io or you can check out the show notes and find her Twitter links. It's also Despo. Well, today we're actually doing a little bit different. So this is

our unusual holiday episode. We wanted to team up two shows we did. So we talked to Jonathan Rudenberg about Flynn about three or four weeks back, and it wasn't quite long enough of a conversation to have as a full episode. So what we're doing is we're combining this 60-minute show with that 35-minute show. So it's roughly an hour and a half, but that gives us our full-length show. So we've combined 24 pull requests, libraries.io, and Flynn into one single awesome Christmas holiday episode. So hopefully everybody listens to it and really enjoys it.

And at this time, we're going to take another break, but it's just the goodbye for Andrew, but it's not the goodbye for the show. So we'll take a break. And when we come back, we're going to be talking to Jonathan Rudenberg. But before we go on that break, Andrew, do you have anything else to say to the audience? Any more advice you want to share back to the open source community? No, just have a great Christmas holiday. Well, thank you for coming on the call.

We're going to go into the break. When we come back, we're talking to Jonathan about Flynn. We'll be right back. If you thought Harvest was only about time tracking, check again. Fast invoicing and payments. You can easily create and send invoices and accept payments with PayPal, Stripe, and many more. You got expense tracking without the mess. You got an iPhone or an Android app to go on the go with you.

Snap photos or receipts and store them in the Harvest app. You can also connect favorite tools like Slack and use chat commands to start and stop your timers. Head to GetHarvest.com and start your free trial. And once that trial is over, use our code CHANGELO to save 50% off your first month. All right, we're back from our break here in this special Christmas holiday episode part two, talking to Jonathan Rudenberg, the creator of Flynn, a next generation application platform. Now, Jonathan, the last time you were on the show was December 20th, 2013, nearly two years ago. You were on episode 115 most recently, and then once before that again on episode 99. So it's been about two years since we caught up with

you, caught up with Flynn. So kind of catch us up with the last couple of years of Flynn. Yeah. So we've had several major releases. The most recent was our stable channel, which was a week and a half ago. And it is the first release of Flynn that has an updater that can just update Flynn in place with near zero downtime. And it's basically good to go.

And you don't have to use the nightly like bleeding edge release anymore. So what is this? What is a channel? When you say channel, what does that mean? Think of it like a browser release channels. So like Firefox has several release channels. There's a release channel.

There's a like a beta channel. There's a developer channel and there's a nightly channel. We currently just have two channels. We have a nightly channel and a stable channel. And we may like adjust that. Uh, but we're doing this kind of browser style rolling release model where, um, it's like release train. So you end up with a new release every, um, every so often currently we're doing it every week or two and we're just rolling out a new update and we're not like, we're really concerned, but version numbers, we're just, um, just rolling

stuff out. So working is all that really matters. You're not caring we're really concerned about version numbers we're just um just rolling stuff up so working is all that really matters you're not caring about you know breaking changes in the past um yeah so the goal here is to have uh backwards compatibility with the past um for now like quite a ways back so the command line tool will work with forwards and backwards and you know like the dashboard won't break when you update but and any api integrations that you built won't break but we'll be adding new apis in a backwards compatible fashion interesting so let's uh before we go a little bit further let's kind of break it down for those who didn't catch episode 115 episode 99 which were awesome episodes uh and you weren't alone you had had Jeff Lindsay with you.

Is Jeff still part of the picture? I think he moved on like beginning of 2014. He's been doing all sorts of other stuff with Docker and so on. And we've just been like hyper-focused on building a platform that helps you deploy your applications and is super easy to deploy anywhere. So the idea is that you write code as a developer and getting that code into production currently

is really painful. You end up having to duct tape together a whole bunch of components that you might want to use containers. And now you've got a whole like new set of challenges. And we found that a lot of people were spending a ton of time just working on the deployment and orchestration of their applications.

And so our goal is to make it as easy as possible to deploy your applications in a highly available fault tolerant way and not just stateless web applications, but also things like your backing stores. So we have what we call a Postgres appliance, which it is fully highly available. And if you're running across three nodes and one of those nodes fails, it'll just keep on working and it won't eat your data and it's safe to use. Kind of reminds me a little bit of the conversation we had with Mitchell recently.

I'm sure that auto was kind of interesting for you to see, and it's promising a better deployment process. How does something like auto fit into this world? Is it a competing thing? Is it a competing ideology? I'd say it's a competing ideology. So what we have is we have this idea that you should not have to worry about how things are deployed on your servers.

And I know auto is doing some of that, but it's doing it slightly differently in that there's a whole bunch of like underlying stuff that you're going to need to know about. Like are you using Nginx and how does that hook up to PHP and so on. With Flynn, you may need to worry about that, but probably not. It's just going to work out of the box. And we've got it set up in such a way that you can just go to production right away and you don't need to worry about um the difference between development and staging and production and

so on i think auto's not concerned about where you're putting your stuff whereas it seems like flynn is more the platform you're deploying to and part of that platform you're deploying to you have the ability to deploy as part of this platform is that maybe a layman's version of describing it i yeah i find the whole space just really confusing and we're trying to unconfuse that's part of the show is to demystify some of this stuff yeah um so my i really don't like i haven't actually used auto i've looked at it a bit um if you think of something like Heroku, where you're just like Git pushing your app and you don't need anything running on your local machine,

except for Git in that case. But you can also use our web dashboard, which we'll clone from GitHub. And you don't need to have any local development tools installed on your local machine in order to use Flynn. If you want, you can install the Flynn command line tool and manage your Flynn cluster using that, but you don't have to. You could just like edit your code on GitHub

and then go to the Flynn dashboard and click deploy. So if we rewind back in time a little bit, since you were back December 30th, sorry, December 20th, 2013, episode 115. At that time, your page title on Flynn.io was Open Source Platform as a Service, powered by Docker. Your page title now, which to me, that's just like a little quick description of like a snapshot of who you are. Yeah. And now it says the product that Ops provides to developers. But then on your GitHub, it says Next Generation Application Platform.

A lot of buzzwords in there, a lot of confusion if you kind of just trace back a bit. Right. What does all that mean? Okay. So originally we were very much designed as a platform that was built around Docker and it was designed to be a bunch of components that were like easily composable and you could like use a single component without using the whole thing. And what we found is that while a few people were interested in the idea of that, easily composable, and you could like use a single component without using the whole thing.

And what we found is that, well, a few people were interested in the idea of that. Very few people use that in practice. And what people actually want, we talked to many, many potential users and people that were using what we are like prototypes and our MVPs and so on. And what we found is that everyone just wanted something that let them deploy their apps and they didn't really care how it worked. So this is very much for if you don't actually like want to think about individual components, Flynn is for you. It's absolutely all open source and all the components are really easy to wrap your head around and you can totally modify it if you want, but you don't need to. It's just, it just works. That's the idea. I know before we talked a bit about fundraising and that line gets a little bit blurred when you talk about where money's coming from. Was it VC funding?

Was this private investment from the community with no obligation for return? Can you talk to us a bit about the fundraising version that you've done and what that looks like as your company? Is it a company? What is Flynn behind the actual software? Yeah, sure. So when we started, we were not a company. We were just a project that had a single webpage that said we would like to build a platform along the lines of Heroku, but open source and you can deploy it anywhere. And that really resonated with especially the Hacker News community. And we ended up raising close to $120,000 just in like kind of a Kickstarter type thing in order to build that. And so then we took that money and we built out an MVP of

the platform. And we actually got the whole thing working. You could boot it up in a VM and deploy. And we decided that we wanted to like take it much further than that to be actually production ready and much more full featured. So we evaluated a few options. We talked to a lot of the original contributors and some new ones. And we found that there wasn't a whole lot of interest in putting more Kickstarter style money into it. So around that time, that was in 2014, the beginning of 2014, we applied to Y Combinator, which is a startup accelerator in Silicon Valley.

And we got in. And so we took we did a seed round in the summer of 2014 and we hired a team. And so Flynn is actually Prime Directive Incorporated. And we make Flynn, which is entirely open source. And we will, it's not open core. It's just an open source product that you can run anywhere you want. You don't need to pay us anything for it. And we continue to develop that. And in the future, we'll have mostly SaaS products that integrate with Flynn

in a way that doesn't compromise the open source nature of it. I'm really interested in the process of applying to Y Combinator. Can you talk a bit about, as much as you want, honestly, I mean, from the process of actually pitching to, you know, what was the real idea they bought into? Because as you said, it's sort of morphed over time. So what was the pitch then? Yeah, applying to Y Combinator is, I guess, strange is one way of describing it. There's just a application with basically infinite questions on it. And it's really a flip of the coin whether you get an interview or not, just because there's so many applications.

And after you do, you apply, there's an interview process where you do this rapid-fire 10-minute interview with three or four partners at YC. And I think what they really liked was that we had a working thing that allowed you to deploy apps from GitHub with basically near-zero friction. And that is something that they got. And so that's why we got it.

Is this unique to you? I mean, being what you just said, like, is there anything else out there like you? There are other platforms. I'd say the vast majority of them are limited in some way. They're either very hard to install or like not easy to install, or they, most of them only run stateless web applications. They don't have stateful services built in like our Postgres appliance. I'd say just, I don't think there's any other platform out there that is trying to do the same thing that we're doing, which is to be the like super easy to use, super easy to deploy and manage and does everything you need out of a platform.

You don't need additional tools or components to use with it. So maybe give me an example of a typical Flynn production setup, like be agnostic if you'd like to. I mean, I'd imagine people are thinking about AWS or even our friends at Digital Ocean who sponsored the changelog. So we have an affinity towards them, but, you know, give me an idea of what it looks like to have Flynn in production.

What servers are actually bare-metal hardware needs to be in place? What languages people are dealing with? What are some of the things that requires Flynn to be in production? What's it like? Yeah, sure. Okay, so we have a super easy installer that basically you install the Flynn command line tool, but you don't actually have to use the command line to install.

You just type Flynn install and it opens up in your web browser from a local web server that's in the command line tool. And there's an installation wizard that is very easy. You can point it at AWS. You can point it at DigitalOcean, Azure, or even give it SSH credentials to a few of your own hosts. So if you wanted a highly available cluster, you'd tell it to boot up three instances on, say, DigitalOcean, and it would tell the DigitalOcean API to boot those instances up and deploy Flynn to them and configure it,

and you'd be ready to go. It would take probably about 10 minutes, and most of that is just waiting for the instances to start and install packages and so on. So how much of that is kind of like magic inside of it to start it off easy? And how much does the developer have, I guess, control over changing that? There's absolutely control over it. You don't have to use the installer. You can use that we have a script that is much more minimal in that you can just run it on existing hosts. There isn't that much to configure in Flynn.

We've designed that intentionally just so that you don't have to think about too much. It's just configured to work out of the box and we're just shipping best practices with it. So you get stuff like, for instance, like I mentioned, Postgres. That's just highly available out of the box. You don't have to do any configuration whatsoever. Is there a reason why it's Postgres and that's just highly available out of the box. You don't have to do any configuration whatsoever. Is there a reason why it's Postgres and not MySQL or something else? Like maybe even Rethink or, you know, insert database name here?

Right. So we started with Postgres because we wanted to keep Heroku compatibility and Heroku has Postgres as a first-class citizen. So we're using Heroku Buildpacks to deploy apps as well. But we'll be adding more data appliances in the future. So stuff like RethinkDB and Redis and MongoDB and all these things that are used quite extensively will be coming to Flynn in a way that is just as easy as our existing Postgres appliance in that you just say, hey, I need a Mongo database for my app, and it sets that up for you. So in your own words, what is the problem and then the dream of the developer that is like, man, Flynn is awesome, I love it? Okay, so the problem, I assume you're asking, like,

why would someone choose Flynn? Like, what problem is it solving? What does it solve for them? Yeah. I'd say that this is the, currently it is the hardest that it's ever been to deploy an application. Like think back to when you could just FTP PHP files

up to a shared host somewhere and that worked. Right. And it's actually the easiest it's ever going to be to deploy apps. So there's more and more tools. You have to worry way more about security. You have to worry way more about high availability and backups and disaster recovery and so on, just because people expect way more out of the products that you're selling them on the internet as SaaS and so on. Even just a static

website needs to stay up the whole time. So I'd say that is the problem that we're solving, this problem of how do I get stuff into production and keep it up and running? So when Flynn solves a problem that was designed to solve, what's the dream of the developer? What's that look like? Yeah. And so that is a single cluster where you can just run everything, whether that be a stateful app that is legacy in some way, or you wrote internally, like there's many companies out there that have, they have special databases that they wrote, like a graph database that's specific

to their use case and so on. You can run that on Flynn as well as, um, all of their apps, whether they be from like open source from GitHub or developed internally as internal apps or developed as customer facing stuff, all of that that can be deployed on a single platform, and you don't need any other tools to manage that in production. So all you have to do then is just pick where you want to host your stuff and have fun, I guess. Is that right? Yeah, absolutely. And I should mention that there are definitely some areas

where we're still working on it. So I'm currently working a lot on the security parts of Flynn. We, um, we basically have no internal authentication and, um, there's, uh, there's a bunch of, there's no user management and so on. So we're, we're working really rapidly to fill out these gaps that we see as barriers to adoption. I was reminded when you said that of your Twitter handle, uh, not just your handle, but, uh, your, your bio and your Twitter. And it's like security focused computer hater. I've never really heard anybody say that, but that's, that's interesting. Yeah. Um, I really think that where

we are with computing is, um, it's not great. It's just computers are very unreliable. They don't do what you want them to do. They're very insecure. And so I'm working on fixing that. Gotcha. So, Flynn, in the past when you were on with Jeff, we talked about Doku, which was something he had written. And then you got Deus out there. And for those out there listening now and they're thinking, okay, Flynn, Doku, Deus, and XYZ that I may not have even covered

that we haven't heard of yet. Where does Flynn fit in? What is the future of what Flynn is in comparison to the other options out there that promise the same or similar thing like platform as a service? It really depends on what we're talking about here. I think for the most part, we can generalize and say that there are many platforms that are like successors to Heroku in that they have basically the same functionality, except

they are open source or not. There's some non-open source platforms that are Heroku clones, that you can run elsewhere. And so like I think of some of the ones that you mentioned as being in that bucket. Doku is the one case where it's even more limited in that it's only designed to run on a single host and it's very, very minimal. But most of the other existing platforms are, they're just direct copies of Heroku in that they run stateless web applications that serve HTTP traffic. Okay.

And so I guess maybe that makes me think about what your inspiration was then. So if those seem to be successors or inspired by a Heroku situation, what was the beginning of Flynn like for you? Definitely inspired by Heroku. But we really wanted to take it further and say, hey, I got apps that I can deploy on Heroku or a Heroku-like platform, but what about all the other stuff like my databases and like an IRC server or a mail server? Like, where do I deploy those?

And the answer at the time was, oh, you spend a while writing some configuration management scripts that are like very specific to the host you're deploying on and you manage those separately. And our goal is to make it so that you don't have to do that. You can just deploy all of your stuff on Flint. When you look at the platform as a service, I guess, landscape, if dare I even say that, what does it make you think of? Like, does it encourage you more to what you're doing with Flanners? Are you like, wow, we've really got a, you know, a blue ocean here because they're not

thinking the way we're thinking. What does the landscape look like to you? Yeah. So I think I'd rather expand that to not just platform as a service, but like there's a whole, there's this whole like new infrastructure space. And the focus seems to be a lot on very specific tools. So you have, you know, a service discovery tool or a container management tool or an overlay networking tool. All these things are components of a well-built platform.

There are very few well-built platforms. And if you don't have one of those, then you're stuck kind of gluing these tools together and ends up being a lot of work. And it's a lot of time and it's just not as resilient as it could be. We already talked about getting started to a degree. We talked about being production ready. So when you say stable channel, that means that it is stable. It does work and you were suggesting that it should be used in production. Is that correct? Yeah. With a few caveats. So we definitely have people that are using it in production. There are like not bug-free in that people are finding issues now and then, and we do fix those pretty fast.

But the main thing right now is that we don't have multi-user support or the ability to run even close to untrusted code on the platform. So there's a bunch of internal APIs that are exposed that we need to lock down more. That is the main thing we're focused on right now is making sure that it's secure enough to be able to deploy anything that you found on GitHub without worrying too much about it. This is sort of a slight tangent to a degree, but I had it down here and I can't leave this conversation without asking it, which is what's a typical day in the life of Jonathan like? You know, what do you what do you do? What's what's Monday through Friday for you? Or is it life of Jonathan? Like, you know, what do you, what do you do? What's, what's money through Friday for you?

Or is it Monday through Monday? I don't know. Is it seven days a week for you? I know it would, that would definitely be like Monday through Sunday. Okay. Yeah. So typical day looks like I have a bunch of GitHub emails in my inbox,

various pull requests and issues and so on. And so I do a bunch of code review and respond to issues, catch up with people in IRC, and then get to work on my list for the day of software that I'm developing, whether that be actually software, writing documentation, and all the while, like watch IRC and our internal chat for issues that come up. So we try to be super helpful

in IRC. If you have any issues with Flynn, you can get ahold of us really easily. And we actually have people in different time zones. So the coverage tends to be pretty good. We haven't really talked about the size of your team, really. What's the size of Flynn like these days? We're about half a dozen people. Wow. Okay. Yeah. So I guess being through Y Combinator, coming out, what is the state, I guess, of, dare I say, runway? I mean, that's really what it is. I mean, somebody's got to pay for your time. You're worth a lot, and so is the rest of your team.

So there's funding. There's money there. What is it like on the funding side? Do you have a long-term partner who's like, hey, I'm just interested in a long-term future of this. Pay me back when you get a chance. I'd say the answer is that the funding ecosystem is complicated. And I don't really want to get too much into the weeds here. But we have no concerns about our runway.

And hopefully, yeah, we have absolutely no concerns about our runway and hopefully yeah we have absolutely no concerns about the runway we'll keep developing for the foreseeable future some back story on that question to you wasn't loaded I promise but we had a conversation with as I mentioned before with Slava Akhmachet talked about RethinkDB and

Jared and I were both surprised by the patience not so much that they're not doing what they should be doing, but he just seemed to have investors who were like just more flexible. I don't know how to describe it. And then obviously Mitchell, he took a little bit of funding recently with with HashiCorp.

And then we also had the guys behind Metabase on recently, which was also VC funded. And so we're, we're seeing a trend here and I can't help but ask questions of like, okay, if you're taking investment and you're building a company, but you're also completely focused on open source like you are, you know, just not so much like a devil's advocate kind of thing, but like, how do, how do you as a software developer navigate that world and how can you share

or encourage other developers out there that have just as much dreams and ideas as you do accomplish some of their goals yeah um and okay so i think there's there's a few things that we should unpack here um the first one is uh vc funded open source which i think the jury's still out on there's um there there are a lot of new companies that have been funded recently that are working on open source, either full-time or part-time, whether they have commercial products or not. There's a whole gamut of stuff. And I think the interesting question, and I don't think it's been answered yet, is how does that play out? What are the business models that end up being successful? Because there are very few successful open source companies that you can point to that have been around for a while.

And I think the big one you can think of is Red Hat. And they have a very relatively enterprise-centric support contract business model, which works well for them. But I'm curious to see how that scales and whether these new companies are in that same position. We're very focused on not compromising the open source nature of the project. So as I mentioned before, we really don't want to do open core, which is where you have like enterprise features

that you're selling and you're actually selling binary software to run on servers. And we're just not interested in doing that. So we're really focused on how can we be successful as a company without having to compromise the open source nature of the project. And so far, we think the answer to that is SaaS products that are really a huge value add to Flynn without having to install any binary proprietary software on your computer. And, um, the other thing that is worth discussing is, um, this, like, if I have an open source project, how do I, you know, take it to the next level? And I don't, I don't know the answer to that. Uh, I know that one answer is absolutely raising venture capital. Um, it is,

it is complicated and it really depends on your situation. Like that's a very person specific thing. There's yeah. Yeah. I kind of figured that cause it's, um, you know, I figured with Y Combinator, it would just make sense. The process of going through that. And you obviously get exposed to a lot of, uh of people who are willing to invest. So through that, you might come out with new connections, maybe no particular ties with YC. I don't know what the terms are, but I think usually it's like 5% or 10%. They take some sort of equity.

They take 7%. They give you $120,000. And the big deal with Y Combinators, you get to go to Demo Day, which they have a whole bunch of early stage investors. And so it ends up being relatively easy compared to not going through Y Combinator to raise a seed round of a million or two or $3 million. Any other particular insights or advice that you, if you had the ear of the open source world on, on accepting money, taking VC, what this process is like for you, anything you want to share? I think that it's important to think really carefully about the, um, the goals of the

project before you're considering funding and how the funding will impact that. So whether you can find, uh, investors who are willing to like go with the open source nature or whether they will pull you towards selling proprietary products, which that's definitely happened. So you'd mentioned that some particular SaaS models that you have ideas for is very, I'm not asking for product names or whatnot but is there anything in particular you can share about what the future of i guess revenue generating things will be for flynn um is it i don't really i think it's i think it's too early we're like super focused right now on getting people happy with flynn so if you are a, um, if you are like,

have the problem that we're trying to solve, which is deploying stuff is too hard and takes too long and you need something like Flynn, then we're really interested in getting you using Flynn. And that is our focus a hundred percent. And our investors understand that and are totally up for that. And so I think that the monetization will come a bit later after we have this really great core of community of, and we already have over 90 contributors to the open source project and our IRC is pretty active. We're super interested in building out the user base and community of Flynn. As we were talking a bit earlier about the day in the life of Jonathan, I was thinking, okay, you got 237 open issues right now on the Flynn repo.

So your day must be pretty busy just considering the traffic of issues on the project alone. I think you mentioned the popularity a bit. So 400, or sorry, 4,025 stars. So it's definitely popular. If you have the ear of the open source world to step in and help out, how could our listeners step in and say,

okay, I'm interested in Flynn. How can I be of service? What can I do from an open source perspective to move things along with you? Yeah, there's lots of cool stuff to do. So the very easiest is absolutely just installing Flynn and trying it out with your apps at work or your side projects and so on. And seeing if it works for you and if it doesn't, telling us why it's not working. And we really want to fix that.

If you actually want to commit some code or docs, there's lots of stuff to do. The reason why there's so many issues is we actually track feature requests on GitHub too. So there's we've got an easy tag on GitHub. And if you just click on the easy tag, you should see a bunch of like things that you could get done in an hour or less. And Flynn is really easy to contribute to. It's written in Go and we have a development environment that spins up in a VM using Vagrant. So you can just have like one command and be ready to go and work like develop Flynn locally. I love this easy tag. It's so cool.

You got 52 open issues. I don't like that. They call them issues either. Cause it's not, doesn't mean like you got, you know, 230, whatever bugs out there.

It's, you know, the legitimate community focused conversations basically. Yeah, absolutely. This easy tag is really interesting though. I don't know if you had, we connected a little bit there or had a bit of a lag.

The, I was just talking about the easy tag. I think it's really interesting. I don't know if I've seen that before. Where did you get that idea from for an easy tag? To be honest, I don't really remember. I think I've seen it in a few repos.

I couldn't name one off the top of my head. The idea, though, of having these relatively small chunks of work that don't require a ton of knowledge and get you started contributing to the project. I'm really excited to help new contributors work on Flynn because it's really neat to see the new perspectives. And it's always nice having see the new perspectives and there's, it's always nice having someone else write code for you. Yeah. Whenever you can get the community to step in and help out with the, with the actual mission of the project is always going to be a good thing.

So. Yeah, absolutely. Okay. I guess we really haven't talked too much about language, but I know Flynn's been written in Go since the beginning. Am I right on saying that? That's absolutely correct. Okay. So having been, what's about four, three or four years old now, the project? Yeah, we started in like July, end of July, like August, 2013. Okay. So two and a half years. So that's about two years after Go was actually written, maybe three years after it went public?

Yeah, I want to say we started with like Go 1.2 or so. Okay. And the reason why I'm asking that is I'm just kind of getting a heartbeat on like your happiness level with Go. Quite happy. Yeah, I have no meaningful complaints. Go is really great because it allows our new contributors to get up and running really quickly. It's not a hard language to pick up and you can come to it from any other language. So whether you used to program in, you know, you're a C kernel hacker or you wrote

Rails apps, you can contribute to Flynn using the Go language really easily. Has there been any other attraction for you to other languages like Rust or Crystal or anything else you can think of that might have drawn your attention? Not that Go isn't good enough, but has there been any other attraction to other languages that make you think, man, if Flynn would have been written in that, it might be better? I keep trying to find an excuse to do something in Rust. And I have like I've been reading some Rust projects recently. I haven't actually written any. That is the only language that I think has a future currently in Flint. I'm always excited to see new languages that people are targeting at production, because

there's kind of a few different classes of programming languages that people develop, and only a few of them seem to be like really like laser focused on use in production and I think that that is something that the Go community has gotten sorted out. If you have the ear of the Go community which I'm sure you do on your own anyways not just with our help but any sort of congratulations anything in particular you want to say back to the Go community that you're excited about with Go? I think that just in general, the quality of the community is great. There's a really strong focus on just on writing code and doing stuff with code as opposed to like kind of rehashing the language, which I think is some people get upset about, you know, oh, the Go people aren't super interested in changing language.

But from the perspective of someone who's like using this all day, every day, it's a solid language. It has, you know, everyone, I think there are like reasonable complaints about some of it, but it's overall really, really, really easy to get started with. And the quality of the tooling is pretty great. Uh, I think the last thing that, uh, that is problematic and go is the whole like vendoring and package management situation, but they are finally sorting that out. So in the next few releases, we should have that like totally fixed. Did you happen to make it to go for con

this past year? I did not. Unfortunately, do you have, did you make it to GopherCon this past year? I did not unfortunately. Did you make it to any GopherCon? No, I've never been to GopherCon. I've mostly been holed up working on Flynn. Too busy, right? Yeah, I haven't really been out to any conferences. The first conference I'm going to this year is at the end of the year

32C3. I'd be really interested to, because we plan to be a part of Go4Con next year, I'd be really interested to see a talk submitted from you on just a lot of the stuff you've done. Because, I mean, it seems like you're solving really interesting high-level problems that you can share a lot back to the Go community. And when we were there, it was really, really interesting. And a lot of the things you're saying about the Go community, we saw that firsthand. So you have that perspective without going to the Go conference.

Yeah, absolutely. I'm definitely going to consider what conferences to submit talks to this upcoming year. Cool. Well, all right, let's tail up the show then. So github.com slash Flynn is the org on Flynn. You got Flynn.io. So that's F L Y N N. So two N's dot IO. And I never even mentioned this, but your tagline on the homepage is just stunning. Throw away the duct tape, say hello to Flynn. I mean, just in retrospective of our conversation

here, it's fitting, very fitting. Thanks. And then you're also available on twitter at titanius that's t-i-t-a-n-o-u-s twitter.com of course so jonathan thanks so much for taking the time to come back on and just catch us up with what you're doing i'm super encouraged by what's going on is there anything else you want to cover before we close out uh no thanks for having me oh you're welcome it's uh it's a pleasure to have you back on the show. In that case, let's go ahead and say goodbye then. Bye, everyone. Bye.

Bye. Bye. Bye. We'll see you next time.