The Changelog: Software Development, Open Source - Flynn, Tent, Open Source PaaS's (Interview)

Episode Date: August 13, 2013

Adam Stacoviak and Andrew Thorp talk with Jeff Lindsay and Jonathan Rudenberg about Flynn, open source, PaaS and more.

Welcome back everybody This is The Change Log We're a member supported blog and podcast That covers what's fresh and what's new in open source You can check out the blog at thechangelog.com And our past shows at 5by5.tv Slash changelog This show is hosted by myself, Adam Stachowiak

And also Andrew Thorpe. Andrew, say hello. Hey, how's it going? Fabuloso. I just wanted to say that on air. That's so awesome. You can tune in live to this show every Tuesday at 5 p.m. Central Standard Time right here on 5x5. And today, we're joined by two awesome fellas.

This is episode number 99. Whoa. And we're, yeah, awesome fellows. This is episode number 99. Whoa. Yeah, 99, right? Yeah. And we're joined by Jeff Lindsay and Jonathan Rittenberg. Jeff has worked on projects like Local Tunnel, Request Bin, and Get Creative. Or sorry, Get Received, not Get Creative, but I'm sure that's creative.

Jonathan's one of the two designers behind Tent Protocol, and together they are building Flynn, which is an open-sourced platform as a service, which is powered by Docker. So if you've listened to, what was that episode number, Andrew? I think it was 94, but that could be wrong. Could be wrong. Could be wrong. Don't hold us to that. But nonetheless, welcome to the show, guys.

Thanks. Great to be here. Yeah, I'm a big fan. That was the most dramatic, crazy intro ever on the changelog. It was a long-winded intro. I don't like them. I'm never doing it again. So, Jeff, Jonathan, you guys have kind of teamed up on this new project.

It's kind of unique the way you've done it. We, the changelog, gave a little bit of money to it. We didn't quite give as much as some of the suggestions, but we did give a little bit. But I think it's pretty neat. So we want to have you guys on the show talk about what an open source platform as a service means. And I guess maybe key off of some of the conversations we had around Docker too. It might make sense if you guys just kind of wanted to give us a kind of an intro to who each of you are and your background, and then we can talk about some of the other projects you worked on and jump into Flynn. Sure. I'll let Jeff go first.

Oh, I am sort of a rogue engineer consultant now. I've worked at Twilio for a little while, but that was sort of my only full-time job. Most of the time I'm doing open source stuff. I popularized webhooks back in the day. And I've done a startup. I've done all kinds of stuff, mostly writing lots of open source software that nobody knows about. You're Progrium on Twitter. Yeah. all kinds of stuff mostly writing lots of open source software that nobody knows about your program on twitter yeah if people don't know the name jeff lindsey probably more familiar with program so on github you have a lot of uh open source kind of behind your name so we'll definitely want to jump into that but jonathan why don't you give us a little intro? Yeah. So I've been a developer for a while.

I started at Shopify in my professional career. Before that, I did a little bit of Rails consulting here and there. And then I kind of moved to doing this thing called Tent, which is actually a protocol, not a piece of software. There's reference software that implements it. And I'm largely interested in all things related to servers and more on the server-side stuff. So I've built lots of random open-source software on GitHub. A while back I did this thing called Mailman, which is a Ruby gem that essentially handles incoming email.

So doing Ruby and Go lately. Oh, you wrote that? Yeah. Nice. Why don't you give us a little bit of an intro to Tent? I think this is neat. Not something we talk about a lot on the show, protocols and things like that, but why don't you kind of give us an intro to what Tent is and where it came from? Sure.

So Tent is a protocol for personal data storage and decentralized communication. So it presents just as like a JSON protocol on top of HTTP, just kind of using RESTful verbs, et cetera. And essentially what you do is you pass around posts. So you have a server that represents you as a user, and then you have applications that talk to that server, similar to how you'd authenticate an app with Twitter. You just use OAuth.

And then your applications can create these JSON posts on the server, and your server sends those posts to other people's servers, or perhaps they're private and it just stores them on the server. And then you can create anything with Tent from Twitter to Facebook. You can even do Dropbox because you can store binary attachments along with the posts. So it's essentially just evented data in a server, very simple, like, RESTful access to it. And it ends up being really flexible. We created it as sort of an alternative to all of the centralized platforms that exist these days.

Think Google, Twitter, Facebook, et cetera. Have you seen any big projects kind of adopt this protocol? So it's still very new. We're coming up on version 0.3 of the protocol, and we haven't been really doing an adoption push yet because we're still developing the protocol and sorting out what should be in the 1.0. So we have a microblogging app that we host

and we do tent hosting. I've kind of started a startup on the side myself and a few others who work on the protocol. And so we're doing that as tent hosting and others have built, uh, some like mobile apps and desktop apps that mostly just do microblogging at this point, but there's cool new stuff coming. What goes into like, uh, I don't know when you're, you know, if you're working on a piece of software and you sit down and you think you have feature requests

or features and bugs and, you know, different pieces that you have to plan out and build? What goes into, like, a, I don't know, planning session when creating a protocol? It's a lot of, like, brainstorming on a whiteboard, essentially, just kind of, like, talking through use cases and sorting out. trying to do like use case driven development where we don't actually add a feature to the protocol unless we actually have an application that either like has a need for it or we are like about to make an application that needs it because otherwise you end up with like weird things that you think you're going to need but that you don't actually need and so it's just it requires a lot more thought than your typical software project because you can, like, slash out features really easily. But with a protocol, it's really hard to take features out. 0.3 was actually a completely breaking release.

We were changing just about everything about the protocol from what we learned with the past, I don't know, eight months or so of the protocol being in kind of production with a bunch of nodes on the network kind of talking to each other. The thing that I liked about the project when I first heard about it was how kind of it took the evented web ideas and like webhooks as like a core concept in it. Because other than things like PubSubHubbub, I hadn't really seen those kinds of HTTP callbacks used in more of a standard. Yeah, it's entirely push-driven. So when you create a post, for instance, like a status post, which is our equivalent to a Twitter post, your server will then push that post out via webhooks

to all of your subscribers that are permitted to see the post. So it's kind of like near real time. You wouldn't want to do IM over it necessarily, but within a few seconds, all of your followers have gotten the posts. Yeah, so it's interesting. You can see where you two kind of got together, and you both have a, as you said, Jeff, you both have kind of a passion for the evented web. So you kind of, you wrote the, or you, I don't know what the best way to put it is, but you basically popularized the webhook pattern, and it's been kind of adopted by Google, GitHub, everybody. What kind of sparked you to create that?

When did you write about that, and where did that come from um i was doing a startup at the time called devja vu and it was basically a hosted track in svn but as a product so it wasn't like here's some free hosting or here's like shared hosting with like track and svn tacked on it was was like as a product. And during that time, I was trying to figure out how to expose SVN hooks via HTTP. And it just made sense to do hooks as HTTP. And you put in a URL, and then when the hook triggers, it would call that URL. And then just all of a sudden, I realized, wow,

I guess there was one reference before that that was kind of popular, which was the PayPal IPN. So that was the real only good example I had to go from because nobody else was really doing it. And I was like, well, you can do all kinds of stuff with this. You can do all kinds of real-time. It wasn't just that you get real-time and that you get push. It was that any web developer can handle it.

If you can write a PHP script, you could handle a webhook. And so I started kind of raving about it to everybody, and nobody really got it. And I just kept doing it. And eventually, people started getting it and started using them and saying, oh, this is actually really cool. And then I made a bunch of adapters. I think one of the first things that I wrote was called mailhooks or mailhook.org. I think it's still online, but it doesn't work. But the idea was, again, kind of like Mailman, it would do SM uh smtp to http so incoming you'd get you'd go to the site get an email address

associate with the url and then we when email comes in it would do all the parsing for you and post it to your url like it was a form post which is makes handling incoming email email super trivial um no matter what language you're using, you just have to be a web developer and know how to handle a post. Yeah, it's hard to imagine the like modern software development world without webhooks when I mean, all of the services that you know, your typical developer uses are all integrated through these webhooks. And I mean, it's, it's pretty cool that you kind of pioneered that that road. And you can kind of see then is is that you know the idea of that intent is that how you two kind of got together and and started talking about flynn or did you guys meet each other some

other way uh we met through a mutual friend who's actually uh one of the co-designers of the tent protocol and um we share a lot of similar interests we've been talking about past stuff for i don't know quite a while now. Kind of like, we want to do something that looks like Flynn. And just recently, we decided to actually go in and do it. Yeah, Daniel. And I think I met him either at a Super Happy Dev House. I think it was a Dev House event, which don't really happen anymore, but it used to be big back in the day. Yeah. So, Jeff, real quick, we don't have a ton of time to talk about each individual project and then also talk about Flynn.

But why don't you give us a little kind of, I don't know, maybe an intro and just a little bit about a few of these projects, local tunnel being the first. So a lot of my work revolves around making developer tools, which is an interesting kind of place to be in, especially when you kind of have this sort of desire to create consumer like products, you know, and where you consider ease of use and simplicity and all this stuff. And most developers just want to solve a problem.

Because when I came out with Local Tunnel, there was really nothing like it. Now there's a whole bunch of stuff. But the idea was, well, you know, I do this a lot using SSH tunnels. Wouldn't it be great if I could just say local tunnel 8000 and expose that port to the internet i did a bunch of prototypes and finally got a version that worked and it it just kind of slowly started taking off and now there's all people building businesses around similar ideas and stuff like that but uh it was just about taking that a lot of what i do is about usually making a more complicated uh thing simpler and more accessible to people it's kind of seems

to be like a common pattern like docker i was involved in docker for a little bit in the really early before it was open source and you know in way, it's sort of about making containers more accessible and more useful to people. Yeah, one of our coworkers actually, Adam and mine, day job at Pure Charity is working on something similar to Local Tunnel called Portly. And it's, you know, same idea of being able to publish your local, you know, what you're working on locally.

So to me, the big probably thing that sticks out about Local Tunnel, and one of the reasons why I never actually covered it on the changelog, we talked about we went back and forth a lot, is from version one to version two, you went from Ruby to Python. Yeah. Would you kind of explain? Well, yeah. The server was always in Python.

The server was written in. It sort of bootstrapped off of SSHD and then had a twisted kind of server-side component. But the client was Ruby. But the client was really just like an SSH client. Like all it did was wrap an SSH library. And I'm not too much of a, I really like building tools that are kind of community agnostic. So HTTP is something that every community knows how to work with.

And so it was kind of a weird thing to have the client in Ruby and the server in Python. To me, it didn't matter. But now I've kind of seen that it makes a big difference, you know, when you start a project, what language you use, and what effect that has on what kind of responses it gets, and what kind of people are willing to contribute to it. So the, yeah, I started version two that was written entirely in Python, just because I sort of use Python more. And I had to write more code because I wasn't, I didn't want to depend on SSHD anymore because it was kind of this big complicated black box and people would create tunnels and sometimes it would, the SSHD processes would hang and I have no idea what's going on. So I wanted to create a simple protocol. And so writing more code,

I wrote it in Python. And that's kind of been in this weird kind of active development uh stage for a while and a couple of people are running it um it's not actually running right now uh but a couple of people run their own instances like run scope um they actually recently took one of my projects uh request bin and are sort of taking it to the next level while keeping it open source so it it's, I'm glad it has like a new home. But what's, what's happened actually is a friend of mine has written, you know, I eventually wanted to rewrite a local tunnel and go. So I told a friend of mine that I wanted to do that.

And so he went off and kind of wrote a go version of it while we were both working at Twilio and he kept hacking on it. And eventually he released it as ngrok. And so it's basically the exact same kind of architecture and model as the new local tunnel, except it's actually a lot better. So very recently, we actually, when people complain about like local tunnels not running, or it's not working for me, I say, well, go check out ngrok. Because it's what local tunnel should be. And we actually just recently have decided we're actually creating, like, there's actually a v3 branch in local tunnel now that is basically just going to be ngrok. We are more or less merging projects. Gotcha. So now it'll be written

in Go. So you're a language, you're a dynamic language adapter? Yeah, I usually stick with one thing, but I'm pretty flexible. Gotcha. You talked about Requestbin a little bit. That's another project you worked on. What is Requestbin? So thinking about webhooks and this ideal of the evented web led to a lot of stuff like local tunnel you know because that was the idea is if i write a web hook script it has to be accessible on the internet so if i want to develop it locally i need to expose it to the internet so that led to local tunnel another thing was is if i use a site that has um you know takes urls for um for web hook requests i want to um it's actually pretty easy to know, they don't really need to document their payload if I can just see some examples. So the idea was if I create a site where I can just get a URL to use and give them that URL and they post to it, and then I can go to a similar URL to see what they posted in sort of a nicely formatted way, that would become a very useful debugging tool for webhooks.

It turned out to be a more generally useful tool, just like Local Tunnel, to just inspect HTTP requests. Like if you want to try a client and see what kind of headers it sends by default, you can just point it to a request bin. And I think there's been some similar clones of that too. But I'm excited about what Run what run scope's gonna do with it because they've given a new design and all this great stuff so yeah it's cool so it seems like you kind of i don't you may have alluded to this a little

bit before but it seems like you kind of write uh the first version of software and then someone else takes it and runs with it as the full-time thing when you move on to the next thing. Yeah. I mean, you, you kind of have to, it's even worse though with services because, um, when you're writing open source software, uh, like a library or an application, you can kind of, you know, write it and get to maybe a stable point and maybe you've developed a community and you can kind of, you know, let somebody else become a maintainer and move on. But when you run something as a service, like a free local tunnel server or request bin or these things, it starts to get very difficult because somebody has to run operations on it and pay for it. And actually, this is actually the very start of the kernel of the idea for how I sort of started thinking about what Flynn is, finally, was back in 2008 when I was thinking about webhooks and building these kind of lightweight adapter services like mailhooks.

And I made a bunch of other ones, one called clickhooks, and I think this still works because it's running on App Engine. Clickhooks.org, it's like a URL shortener where you put in a url to redirect to and then you get another url but when you click that url it also triggers a webhook so for a while i was using that to i wrapped my uh subscribe to my blog link in that and then had it post to a service that i previously used to run called notify io that would give me a growl notification when anybody clicked that link um so i um the idea though was I want to run a lot of these services, but unlike a regular open source project, I can't just hand it off.

There's money involved and all this stuff. And so the idea was things like App Engine just blew me away because I was like, okay, it's a lot easier. Operations is now a lot simpler. The cost model is a lot simpler um you know and more efficient effective cost effective and uh so i was in love with app engine and then i was in love with heroku and so that led to this this love of platform services and then when i was at twilio we kind of realized the thing was i was always better butting heads against like what they would let

you do for example i say heroku would be 10 times more useful if they just didn't have their HTTP router, because then you could run anything. You could run mail servers. You could do all kinds of stuff, because it's a very general platform at its core. And so that's a lot of these ideas. And actually, I was hired by some friends at NASA when they were working on what became OpenStack to basically build the original vision for OpenStack was actually not just like an EC2 clone and S3 clone,

these things. It would actually have a platform as a service layer. But it turned out that it was really difficult to do that first lower level layer. And so I never actually got to building it, but I spent a lot of time thinking about it while I was there. So I've just been thinking about this platform stuff for years um for a lot of different reasons and uh so i you know when i got to the end of my time at twilio i

kind of had some good ideas like i had basically sketched out the idea of docker and i just happened to run into solomon he's like oh you you know, we're doing the same thing. So we collaborated on that. And that was just like a means to building something like Flynn. Yeah, Flynn is a pretty neat thing. I mean, coming from the love of Heroku and obviously App Engine and that, I mean, getting that experience with a platform. And then I guess just serendipitously being involved with Solomon

in the early days of Docker. When did Flynn come around then, I guess? When did you guys actually start collaborating on it and thinking things through and starting to, I guess, even flesh out the idea of raising money to make this kind of community-supported but still open source? So we started talking about it, I guess, last year sometime, but it was like, this is something we need to do soon.

It was, we didn't really have time to do it at the time. And just recently I was talking to my former employer Shopify and I was like, Hey, I really want to do this thing. Do you want to sponsor it? And Toby, CEO of Shopify was actually, hey, I really want to do this thing. Do you want to sponsor it? And Toby, CEO of Shopify, was actually, yeah, totally. We'd love to sponsor it. And then we were talking about it more and we thought that there might be some other companies

that would be interested in sponsoring it. We didn't think there'd be that many that would just up and give us cash right out without knowing us. But we put up a site with a Stripe button, and it turned out to get way, way more money than we were expecting without doing much sales, I guess. I know right now you're sitting at 108% funded, so that's $80,713 of the $75,000 you guys intended to raise.

What was, I guess, the impetus around determining how much money to raise? It's kind of a lowball estimate of what it would cost for us to spend six months building Flynn, myself mostly full-time, and Jeff close-ditch to full-time. Yeah, part-time. So you mentioned Shopify. You got quite a few other, and we can name them all if you want to, but just some logos that look nice that stand out to me, like Lab Division, Nebula, LocalWeb.

Are these friends of yours, or do they just kind of come out of the woodwork and like, hey, yeah, we'll support Flynn? A few are friends. Most of them just found it through the Hacker News article and Twitter and just out of the blue decided to support Flynn, I guess, after reading the docs and, you know, shooting a few emails, talking in IRC, et cetera. Yeah. Yeah. One of the things we talk about on the show a lot is sustainability. So I noticed that you, um, you kind of have, you know, $75,000 is, was the goal and, uh, the, when will it be ready? Frequently

asked question kind of says it's like six months. So after six months, in terms of funding or next steps, what's the goal for Flynn at that point? So in six months, we hope to have something that's runnable as an internal service at companies for for perhaps running their internal services like um most of the companies i've interacted with um of any size have a bunch of tiny little internal apps um from things like dashboards to like employee directories and the whole gamut of other stuff um so it should be able to run those types of services basically like your heroku like 12 factor apps and then after that well it's just one step at a time do you think do you foresee yourself working on this full time or or would you you know go to another project type of a thing um so my time is split between this intent and that's all i've been working on and will be working on for the

foreseeable future. Gotcha. It's cool. The second frequently asked question is, is it open source? And your answer is 100%. It's really cool to see how passionate you are to, like, you know, ensure that this is going to, like, be and remain open source. What's the driving reason for that for you? The thing is that from what I've seen, there's a lot of companies that either need this or are building a version of this right now. And for it not to be open source, for it just to be like one company's internal tool really sucks for the rest of us because then we have to build it. So I think that if a few people step up to build something that everyone needs, then that just saves everyone a lot of time.

You mentioned that you guys, I guess, had early relationships with Solomon and Docker. And since we're talking about FAQs, it says, how is it related to Docker? And you say that you've been working with the.cloud team on Docker since before its public launch to make sure it was suitable for this project. So it sounds like maybe early days of Docker, you knew about Flynn. Yeah. So when I was – and Docker has become so much more than I could have ever hoped, and it's really part of Solomon's vision,

and it just so happens that our visions align so much for that tool. But I, you know, really what I wanted when I was at Twilio, and I was trying to think, well, we're trying, so my second year at Twilio became focused on what we call the platform team, which we wanted our ideal product of that team to basically be an internal platform that the rest of the developers could use to build all these services. Twilio is actually a very highly service-oriented architecture with 200 different types of services. And so trying to make that experience for developers and operations both consistent and an enjoyable experience.

We wanted something like Heroku. We couldn't use Heroku because we're doing more than HTTP, and we want to have control over how the scheduler works because of various whatever our SLA policies are and stuff like that. So it really became clear we needed to build our own. And since then, I've heard lots of companies, like Jonathan was saying, that want to do the same thing. And so at the end of my time there, I was like, well, really the first component is probably like a dyno manager, like something the equivalent of

the Heroku dyno, which is more or less a high level container made for, mostly made for services. But really, once you have that primitive, you can do a lot of different stuff with it and so i kind of sketched that out with the idea that it is part of this bigger puzzle of this platform really a framework or like i really like building tools that are sort of really kind of independently useful components, sort of that Unix philosophy of doing one thing that works well, that does one thing well and works with other components. And so that was kind of a differentiating concept that we had going into Flynn is making a system that, you know, is components, but isn't just a monolithic set of components, but is actually basically a set of independently useful components. So for example, if we get receive, which is sort of an early version of, you know, the type of thing that we would have for like a Git front end for Flynn, that's independently

useful because you can use it to wrap, you know, any other kind of Git based workflow type of thing. You can push a repository to it and it'll run a shell script. And so you can use that to do all kinds of stuff. You can use it to put Git in front of App Engine and be able to deploy to App Engine via Git. So Docker was one of these many components. It was just one of the most important ones.

And so I did go into working with Solomon to make sure that it met these requirements. And I, you know, continue to push still to make sure that Docker meets the requirements for these sort of things for a system like Flynn. And I hope that that can be replicated for all the components. So we can find, you know, if we're building it for Flynn, we can get somebody else to use the component for something completely different to ensure that it is, you know, general enough and simple enough, you know, but simple enough to satisfy both uses. So let's kind of fill in the blanks real quick. Why don't you give us, like, the pitch for Flynn, you know, the what Flynn is in a sentence for somebody that's never heard of it. Jonathan?

Sure. So Flynn is a set of building blocks that, when put together in their default configuration, presents a lot like Heroku. So you're just doing, like, Git pushing apps, and then a build pack deploys it. But at a lower level, it's managing just containers with Unix services in them across a cluster.

And then each of the building blocks that are used to build Flynn can be replaced or reused. So it's a modular system. It's extensible. And it doesn't require you to use it in its default configuration. So Flynn out of the box, you could think of like a Flynn distribution, is all these components made together, made to come out of the box, work like your own private Heroku. But for example, like I said, Heroku, you get an HTTP router, and maybe that HTTP router supports things like WebSockets, or maybe it doesn't, ours will.

But you might want to remove the router completely because you're going to be doing other stuff, or you might want to replace the router with your own router. And so we really want to make sure that this is very, you know, again, that component philosophy is you can recombine these things or replace things. And a lot of these components are running in sort of a core FLIN, you know, lower-level platform. So a lot of these components run in FLIN itself. And so you can replace them and deploy them in the same way you would your apps that you run on it.

Gotcha. Do you have, like, a high-level, you know, from 20,000 feet, like where do you make the separation of the modules and, and, you know, the, like your default set, uh, you, like you said, the router is interchangeable. You can put a different router in there or you can take it out or whatever. Do you kind of have the plan for like where, what pieces are interchangeable and where you make that distinction at? We have a sort of this high level architecture of the problems that we need to solve things like the router the scheduler um and you know the get front end and the management api and all these

things but um when you get into actually solving those problems you end up realizing oh well this can be solved with a simpler component or um or you know a set of these components and so really as you go into those problems, try and break them down into smaller, simpler components and problems that you're trying to solve. And so it's kind of an iterative discovery process. And so there's both high-level and low-level kind of concepts of how this breaks down into components.

You know, one of our... I mentioned earlier in the show that we supported Flynn, and we kind of immediately blogged about it and featured it on the changelog, and one of the followers of the changelog, Mark Jelen, who is also a platform as a service advocate, kind of tweeted back to us and said that, I guess just the way we worded our tweet, like, support Flynn to help make it pass open source. And he replied, there are at least two perfectly good open source platform as a service projects. Why do you act as if there's none? And then also on your FAQs, there's a mention of Cloud Foundry, OpenShift,

and a couple others that are mentioned. Can you just kind of contrast what the differences are, I guess, between what Flynn aims to do and what others have tried to do or are doing? So from the beginning, like, for example, App Engine, it came out and it was super useful, but it's very constrained to this paradigm of web apps. And Heroku and.cloud actually, because they kind of in parallel sort of follow the same development path in a lot of ways,

generalize that. So it's really about just running a Unix process as a service. But they're still based on deploying web apps in all their conventions and the HTTP router and all this. And even though they've made progress, App Engine is still very much focused on web apps, and they've kind of hacked a bunch of extra features to make it a little bit more, but it's still like the way it was designed originally is still focused on web apps. And I think a lot of the open source projects that are trying to solve this

platform service problem are sort of similar. You know, they're still geared a little bit too much towards web applications to be useful for me. Another one, because I've done Cloud Foundry consulting, and, you know, there's just, you know, they, I don't want to speak, you know, for all of them, but, you know, many of them are, they try and break them down into components, but they're still this sort of monolithic beast that's very complicated, and, you know, each of the components isn't very well documented,

and it becomes very difficult to deploy the thing. And so that kind of user experience is something that we want to try and make much better. So the out-of-the-box experience is much better, but you still have that hackability. You can drill down and actually pretty easily kind of see how everything works together and start hacking it and taking it apart and doing whatever you want with it. And so to me, actually, it's not so much about building a platform service. It's about building tools for building your own platform or your own

district. Really, it's a toolkit for building distributed systems. It sounds like the key words that you're saying is like a set of like, and you just to use your words and your FAQ best, you say a set of modular components. It seems like you're really, like you'd mentioned, you're more focused on the individualized components and how that makes up what actually is a platform as a service, much like Heroku without the, you know, some of the pieces that have kind of upset you or didn't kind of put some

blockers in front of you with using Heroku like you wanted to before. Yeah. So it's really taking a lot of the technology that was developed in building platform services and making them more accessible, but then, you know, decoupling them so that you can use them for different things. Like container technology was really, I think, developed by platform services, companies like Roku and dot cloud. But it turns out when you break that out into a component like Docker, it's immediately useful for all kinds of other stuff that has nothing to do with running a platform service. And so there's all this great stuff in there that's useful for building your systems that we want people to kind of, you know,

take advantage of. So right now, just the spec is on GitHub. And I know you're past the 100% mark in terms of meeting your minimum funding goal. But, you know, we talked earlier, too, about six months, a certain time frame and whatnot. But when should the community begin to see a repo pop up and commits happen and I guess start seeing progress

towards what Flynn's going to be? Within the next few weeks, for sure. We're currently just kind of talking through some high-level stuff, just getting our bearings, and then we're going to start diving into components really soon. Talking about the Flynn spec, is that written in sand or written in stone? Oh, sand.

That's actually just like a bunch of bullet points we put together, like even before we put the Flynn.io site together. It's pretty old at this point. So when people kind of started to support this project financially, what do you think it was well first of all this we've talked about like we said sustainability and we've had people talk about different you know uh funding models or revenue models for open source projects whether it's you you know we've talked about we had get up on the show at one point or we've had you know people like sidekick like mike perrin with sidekick where he he releases it open source but then builds some professional features on top of it and charges for a monthly rate. What did drive you to kind of go with the pay-ahead, almost the Kickstarter-esque without the minimum goal model for Flynn?

So funding open source is a really hard problem. Most projects are small and some ask for donations, but most don't see more than $20, maybe a year or something. So we looked to the Kickstarter model. There's been a few open source projects that were funded quite successfully, and we decided that there are actually companies that were interested in funding rather than individuals. We've had lots of individuals sponsor Flynn, but the vast majority of the money came from

corporate sponsorships, companies that want to use Flynn. So that's what we targeted, essentially. Yeah, I think the lowest tier was actually $1,500. So it's very clearly targeted towards companies wanting to sponsor. And that sort of makes sure that we're solving a problem for businesses. All our sponsors are sort of going to be able to participate in conversations about, and I've actually been going out to a lot of companies and just talking to them in person to learn about their requirements and stuff like that so we can kind of continue to refine the design of this thing and make sure that we're building something that's simple

but is able to satisfy all these requirements. So since we're, I guess, on the subject of sustaining, I guess, in some capacity, you've got the funding you guys requested. I guess what's the plan in the future for, I guess, sustaining this past this point? Like is it go back to these original sponsored companies or back to the community and say – I guess what's the plan to, I guess, sustain? I mean, so we could raise more sponsorship. We actually have talked to a lot of companies

much more actually much more in depth about the technology than some of the people that have sponsored so far that are very willing to sponsor and were about to, but we were sort of like, well, we reached our goal. We'll come back to you later. And they were very willing to sponsor them and were about to, but we were sort of like, well, you know, we reached our goal. We'll come back to you later.

But they're, and they were very willing to, you know, let us know, you know, they're just very excited about the project and the approach and all this stuff to be able to help us out because they're seeing all of these problems. And I'm just, I'm super surprised just how many companies internally are sort of realizing that what they want is sort of an internal platform service. And again, that's sort of one of the things that differentiates us is a lot of these open source platform services, passes, are made to be run as a, service. Not, you know, they've got billing and quotas and, you know, all this stuff kind of built in so that it's made for someone to kind of deploy and resell or something like that. And we expect that at some point people might add that to Flynn, but really we want to, you know, a lot of internal use cases don't need any of that. So we're just kind of avoiding all

that for Flynn. And so it's kind of a different use case. Yeah, our target customers are the operations teams at the medium startup, medium to small size startups that are kind of struggling with just the amount of work that it takes to deploy each new application. So it's almost like the project has a different customer than the existing projects in the same space. Can you pause there for a second? Because there's one quote, I guess, under the praise for Flynn that I think needs to mention. And I guess it kind of maybe expands a little bit more on this, which is from Tobias at Shopify. He said, the future of operations is to function like a product team that services the developers of the company as a client. So when you kind of flip that on its head, it's like you're targeting towards,

I guess, the Shopify's and people like that that are wanting to support you guys, but it's in an effort to help their development teams and their operations teams better interface between DevOps and developers. Yeah, I think, and at Twilio that was the idea, was we wanted the platform team to basically build a self-serve platform in much the same way that so many startups use EC2, where you just have this great layer of abstraction. And they take care of like people kind of, you know, are, you know, arguing about the value of the cloud and stuff like that. But the stuff that they do and abstract away for you is incredibly amazing. And so the thing is, though, is that there's no kind of layer of abstraction between EC2 and a Heroku. And so we kind of want to open up that spectrum of, of, you know, abstractions and capabilities for operators and to the benefit of both operators

and developers, because Heroku is a great developer experience, right? It's kind of talking about Heroku. You have another project called docu that you worked on um yeah or doku i want to say docu because of docker but yeah it's kk uh so i noticed i think flynn kind of came about what would you say like a month ago maybe is that right yeah and then the initial commit on doku was two months ago so what was the kind that was this – was Flynn already in mind when Doku was started, or kind of how does that relationship work out? Well, like I said, I've been thinking about this for a ridiculously long time, and since even before Docker existed. And I actually gave a talk with Solomon at, I think, GluCon, and I wanted to give an example of how you could use Docker to build a platform service.

And by then, Docker had been developed enough that it did actually do most of the work to actually make a pretty simple kind of Heroku-like service. So in six hours, I spent the day before the talk actually building the first version of Doku. And the idea was that it was super simple right because docker does most of the heavy lifting and trying to just like uh do the simplest thing possible that works with the constraint that it's you know it only works on a single host you know it's not a distributed system um but it turns out that that

actually is pretty useful a lot of people want like their own little mini heroku and uh so doku started um i released doku a little while after that because i had added virtual hosts because that makes it a little bit more closer to like heroku where you have a subdomain for your app and um and i just started working on that on the side for fun and it got a lot a lot of attention and uh that sort of uh it was happening separately slash in parallel to uh talking with these guys about working on flynn and uh so a lot of the same philosophies and actually a lot of the components that we would be using for flynn will be pulled into Doku. And Doku kind of gives us an idea of some of the components that we need for Flynn.

For example, Doku uses GetReceive to handle pushing via Git. And so we know that GetReceive is not ideal for building a distributed scalable system, but it solves the problem well in Doku for a single host. However, if we take that same component and re-implement it in Go and make it a little bit more general and fitting for a distributed environment, it's more or less the same component, but works for Flynn, and then we can run it on a single host and it works for Doku. So Doku, for me, is going to continue to be a single host and it works for doku so doku for me is just is going to continue to be a single host more or less like a single host distribution of flynn um and so for me it's kind of a prototyping

ground for ideas for flynn um but yeah it's kind of different different goals single host gotcha so this is going to be uh kind of i don't know, maybe like supercharged version of Doku or the Doku++? Yeah, actually, in the readme for Doku, when I was explaining what it's not, it's not multi-host, it's not made for a multi-tenancy sort of thing it's it's uh i said maybe those are features for super doku and then um it just so happened that uh flynn is more or less what super doku would have been there's actually some other great projects um built around docker and it's on hacker news today somebody told me um ds which i actually saw quite a bit before because they're sort of in the docker community um they're released and so they're another platform service um built on docker um and already we're sharing components like i wrote for for build step for uh for doku and we'll use it for flynn is this piece called

build step which is maybe more accurately something like heroku Stack, because it's basically a builder and runner for Heroku build packs in Docker. And so they're using that for their platform service, and I'm using it for Dooku, and we'll be using it for Flint. Can I ask maybe not so much a, I guess, I'm not really sure how this question will be sounded, I guess, but you say things like in the areas of, I guess, for Dooku, ideas for improvements where you say Heroku-ish commands. I mean, I know Heroku is a for-profit company, and they're doing some awesome stuff in open source too.

But does any of this cross lines? Does anybody call you and be like, hey, stop doing what you're doing? We don't really want to support that because maybe Heroku wants to protect their market share. Well, I've been friends with a lot of the Heroku engineers for a while, and I use them. I'm sort of a power user, so I go to their offices fairly frequently when I do stuff. I made a web service that you actually put on App Engine that lets you register new Heroku accounts because I was working on a project that needed to let you create, like, infinite number of apps. So I needed to be able to create, So it could kind of self-deploy. I'm doing just all these weird things with Heroku. And so very often they'll kind of like pull me in and want to talk about it or see what's going on. I've actually been, you know, a lot of the times there will be like

product development discussions, like, you know, you're trying to do this, so how does this sound? And we actually have these kind of useful conversations. But I've heard, though, that some people in Heroku who's pretty big are sort of like, are very kind of curious about some of the stuff that I'm doing, but the majority of them actually don't know. I think it's possible, potentially potentially i know this is just being hypothetical of course but um maybe that heroku will be like oh man i love what you guys are

doing with flynn will acquire you i know you're not really a company yet but like the thing to remember is that and support it is that flynn is um is targeted to run internally so heroku is kind of this this service that you pay for and runs on EC2 and you have no control over. Whereas we're targeting Flynn at companies that need to run something internally for whatever reason. There's a variety of reasons from security and control to, you know, just like latency reasons. Heroku's not in a data center that they want to be in etc so we're we're making flint for essentially the people that don't use heroku or can't use heroku for whatever reason they're adjacent they're not in direct competition i don't think it's actually the same story as open stack because open stack came from nasa and it basically our group of people uh like a

ragtag team we're trying trying to make NASA cool again. We're doing all these kind of neat web apps for missions to have more participatory kind of citizen science sides to them. And so we kept thinking, well, we want more people to do this in NASA, so it would be great if we had a platform for them to do this or even just use existing stuff like App Engine. The problem is it's government stuff, and the government requires you to use your own hardware. So that basically forced us, if we wanted to do this cool stuff, into building more or less our own EC2. That's sort of where Nova came from in OpenStack. I guess it's no different than saying GitHub Enterprise versus GitHub.

GitHub, they're not competing. They're different markets. I get it's no different than saying GitHub Enterprise versus GitHub. They're not competing. They're different markets. I get it now. Yeah. So when the Flynn.io launched, it said that the minimal viable product would be ready in two to three months. I'm not exactly sure of the timeline, but when can we expect an MVP for Flynn? This fall.

Cool. And then so once that comes out, are you going to give a lot of time for feedback or are you just plowing right through towards the production version? We definitely love feedback, and we get a lot of feedback already just kind of architecturally in the approach from the various companies that we talk to and are sponsoring. But we definitely have kind of a set all this kind of componentized philosophy, as well as a set of sort of like technical guidelines that we're going by. And once we publish those, then hopefully it'll make suggestions and stuff like that a lot more productive because we can easily say, well, we can't do that because we've decided philosophically that that's not for us. The cool thing is that if people don't like the main Flin distribution,

how we're organizing things, hopefully that a lot of the components can be used for them to sort of remix it into something that is more what they need. Gotcha. I think it's interesting, almost funny, that just the spec, which is like this one little readme, you said just bullet points, has like 520 stars and 9 forks. Yeah. I mean, do you get, I don't know, I don't see any, but do you get like, do people take this and say, I see this as one of the general features, but you should change it to that? Or why are they forking this?

There's people who have opened issues. I haven't seen any pull requests yet. That would be entertaining. Yeah, that's interesting. Cool. Well, it's definitely a product that we will be keeping our eyes on because this is something that, you know, we talk about a lot that we have like, well, you know, for instance, we have preprocessors, we have SAS, right,

which like boils down to, you know, a cool way to do CSS or a powerful way to do CSS. And at some point you think, you know, the levels of abstraction will seem to stop. But I don't know. Flynn just gives you another use case of a higher level abstraction to one step further than Docker. And I think that maybe this is where it stops at. But it's an exciting, interesting product that we will be watching for sure.

Me too. Well, hopefully you're watching it the uh so if you're so if you're new to the uh new to the changelog then we just want to let you know that we ask these three questions and seeing as we have uh two guys on the show with us this time we'll give a little extra time but we have three questions every week to our uh guests and so we'll go ahead the first question and i'll ask you jeff is um for a call to arms for flynn as obviously right now flynn is not in um you know uh it's not on github so it's not necessarily something that the community can actually contribute code to but what would you like to see people or your sponsors or anybody kind of do Flynn-related right now?

Well, so there is Doku, which is sort of a – in a sense, it's a very different project, but there's still a lot of the same philosophy behind it. So if you're interested in this sort of thing, definitely check out Doku and play with it. And definitely, I think, preparing people, because everybody should be able to take advantage of this, Flynn. And so it'd be great to have more people involved and contributing. And so one of our sort of technical guidelines is to, most of our components are written in Go for various reasons that we'll document. And Docker itself is written in Go. And so if you need an excuse to learn Go and you want to participate in this grand vision of Flynn,

definitely take advantage of it and start playing with Go. And some of the components that we already have out there are open source and you can start playing with them and learning Go. But Go is really awesome. So maybe that can be my call to arms. Yeah, talking about Go, we're actually going to have Andrew from Google on next week to talk about Go. So it should be a pretty fun show. What about you, Jonathan? I'd say pretty much the same as Jeff for Flynn. Also, Tent, if you take a look at the protocol docs and find it interesting, always love to see new applications being built, and we're always around in IRC to answer questions, et cetera.

So have a look at Tent and start thinking about what you can build when your communications platform is decentralized instead of centralized. And you have a nice platform like Flynn to build those on. Yeah. Kind of a new question that we've been asking, and I'll ask you first, Jonathan. If you weren't doing this, now this is pretty new, so this might be be meaningless to you but what would you be doing if you weren't doing what you're doing right now if i wasn't doing open source i would probably be a film editor i actually went to school for a few years um for filmmaking and tv broadcasting that

kind of thing so i like that stuff too what about you program i? I struggle with this idea that I have too many interests. One of them is film, so I'd love to start doing film. But I sort of prioritize based on how well it fits into my lifestyle. So outside of programming stuff, I do a lot of music stuff, and I'm trying to make more time producing music. I actually do metal and hard rock and stuff like that and um but otherwise i'm really into indie games um but i can't do indie games right now because it's just more programming and so i don't want to like spend my time not programming programming

gotcha yeah one of our uh one of our friends of the show that we have on the show a lot kenneth writes he's uh he is also into music. It seems like that's kind of a popular trend right now is for developers who kind of do some release on the side with music, which is kind of a neat little thing that's going on. Yeah, I told Kenneth we should start a band. That's awesome. I want to give you a chance to kind of give us a shout-out to someone personal or somebody that you look up to. So we call it the programming hero on the changelog.

So who is your programming hero, Jeff? I have a ton, but if I were to pick one to give a shout-out to right now, it would probably be Brett Victor. So I met him recently, and he's given a lot of amazing talks and is is doing a lot of really amazing work and um he's he definitely falls into the realm of the type of person that inspires me so shout out to brett victor gotcha and what about you jonathan um i have to pick one uh shout out to rob Pike, co-creator of the GoPro language. And he made UTF-8, which is also a really nifty encoding thing that everyone uses.

I'm a huge fan of his no-nonsense design aesthetic for the software that he makes. And his one-liners on mailing lists are hilarious. Yeah, that's a good choice. Funny story, Go is really, you know, like 20 years old because he wrote a language called New Squeak that is basically Go with kind of a more Fortran-looking syntax. You can look up a Google tech talk on him talking about concurrency. It's actually, he shows New Squeak,

and pretty much everything in it is the exact same thing in Go. Yeah, he's been contributing to the community for quite some time. I think he was one of the designers on Limbo. That's right, too? Yes, that's correct. He's a good guy. Yeah, cool guy. That's kind of a huge throwback to our early days, but Rob Pike was on the show on episode number

two, so we... Oh, yeah, I heard that. That was like the super early days, I guess, not really early days of Go, because you just mentioned what you mentioned, so not really early, but it was like around the same time of the release of Go as it is now. Yeah, he's a good example of a programmer that works with sort of great philosophy behind his work. Well, cool.

Yeah, I know we can certainly go on for quite a while talking about this. A lot of fun conversations and topics that we can certainly dive deep into, but we do have to wrap. We try to keep this show to around an hour, so sometimes we go over, sometimes we're a little under, but either way,

I do want to mention two things before we do go. So we're just launching an every Thursday newsletter from the changelog. So if you want to sign up, you can go to the changelog.com slash newsletter. Every Thursday in your inbox, you'll get the latest from the changelog. We're also ramping up our contributors as well. So expect more on the blog. We do have our T-shirt in. So you can hack and style with your very own changelog T-shirt.

You can go to the changelog.com slash store as well. So if you don't have that t-shirt, you are wrong. But Jeff, Jonathan, thank you so much for The Awesome Market doing an open source and taking the time to come talk about it on this show today. Let's say goodbye. Thank you. It was great being here. See you all later. See you. It was great being here. See you all later. See ya.