Evan Prodromou has been involved in open source since the mid '90s. His open source travel guide – Wikitravel – grew up alongside Wikipedia and the web itself. In this episode, we hear Evan's history, try to solve open social networking once and for all, and learn how sprinkling a little artificial intelligence on to our products can yield big wins without having to shoot the moon.
Linode – Our cloud server of choice. Get one of the fastest, most efficient SSD cloud servers for only $5/mo. Use the code
changelog2017 to get 4 months free!
Toptal – Easily scale your team — hire the top freelance software developers, designers, and finance experts with Toptal. Email
email@example.com for a personal introduction.
GoCD – GoCD is an on-premise open source continuous delivery server created by ThoughtWorks that lets you automate and streamline your build-test-release cycle for reliable, continuous delivery of your product.
Fastly – Our bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform.
Notes & Links
Our transcripts are open source on GitHub. Improvements are welcome. 💚
Alright, should we start?
Yeah, we should start. You mentioned open source since the '70s; I'd say let's --
Well, not since the '70s.
Um, sorry, he's 48, so... That's ten years your senior, so call it '90s, yeah.
That's my earliest time. That's a really good story, actually. Are you guys recording?
We are recording.
We can start right there. Yeah, tell us about that.
So I was working for a very big company based out of Redmond. I was working for a big customer in Silicon Valley, and working on it we had a number of tools that we were doing with them. We had one project that really was amenable to doing via a website. This was like 1995 or so, and I was like "Oh, this web thing looks pretty interesting. I'm kind of into what's going on" and I'm like "How do I do this?"
At the time, the only way that you built dynamic websites was with Perl. There was a port of Perl to our platform - Windows NT at the time - so I started building websites for this customer using the NT port of Perl, and it was really difficult. And I spent a lot of time documenting what I had learned, and responding to people on e-mail, responding to people on IRC, and these were all things that I had never done before, and I was getting more and more into it.
Then I published a big FAQ. It was basically a How To for using Perl on Windows NT. I'll never forget that experience of publishing -- you know, this is a relatively small open source participation, but publishing that and just having this flood of dozens of e-mails coming in saying "Thank you! This is exactly what open source is about. We're so glad you did this. This saved my life. This has been so important to me. Keep doing this!" and I was like "This is amazing!"
[laughs] It was pretty good.
[00:03:58.10] I'd only been doing software for about five years, and I'm like "No one has ever personally thanked me for something I did."
I was like, "I just want to keep getting this experience again and again and again, for as long as I can." I think for a lot of people who get involved in open source, that feeling of gratitude that comes from people who use your software gets kind of addictive. You're like "I'm making a difference for people with something that I didn't even know would matter to them."
What years was this? You said Windows NT, so this is like mid '90s?
It would be '95, or early 1996.
Yeah, it was a really good experience. Perl was actually shipping with Windows NT at that time, but it was totally undocumented, and it was really great for me to be doing that part of it. A great experience there, and I think that the other projects that I've launched and have had that great feedback - it is a high that once you had it, you just wanna keep getting it again and again.
Tell us about some of those... I know Wikitravel - it sounds like it was a big success. Tell us about that story.
[laughs] Yeah, Wikitravel started -- I actually started that website with my wife. We were traveling around the world, I had quit my job in the Bay Area, taking the money I had made and I was trying to figure out what I was gonna do next... So we were traveling around the world, we were doing all kinds of interesting travel, and we were using at the time what everybody used, which was great, big guidebooks; you know, those big 500-page guidebooks that would say "Name of Publisher, 2003." We used one to get to a hotel in Thailand on an island called Ko Samet, and we had to take the ferry from the mainland to this island, and then a jeep to get to this hotel... No internet for this hotel, no phone... This was a backpacker kind of place. Then the jeep drops you off and you have like another half mile walk to the hotel.
We get to where this hotel is supposed to be that was in our guidebook, and if there had ever been a hotel there, it had been gone for at least five years. There was just like a little bit of detritus on the ground... So as we were doing the five-mile walk back to the harbor town, we were asking each other "What are we gonna do about this?" I think the thing that really surprised us is that we had just had an experience where our guidebook was catastrophically wrong for us.
It wasn't that big a deal, we could recover from it, but the worst part being that there were gonna be hundreds of other people that would come make that same mistake, right? That listing was gonna remain in that guidebook. Unless we reported it, it just was gonna stay there forever until they came out with a new addition or they sent a [unintelligible 00:07:23.01] and we were like "This is something that makes no sense. Why do we have a system where we're using guides that get out of date really fast?"
One of the things I learned later was that most travel guides are updated on a 3-5 year editorial cycle; they don't actually get updated every year, even though it's got the name of the year up on the front. They don't send [unintelligible 00:07:47.27] more than once every three or five years.
[00:07:53.00] I had been looking at Wikipedia, I was really interested in it, and together with that experience, we realized that having a Wiki edited travel guide where anyone could update the travel entries would mean that nobody would have that same kind of problem that we had just had. If there were changes in prices, if hotels or restaurants opened or closed, that kind of stuff would get updated immediately.
So we started Wikitravel in 2003 and had that first kind of exciting point of launching the site, getting the first group of users involved - a lot of people who were involved in Wikipedia - and then having a number of articles come out about the project... Oh, god. I mean, our first articles were like on [unintelligible 00:08:44.29] They are two names I've not heard in a long time, but they gave us [unintelligible 00:08:51.28] the boost that we needed to really get that virtuous cycle going with that site.
Another one of those experiences where people are writing and e-mailing us and telling us "You saved our vacation. I got stuck in an airport and we had to find something to do with my kids, so we used Wikitravel..." So it's been a really successful project.
Are you still involved in it today, or is this in your timeline only?
Here's what happened with Wikitravel... We sold it to a company in 2006, and we stayed on and managed it for three years after that. After we left, the company didn't do as good a job as they could have in community management, and working with the admins. By that point there were something like 40 admins on the English version, 25 language versions... Different language versions: English, French, German, Romanian etc. and eventually the group of admins said "We're not getting the value out of this relationship that we expected" and they forked the project. It's now a Wikimedia project called Wikivoyage.
So the two still exist. Wikitravel is moving more to a read-only version, Wikivoyage is where all the big action is, but at this point I answer questions when people ask... I don't do a lot of speaking about it as much as I used to, but I try to be helpful...
Well, it sounds like you're still passionate about it though.
I am, I think it's a fantastic project. When we launched the Hungarian version of Wikitravel, we needed to have a core of admins. They told me that a country of eight million people at the time, eight million native speakers of Hungarian - there were no travel guides written in Hungarian. The only Hungarian travel guides dated back to the Soviet era, and were like for "Travel to Cuba", "Travel to Angola." They were only within the communist world.
For people who are English-speaking, it's one thing. We can get a lot of commercial options for travel guides. For people who speak Brazilian Portuguese, it's very hard to get a travel guide to Iceland, a travel guide to Goa, a travel guide to South Africa. There are much more limited options, so having a system like Wikitravel really helps more people travel in a lot of different ways, and I think that's been exceptional. I'm very proud.
And obviously not arrive at a hotel is not there anymore...
[00:12:02.19] Right... [laughs] Well, let's hope not. I think the other thing that's been really interesting that's happened with Wikivoyage and Wikitravel is that it's become the default data set for a lot of the travel apps on iPhone and Android.
Yeah, because it's Creative Commons license, they're able to use that and deliver it in different ways. There's also a very nice -- Media Wiki, the software that runs Wikipedia and Wikivoyage (the whole Wikimedia group) has a really great mobile experience... You can go through a mobile editing process where you're standing outside a restaurant that's closed, or you're at a hotel whose rates have changed, and you can just make the change right there. I think that's been really cool, too.
It was something that we didn't really have 15 years ago when we started the site. It was much more like you would go to an internet cafe and sit down, rent your PC by the hour and try and do your editing there. The mobile aspect has made that two-way process much, much easier.
Just looking at it - and I know it's quite different surely today than it was even when your data involvement stopped, but the name, the website, the software that runs it started in 2003, Wikipedia in 2001, like you said, you were inspired by it... I'm curious if there were efforts like "Be part of Wikipedia." I know that there's slightly different goals with a travel guide versus an encyclopedia, but was there ever -- you said there was some cross-pollination with the people that were editors. Was there any other involvement with Wikipedia proper?
Well, obviously we used Media Wiki... I was a core committer on Media Wiki for quite a long time; I built a lot of the extension mechanisms that work in Media Wiki, so your ability to write extensions, the whole hooks architecture for Media Wiki... Because I needed it for Wikitravel.
Media Wiki was very monolithic for running Wikipedia when I first started, so that was one of the first things that I really worked on. So there's that relationship... But you know, I think the big thing is that an encyclopedia is not a travel guide, right? Things like the phone number of a restaurant don't necessarily belong inside of an encyclopedia, but they're crucial for a travel guide. So that's the kind of thing that -- we tended to cover a lot of data that didn't necessarily belong inside an encyclopedia... And a different kind of presentation, too.
We tended to have abbreviated histories, abbreviated information... You're not looking for the full encyclopedic listing of the Eiffel Tower and its full history and what kind of steel was used; you're looking for when it opens and closes and whether it's open on Sundays after 10, right? So that's the kind of thing that people are looking for in a travel guide.
For a long time, we had this kind of "It doesn't make sense for us to be a part of the Wiki Media Foundation... Or should we be on our own?" I think there was also an expectation that not every Wiki in the world needed to be a part of the Wiki Media Foundation. Jimmy Wales started a company called Wikia that does some amazing wikis... There is a fantastic site called WikiHow, which is How To and instruction manuals.
[00:16:04.11] We felt like we were part of an ecosystem there. We had a good tie to Wiki Media and Wikipedia, but we didn't think that we had to kind of merge in. I think eventually having Wikivoyage be part of the Wiki Media Foundation has been a really good fit, but it was definitely a long time to get there.
So you gave us your formative experience, and I think most people who've caught the open source bug have had a similar experience to what you have in some form or another. I even had it even just writing on a blog... Just blogging technical things that I thought weren't interesting to anybody, but putting out very specific errors and then the fixes to them - it turns out that's of huge value to people who are also pasting those errors into Google...
So you have heaps of praise for saving somebody maybe a minute, maybe an hour, maybe a day of their life, and we all probably have also been on the receiving end of that - I know I have - where people have saved me countless hours.
Your Wikipedia articles says you're a free and open source software and an open culture advocate. Did that all start when you had that experience, and then perhaps the success of Wikitravel? Where is that coming from?
Well, I think part of that is that experience from the web, right? For me, having worked at Microsoft and then having had this kind of transformative experience of open source, I began a really deep involvement in web technologies. And even today, web technologies are 95%-98% open source anyways, right? But especially at that time it was Lamp Stack, you had to learn Linux, you had to learn Shell, you were using Emacs or using VI, and so pursuing that technology required that you had to go into that culture.
It was also an exciting time. The word "open source" was just coined around the time that I was starting out; previously it had been "free software." The first O'Reilly conferences were starting, and I spoke at one of the first Perl conferences... It's a very heady experience. I think that that has been really important, but also that feeling of like "What if we could use these same freedoms for other kinds of projects?"
Wikitravel is Creative Commons licensed, and it's a BY-SA, so it's a ShareAlike license, and I had not actually known a lot about Creative Commons before I started Wikitravel, but because of our involvement with Wikitravel, I got very involved with Creative Commons. I was a Debian developer and I helped with analyzing the Creative Commons licenses for inclusion in Debian, and kind of negotiating that process... Which was really good for both sides, I think.
I definitely think that there is a step-by-step process where once you get started, you find that there are lots of tasks all over the world for you to do. There are always issues that need more effort from more people, and people who have experience with open source can really make a difference.
One of the ways you've been applying that experience it seems like over the years is with regard to open-federated open source social networks. Give us a little bit of history of your work with Identica, Pump.io, StatusNet... These things.
[00:20:15.14] Yeah, so partly because my experience was Wikitravel, I was involved with a number of people who were interested in how free and open source software was going to be affected with cloud computing. This is like 2006-2007.
I was part of a group - The Franklins Street Group - that did some discussion and put out a statement (The Franklins Street Statement) about free and open source software in a kind of cloud computing world, and ways that people can be preserving their freedom in that kind of world.
At the same time, a lot of the social networks that we take for granted today were just starting to break through. In 2007 Twitter had their launch at South by Southwest, their big public launch... The classic epic launch at South by Southwest.
Being in there, their hockey stick began to rise.
Exactly. Everybody's been chasing that same hockeystick since, right? Everyone that goes to South by SouthWest is like "Yeah, it's gonna be guaranteed. That's what's gonna happen for us."
[laughs] That's what happens there, right?
Yeah, exactly. Facebook in 2007 launched the platform and opened up for non-college e-mail addresses; two really big steps there for Facebook. I was really interested in social networking... At the same time, we had some really interesting social "open stack", although that name has been used for other things now... Of OpenID, OAuth, Personal Contact, and a number of other interesting projects that were making it possible to have open standards for web applications... Especially web applications that had social aspects.
So at the time I was so charged up about free and open source software and web based systems that I was like "We need to have an open source social network." That's when I started the project that eventually became known as StatusNet. It's now GNU Social, so it continues to live and breathe, but at the time it was actually called Laconica... StatusNet is the name a lot of people know it by.
I launched a site that used a product called Identica, and that was really the first big step. So it was a micro-blogging site, and for many years it was very popular among a number of people, especially people who were involved with open standards, open source software, and it remains active today; there's still an active community, but a lot of that community has kind of moved on.
I think that as the period from 2007 to 2017 has shown, social software has become a crucial substrate in the internet experience, right? Something that a lot of us would dismiss as trivial, kind of unimportant... You know, find some friends, stalk your ex-girlfriend kind of thing... Now it is an important part of business, and it's really the way that most of us stay in touch with our friends and family, and yet it remains a system that is largely centralized around a few big sites, right? Facebook, Instagram, Snapchat and Twitter. And Google+ I guess, if you're in a certain group of people.
If you work for Google.
[00:24:04.27] Yeah, there you go. [laughter] I think it's definitely an area that continues to need focus from the open source community. The big thing that's been kind of the way that things have gone in waves -- so I started StatusNet, I published a federation protocol that would let two StatusNet applications talk to each other, and that was called OStatus. Then Diaspora came along and they built their own federation protocol that let you have two Diaspora systems to talk to each other. Tent.io came along - they have a protocol that lets Tent systems talk to each other.
So all of us were putting out this great free and open source software, very easy to use, very interesting stuff, but we didn't make it talk to each other, and that I think has been the big sticking point for federated software. I know that there have been at least 10 really interesting projects over the last ten years that have gotten a lot of media attention, and looked like we were gonna break through, but we keep having this kind of not-invented-here syndrome where we make our own protocol, make our own systems, and we don't make them inter-operate.
A project that I've been on in the last two years has been for the W3C to take best practices from all of these different systems and make the one ring to rule them all social standard. That has been really a successful project. We've been working over the last couple years first of all taking the Activity Streams standard and enabling it for JSON, making it easier to use. We've also defined a standard API that uses Activity Streams called ActivityPub.
The combination of those two means that it's very easy to set up a federation system in a lot of different applications. We're getting a lot of the applications like Diaspora, GNU Social, Mastodon is working on it, etc. to start moving towards a single protocol for federation. The hope is that we'll see a stronger ecosystem there.
I think that it's unlikely that Facebook will ever disappear from the Earth, but with luck and work we may see a good ecosystem of multiple implementations that are able to interoperate with each other and see some better behavior there.
Coming up after the break, we talk about the open web and all the social networks, Evan's open source social platform called StatusNet, Micro.blog and a JSON feed from Manton Reece and the importance of being open and federated, and Evan's role in the W3C Social Web Working Group. All this and more after the break.
Alright, Evan, you were discussing other social networks down through the ages... It seems like every couple of years there's a new round of potential Twitter replacements, or Facebook replacements... Like you mentioned, Diaspora... I recall Identica; I don't know what's still going on with Identica. Recently we've had Mastodon, there's people talking about Scuttlebutt, Manton Reece has a new thing called Micro.blog...
There's different things that pop up here and there... App.net was a huge one back in the day... App.net actually seemed like it had a pretty good chance for a while [unintelligible 00:29:09.01]
It seemed like it had the best chance of them all, yeah.
It did... But none of them stuck, and you had efforts - Pump.io - things that didn't seem to stick on their own, so what you mentioned before the break is the problem is each of these tries to be their own individual next Twitter or next Facebook or what have you... But what we really need is to allow to have a common protocol or common thing that all of them share, because it's very unlikely that something's gonna rise up that offers similar things -- I feel like it has to be a brand new thing to replace, and right now it's like "Well, we don't wanna wait for that brand new interaction, but also want something that's open and federated...", so you have the Social Web Working Group.
Let's just kick back off there. Tell us about what specifically the working group's working on and what's come of it.
Yeah, so the Working Group has like a mandate for three important tasks. The first is a social data syntax. That is a way of being able to encode in JSON statements about people's social activities. "Evan liked Adam's post" and "Jerod posted this text." Being able to describe in a JSON blob what happened, when it happened, who liked it... That is kind of the first part.
The second part is a social API, so kind of a client server API. Similar to the Facebook API or the Twitter API, you're able to build clients that not only do basic posting and listing, but also can do some of the really creative stuff that we've seen in the Twitter ecosystem, and to some extent in the Facebook ecosystem.
The third part and the third major deliverable is a federation protocol. When we talk about federation, that means a sever-to-server protocol, so that if Adam's on one server and I'm on another server, I can follow his posts, I can respond to them, I can send him a private message, he can see my images or videos... We can actually interact in a social way without having accounts on the same server.
The same way that we use e-mail or that we use some other systems, telephone systems. None of us expects each other to be on the same cellular telephone network, we expect them to just work together. That's the way we expect social systems to work, and we're looking to have that happen.
[00:32:06.24] We've done a combination of those three things: the Activity Streams System, the ActivityPub - ActivityPub covers both the client-to-server API and the server-to-server protocol.
We have a number of other things that have come out, which has been really interesting. We've encoded some of the other really cool stuff that's happening on the web and in social, so MicroPub is kind of a slimmed down version of ActivityPub. We have a system called Webmention, which is kind of a modernized pingback mechanism that does a very nice job of giving a federation experience. So we're basically doing a lot to put these things out there.
But a lot of my work over the last couple months has been bringing some of the folks together who are working on Diaspora, on Mastodon, GNU Social, my replacements on Pump.io (I'm no longer the maintainer on Pump.io) and having them work together on these protocols. It's been a very successful process, we're really happy with the uptick in the community. I think the question, as you said, is "What gets it to move forward?"
I think probably one of the things that we find a lot in open source systems - there are a lot of open source systems that start out like this - someone says "I hate using Adobe Illustrator. It's expensive, and crappy, and it doesn't work. I'm gonna write my own Adobe Illustrator, and it's gonna be much better." So we get this kind of reactive or negative foundation for the project, and sometimes those can work for a little while and sometimes people will actually use the project because of that negative foundation, like "I hate Illustrator, I love whatever replacement I would use. Inkscape, or something." But it has to become useful on its own if it's ever gonna succeed.
So none of us think of Ruby as like "Oh yeah, I hate C#, I use Ruby instead." We think of Ruby as something that is on its own. It isn't an anti-brand, it isn't a negative space.
But Ruby is not a social network.
Oh yeah, Ruby is not a social network, that's true... [laughter]
Good observation, Jerod.
Well yeah, that's why they pay me the big bucks.
So can these open source social networks take on a life of their own that isn't just about getting off Twitter, or getting off Facebook...
They all seem to stem from that though, right? Like, something negative happened on a network - either harassment or racism or anything... It happened on the network and it's not being policed well enough to a certain group's feelings or what not, and they're like "Let's move to somewhere else", in hopes of having good things, better community... But for whatever reason, it never catches on because it takes a critical mass, or then you kind of wish that -- in your case that you're saying here, you wish that network interracted with (let's just use) Twitter, for example.
Yeah, exactly. And there's that feeling that like "Grandma's on Facebook. Eventually, I'm gonna have to go back and say "Thanks for the happy birthday, grandma", right?" It pulls you back in, because they have that critical mass of people. So I think that tools that integrate using the custom APIs of Facebook, Twitter, Instagram etc. - those are ones that are more successful, so you can keep your existing networks without kind of giving them up.
[00:36:07.11] I think also ones that stimulate hackerly instincts are also really powerful. The more that we have cool third-party clients, the more that we have cool hacks, games that integrate with the social network etc., the more likely we're gonna be to use that kind of thing.
I think that you get a virtuous cycle where you have the platform, and then third-party clients build on top of that, and because there are third-party clients, there are more people using it; the more people using it, the more third-party clients want to build for it, and you get this nice cycle.
One great thing about having open standards is that if you're like -- there's no crueler fate than being a Twitter developer over the last ten years, right? There have been so many ups and downs... One week they're encouraging one thing for you to do, and the next weeks they're saying that that's forbidden and they're gonna turn off your API key, right? Same thing with Facebook. They've been definitely back and forth on what they wanna encourage people to do and not encourage people to do.
With open source networks and open standards, nobody can tell you what to do. If you want to build a competitor for the default Android client, go ahead. No one's gonna stop you. That I think can be really powerful. Getting outside of those big companies' main business models and saying "We are gonna build our own system that doesn't depend on that."
How does it sustain, though? That's the one thing I wonder. I mean, obviously, Facebook is one thing and it makes a lot of money, so it's able to progress its network, whereas with the W3C obviously you have members in different corporate interest layers... How does the motivation remain? Somebody's gotta eventually profit in some way, whether it's monetary, or a better network, or a better system, and that's the open web. So where does that motivation/funding/sustainability come from with this particular effort?
Yeah, absolutely. That's a really good question. There's definitely different sources of "Who's gonna pay?" I think for enterprise - a lot of enterprises have their own social network that they run internally. They'll have a Jive or a Yammer, or they'll use a messaging system like Slack or HipChat, right? So having something that's internal that they can also connect to partners and customers with is really powerful for them. Something that they own, they know where the data is, they control the user accounts - that's very attractive for those enterprises.
We had a number of companies that participated in the Social Web Working Group because they think social for business is an important aspect, and for them having multiple vendors, having choice in terms of the software that they use is really important.
I think that there are a lot of people like us for whom spinning up a DigitalOcean Droplet and putting a Docker image up is really easy, and we're like "Oh yeah, it's a few bucks a month, I don't mind doing that." But for the wider internet user community, if we can ever say --
My aunt is not gonna wanna do that.
Yeah, I guess that's just people now, right? There's no such thing as the internet community, it's just like humanity...
Yeah, the world.
In a world.
[00:40:03.10] They don't pay for the software, right? Asking them to pay for their social networking is not gonna work, so it's going to be -- I think that in a federated world what happens is you probably have a mix of advertising-based systems that do connect into that federation the same way as the self-hosted ones do, or the enterprise ones do. But I think it's interesting to think like "What's the advantage there?"
I think the advantage for someone who would be starting a commercial social network in that kind of world is like "I can start a new network and there would be hundreds of thousands or millions of people already on the network, because I'm being a part of this federation." So that's a big aspect.
The hard part is like "Well, what is the special value that I provide to my customers?" and being a commercial provider is gonna be a little bit tougher there. There have been a few -- we've definitely seen some advertising-supported systems, but it's definitely a little bit more of a slog.
The system in the protocol has to be independent, right? The ability to do so doesn't play to the same motivation for why you wanna do it, right?
All these different components to it - the social web protocols... Being able to and the motivation to do so are two different things. We have to give the open web a standard for which to do so, and that seems like what this effort is - it's less on "Why would somebody wanna do it?" but more so "How they should be able to do it."
Yeah, exactly. I think e-mail is also a good model here, and it's definitely a model to -- there are some negative aspects to it too, but we have people who use free e-mail systems like Gmail that are advertising the support and that are happy with that system...
Sure, that's true.
...a lot of enterprises who are like "You have to use the company e-mail for company business", and everyone knows that that's the way that works, as well as people who are like "Hey, I'm just gonna spin up my own mail server and use my own domain", right? I think that we have a good mix of that on the internet; there are definitely downsides to that, too... Like, it is really hard to run your own e-mail server in 2017, it is an uphill battle, but still possible, which I'm glad about. I'm glad that it's still there. It's one of those tasks that I do that I'm like "I just have to keep doing this." [laughs] I have to keep doing this because I want to believe that it's possible, right? Yeah, and it's definitely an interesting fight... So seeing that same kind of pattern in the social world is possible, too.
And again, with e-mail we have a mix of proprietary software, open source software, cloud-based software, web software, so I think that the same kind of thing will happen with social software.
I think e-mail is the best success story to use, because it's used globally by everybody. It's on open protocols, SMTP, POP3 and IMAP, and it's completely federated. I think a failure case - if you wanted to say "What worked for e-mail?" and then "What didn't work?" So IRC is the opposite, right? IRC is federated, IRC is very popular amongst people like us, and in many ways it's better, in many ways it's worse, but it never broke through, which is interesting, because they probably both started in the good old days. E-mail was used by everybody; IRC never made it outside of hacker circles, and even amongst us - most of us are on Slack, because they provide overall a better experience.
[00:44:13.00] So what - and I'm not necessarily asking you to answer this, Evan... I'm just kind of throwing this out as a thought - why did e-mail get traction and IRC never did?
Or even remain. Not so much just traction, but remain...?
Well, IRC's still out there, but it's not --
Yeah, but there are a couple things in there -- and obviously, hindsight is 20/20, right? I don't know, but it's kind of easy to say, looking back... There are a couple things that I think are interesting there about IRC. One thing about SMTP is it's super simple; the protocol is very simple, but extensible. In a lot of ways it's a little bit [unintelligible 00:44:55.14] If you start getting into some of the weird extensions, it can get really funky, but it has been this kind of layered thing that started with something simple, then we needed something else put on top of it, and so on and so on, right? Whereas IRC is just gigantic... The protocol is really big to start off with, and it's really complicated, and it maintains these live connections, so there's a lot of stuff that you have to do that's really kind of tricky.
So I think that's one thing - you mentioned POP3, IMAP and SMTP, as well as the e-mail message standard (MIME), the way that we do attachments... All this together is one thing on top of the other. If you wanna build e-mail, you're gonna be using a lot of different protocols, whereas IRC is very monolithic and very big... So that's one thing.
I think the other thing is that -- one of the things that I love about Slack is how quickly and easily extensible it is. You can build a slackbot... If you have any web programming skills, you can build one in an afternoon, right? Using the hook system is really fun and easy, and you can get some really fun behavior out of it, whereas building an IRC bot takes a long time, you have to have a live process that maintains these connections, and it's definitely a lot more complicated.
That third-party developer experience where it's like "Hey, I'd like to augment this experience by doing something a little bit fun or a little bit interesting or experimental, or tying it to another system..." - it's something that's really easy with a Slack, and hard with IRC; not impossible, but definitely not as fun, right?
E-mail is somewhere in the middle. A lot of us build applications to just like "fire off e-mail", but doing things like mailbox management is kind of a mess, right? That's not as much fun. So it kind of lies somewhere in the middle there.
So those are a couple things... Can you get something that's fun for hackers?
"Look at this cool, funny thing I built", right? And that's the kind of thing that just like -- once you've got the hackers, then you've got their friends and family coming on, because they love looking at that stuff.
How many of us use Twitter because of all the hilarious bots that are on there? That's a big part of a lot of people's Twitter experience, right? That is largely because they built an API early on that was fun and easy to use. You really don't need to know much about the Twitter API to be posting. I think that the more that open source projects are easy and accessible to third-party developers, the more that we get fun bots, fun add-ons, fun applications, fun games that run on the network.
[00:48:29.02] One of the things I'll add is that even a more basic concern with regards to -- just going back to IRC versus e-mail and why one took off and one didn't... E-mail appealed to humans at a level they already understood. You already know how the mail system works; I'm talking conceptually now, not technically or anything like that. "This is like mail for your computer", and that's something that everyone was like "Oh, okay, I get mail. Internet mail? Okay, I'm gonna get mail on my computer." I'm just talking about human buy-in into the network, not just how it works and the federation...
The people who are creating cool things, like you said, are attracting other people to use it, but the ones who are just deciding "Should I get an e-mail account?", they're thinking "Is this gonna provide value? Is this something that I understand and can use?" whereas IRC was very technically challenging (like you said), very insider. Actually, when I was exposed to IRC as a young lad - I probably was like 16, 17 - it was scary, weird... The whole interaction with IRC was something...
Yeah, foreign... And it had a bit of a -- even then (this was the late '90s), to me at least, the way it was introduced to me, it had like this underground, scary, kind of like forbidden fruit thing that to me was attracting, but to most people, they were like "Oh, keep me away!"
And you also have to not just get the technical things right, but there has to be some sort of hook into the humanity, and saying "This can add value to your life, and by the way, it's something that you can totally manage and do." And I think a lot of the struggles with us as we try to build open things, because we're so concerned with doing it right - which, of course, is paramount - is that we don't have the right sales pitch for the other people who -- it would be better for them if they were to buy into this system, as opposed to using Facebook all the time... But we don't tell them why it would be better in a way that's actually palatable or real for them. So lots of struggle - some technical, some social.
Yeah, and I think that a lot of times we see a gap between the user and the thing that they wanna get done, and we think of that gap as the user's fault. If someone says "Oh, I don't understand how to use IRC", it's like "Okay, this is what you have to do. Look for an IRC client for your platform on the web, install it, then find the right network and then register a nick, and then this and that. Here are all these things that you have to do, and here are all these steps." And they're like "I'm never gonna do those things", right? Versus having, say, a web-based experience like a Slack where it's just like "I go in, I punch in my e-mail address, it sends me a link, and Boom! I'm in the community I wanna be in."
In the open source software community we tend to think like "You must be at least this tall to make it into this ride", right?
[laughs] Yeah, exactly.
"You must be this smart to use our software, or you're not good enough for our software", right? And then we say things like "Why doesn't anybody use our software?" and it's like "Well, because you said they're not smart enough, you said they're not good enough." Nobody wants to be told that they're not good enough, and nobody's gonna not do a task because you told them they're dumb; they're gonna go find someone who says "You're smart" and they're gonna go find someone who says "Here's the easy way to do that", right?
[00:52:15.22] How many of us -- I think things that we do, like having cut & pasteable curl outputs to Bash - curl shell scripts down, and then output them through Bash, and do an installation... That is -- everybody knows it's the wrong thing to do and everybody has criticisms, but it's soooo easy! One copy & paste, right?
Finding those things where it's like "Maybe we could close that gap a little bit. Maybe we could just make it a little bit easier for folks", and eventually that spark happens, right? And I think that it's really up to us, rather than up to the users to close that gap.
Well, speaking of not using software and making things easier - before we get a little break and transition to the next topic, I wanna ask this about a tweet you had about Mastodon, which is one of the most recent efforts to do a federated social network...
You put out a tweet basically being bummed that they didn't use ActivityPub, and you said at the end of the tweet that's all you had to say, but I doubt that's the truth... [laughter] So on the note of not using software and--
Are you calling him a liar? [laughter]
Well, I'm sure he has more to say and I'm giving him a chance to say it right here.
So you know, maybe not so much a response to that tweet in particular, but maybe to those out there who are doing something similar to Mastodon or even themselves, to use the different protocols that you and the folks at W3C have been doing around the Social Working Group... Like, give them the pitch of why ActivityPub should have been used, and the first steps.
First of all, there are Mastodon developers who are working on implementing ActivityPub right now. I'm very happy about that. The author of the ActivityPub spec has been working really closely with Mastodon folks, so I should probably unpin that tweet at this point...
Delete the tweet...
I kept having people who were like "What do you think about Mastodon? What do you think about Mastodon?" and I think for me -- Mastodon uses a protocol, OStatus, that I was one of the main authors for. So it's not like it's a problem for me that they're using OStatus; the thing is like, they just started something new, they started this new project, and we've been working on this great improvement over older standards, and it's like I wish we had -- this is another example... As a standards developer, I wish I had closed that gap earlier, right? I wish that we had had something ready for them at the time that they were looking for a protocol suite, right?
So I think that in a lot of ways that is not a criticism of the Mastodon developers, who are doing AMAZING work. I love Mastodon, it's a beautiful system, and they're doing a lot there. I take it more as a criticism myself; I wish that we had had the product there ready for them to choose. I think that's my big disappointment.
That said, I'm excited that they're picking it up, GNU Social, Diaspora, Pump.io... We're seeing some really good movement in the ActivityPub's space.
I think that I've said also a lot of things about federated social web that apply to Mastodon, too. You can't live forever being the anti-Twitter; eventually, it has to be something that's valuable in and of itself. Supporting third-party developers....
[unintelligible 00:56:15.20] "We're not this thing", and that thing was Twitter, and that was what was supposed to attract and keep in it. Eventually, you just posted to Twitter AND at DotNet, and then it was like "Well, why am I doing this?" But maybe you had longer conversations. There was a small group of people who had a good experience there, but in the end they just didn't stay... And Twitter just attracts more people, the masses, the mainstream; when more and more people are there, you can't deny the network's presence.
Yeah. I mean, I think that for people who are passionate about Mastodon, what they need to be doing is don't be the doomsayers; don't be the Cassandras, don't be bringing everybody down by saying "You really shouldn't use Twitter. You really shouldn't use Facebook." Build a cool app that uses Mastodon, build something really fun that's only on Mastodon. Make a cool bot, make a cool account, make something that's foreign and interesting there, because that's how you get a community that's excited on its own, and that's what attracts people. Negativity only goes so far.
Coming up, we talk about Fuzzy.ai, a service that lets you create agents that add intelligence to your applications. We talked through ways to add simple, intelligent responses to your apps, that have a huge impact on the users' experience. Evan also makes a huge claim by calling data the new oil. It's required for machine learning engines, yet it's a scare resource and one that not everyone has. All this after the break.
What's this next thing for you? Where you're at now is in AI... We've kind of shared Evans' history, so to speak; your history through the social networks, creating standards, and we're in a place now where AI is taking far more presence in things. You've got machine learning, you've got deep learning - you have all these different stacks of basically artificial intelligence, and you've got a new endeavor that is spawning from this. Can you talk about that?
Yeah, so my new company is called Fuzzy.ai, and it is an AI API that makes it easy for developers to get started with adding intelligence to their software. You've mentioned a number of different systems for doing AI - machine learning, deep learning are really powerful algorithms based on neural networks that have had some really amazing results over the last few years. We've seen a lot of interesting stuff happening. There are downsides to those systems, too.
[01:00:03.00] To get a deep learning process going, you really need two things. One, you need a lot of data - like, a LOT of data - maybe hundreds of thousands or millions of rows of data in order to get really good intelligence out of a deep learning system. The other thing is that deep learning systems can be very sensitive to minor changes in parameters. If you modify how your networks are laid out, what kind of layers you have, what kind of inputs you're putting in, you can get very different outputs, you can get very different intelligence, and it takes a skilled hand to get a machine learning or deep learning process that can be used for production software development.
That combination of needing a lot of data and needing very skilled data scientists in order to get machine learning to work for you is a real non-starter for a lot of companies, right? And it means that when you're trying to do -- I like to call it "casual intelligence"... So this isn't your "bet the company" artificial intelligence. This isn't putting a brain under the hood of a car, this is like "Hey, maybe we could make our menu organization a little bit more adaptive for our end users. Maybe the e-mails that we send out could be a little bit more sensitive to their particular context." All those little experiences that we have with software, could we make them a little bit more intelligent?
That's the kind of problem that we're trying to do with Fuzzy.ai. Those are hard things to do with big data stores and lots of data scientists; nobody's got those kinds of assets to apply to improving web experiences, but we can do that with other algorithms.
With Fuzzy.ai, we use a hybrid logic learning system, so that we'll start off with explicitly states rules in a programming language that are then used as the initial decision-making process, and then based on feedback from production use, we will actually improve their behavior with a learning process.
Let me think of an example really quickly... Let's say that we were trying to do a system that sends an e-mail to new web users after a few days, just saying like "How's it going? Is this working for you?" and we wanna know how many days out to send it - do we send it one day, do we send it nine days?
We could build out a Fuzzy.ai agent - we call it an agent - that makes that decision, "When should we send an e-mail out?" Maybe they are a user who came from the Stack Overflow podcast and we know that those tend to be more busy people who have a lot of work that they're doing, so maybe we'll give them a little bit more time. Maybe it's someone who's coming directly from Google, we know they have a short attention span, so we give them less time.
We can use rules like that almost in the same language as I've just given, and use that to make the first decisions. Then based on whether people actually respond to the e-mail, we can then say "Oh, that worked. This person responded to the e-mail, so that was a good number of days to wait." Or "Oh, that didn't work; they never responded, so that was a bad number of days to wait", and we can feed that back into the algorithm, and it will actually learn what input data actually maps well to the output data.
[01:04:06.21] The reason that I like it is that I often wanna put intelligence into my software. I was getting really frustrated with these moon shot machine learning processes... I was like, "We're not gonna dedicate six months of training and hiring and getting a data scientist on board just to decide when to send the e-mails out", but this is something that can actually optimize our business, and making those small optimizing changes are really important for any online business.
And you can have big payouts, too.
Make a user happy that quickly - using that e-mail as an example - you can really have a huge impact very quickly on a brand new user, or whatever the case might be.
Yeah, and that's really the difference between frustrating a user and delighting a user - having a little bit more intelligence. How many times have you been using an app and you're like "Look, I already told you five times I don't wanna do this. Quit popping this up to me." Or "I wanna get back exactly to the page I was at before. Take me back to that." Every time something acts intelligent and recognizes who we are, recognizes what we want and tries to do things for us, those are the apps that we stick with. The apps that are very rigid and don't adapt to us, those are the ones we get frustrated with and eventually stop using. No one likes to feel like their software is framing them in.
The idea, again, with Fuzzy.ai is like "Can we make it easy to build artificial intelligence into your applications without having to devote a huge amount of data and a huge amount of time and money into making things intelligent?"
You used the e-mail as an example... Are there other examples that are perfect fits? Because obviously, every intelligent response or every intelligence requirement in software isn't perfect for Fuzzy.ai, so aside from the example here, what other good examples can you give that are just not that perfect for Fuzzy.ai?
What I tell developers is every time you have a constant declaration or if you have an if statement, that's a good time to be calling Fuzzy.ai instead. I'm only joking, but [unintelligible 01:06:40.09] That is a lot of things, but we do -- that constant declaration is such a great example though, because how many times have you sat there and been like "Wow, I wonder how long we should wait for that e-mail? Let's say seven days." You put it in there, and then those things stick around in your code forever. It's like, "Well, that's just based on my guess I made on a Tuesday before the software had to ship", right? It doesn't have anything to do with the reality of the world.
We have companies that use Fuzzy.ai for all kinds of different things. We have a company that uses Fuzzy.ai for matching up clients with attorneys, so people who are looking for legal services, they're able to find attorneys that will perform those services... For the right amount of money, who are nearby - that kind of thing, adapting directly to them
We have customers who use it for analyzing your social networks - who's important to you really in your social network? Who's less important to you? Who are you connected to that's meaningful? And if we wanted to bring together the most meaningful people in your social network, who would they be? Those are a couple things...
[01:08:07.29] We also use them for things like "When do you show a pop-up, if you show a pop-up?" Let's say you have an e-commerce site and you want to pop up when someone's checking out like "Hey, would you like to add something to your shopping cart?" Well, that can be really annoying for people; people might not like it. Or you could pop up exactly what they need and want, and you've just added $10 or $100 to your sale. So knowing when to do that the right way is really important.
Those are a couple things... I think another thing that 's been really interesting for us is the growth of chatbots. There are a few really great chatbot systems out there, APIs for chatbots, as well as different plugins for chatbots. A lot of chatbot systems are very static. They'll have a pizza ordering bot that no matter how many times it offers me anchovies, I say no and it still keeps offering me anchovies. It should learn eventually that I really like pineapple -- I don't like pineapple, by the way; I way prefer anchovies... I probably should switch that route. But it should know that people over time don't like anchovies, they prefer the pineapple; "We should really offer the pepperoni rather than the sausage, because that's what people want."
So taking the initial assumptions of your software and exposing them to a testing environment, in a lot of the ways that we do with A/B testing - exposing them to a testing environment and letting them actually improve over time is a lot of what Fuzzy.ai is about.
What you mentioned there about the pop-up -- because I wear a marketer hat sometimes, right? And there are times when I want to share a message with people who may visit Changelog.com. This may be in the future we'd do different things, but there are times when I think "Okay, to this type of user I'd show a pop-up, because they can be okay with it", and there's other users you just wouldn't want to. It sounds like this is a perfect tool for user experience designers, marketers, people who wanna make wiser choices on things they wanna do, but not do for every single user type. Extending from that, is the UI for training it easy to use? How does that work?
We have a developer environment. I think that for me the user experience had to be really good, because we were looking for something -- you know, if you use some of the really great developer APIs like SendGrid or Parse... Some really nice APIs. They have great UIs that are really easy to get started with, and we wanted to have that, too.
I have a good friend, his name is Kevin Fox - he was the user experience designer for Gmail 1.0, he also designed Google Calendar (the first version), he was at Facebook... Now I'm thinking that you probably should have interviewed him instead of me, but... [laughter]
While you're talking about your team real quick, we'll also tell you that James Walker is a long-time community member and a friend of ours, so that's another person o your team...
In fact, I didn't realize Fuzzy.ai - on the About page you've got five folks, so you're just getting started, small team... I remember asking James "Do you know Evan Prodromou? Because we're gonna interview him." He's like, "Yeah, I know Evan." [laughs] He's like, "Of course..." So hi, James...
[01:11:59.18] Yeah, getting James on was just fantastic. James is one of the most versatile developers I've worked with. Very smart, very quick at learning new things, really thorough... We worked together on StatusNet too, so when I started Fuzzy.ai I was like "I know one person I need to lead the software development effort." So he's been with us for a year and a half now, and he's just one of my favorite people to work with.
Cut all that out, because it's blow his head up... [laughter]
No, we're leaving it in.
[laughs] But he's done a great job with the way our system works, too. Kevin built our developer environment, and our development environment is very straightforward. It's very easy to use, it starts off with a rule-based system, so you can kind of put together your inputs and your outputs, and you really write out your rules in this very natural way that is kind of the first step to the process.
Then the integration, we've got good drivers from those web languages - Node.js, Ruby, Python, PHP - that make it easy to call us from your system. And it's a RESTful API that anyone can call remotely. So it's a nice kind of system to do.
It was funny, you were talking about the pop-ups... One of the ones that people have been really interested in is that "Rate us in the App Store" pop-up, which can either be a great growth hack for an app, or it can kill it.
Oh, don't show that to me, man... Don't show it to me.
See? Exactly, you wouldn't want to show it to the Jerods.
I'm the guy that you don't wanna ever pop up anything on me; I'm just gonna get mad.
Right. And there's some people are like "Thank you for sharing that you have an e-mail list", or "I can extend my experience..." [laughter] That's what I mean. There's the flipside that it takes a human touch to figure out, but if you can train a Fuzzy kind of thing in this case - the "fuzzification", as you mention in your terminology - if you can beat human training this thing to do it, these little micro-interactions that have big implications to user experience and potentially even company growth. That's a huge gap being missed.
Yeah, and I think it's an exciting part of -- you know, it's not the entire AI ecosystem; it's not everything that's happening in AI, but like any software ecosystem, I think that there's going to be a lot of different players. There's gonna be a lot of different things going on there. And for every exciting [unintelligible 01:14:51.16] that is pretty amazing; it's pretty amazing that those systems work. I think that we all have to understand that there are gonna be lots of sharp edges that we will buff off using AI, and it's gonna make using software a lot better. We're all gonna enjoy it a lot more. It's gonna be something that we're going to actually be looking forward to.
We've done a lot of work on this over the last 10-20 years, to the point that people are almost in this addictive behavior with their software, but I think that there's gonna be a lot of things that we can do to make it more fulfilling and enjoyable and fun to be using software, and with lots of little agents that kind of help you along the path.
Well, considering the conversation we've had... We kind of broke one of our rules, which was talking about the commercial operations, so to speak, with potentially no open source aside from SDKs, so I'm kind of curious, given the conversation we've had about your experience and participation in open source and all the things you've done, Fuzzy.ai is a company, it's a for-profit... I'm curious how this plays back into impacting open source.
[01:16:13.06] Yeah, that's a really good question, and I think that that's definitely something that's been on my mind as we've been working on Fuzzy.ai, because we do have -- you know, a lot of our stack is open source; we publish a lot of what we do either out through GitHub or through npm, but there are some parts that aren't. Our core engine is not. That's something that's really interesting to me.
We had an experience when we were doing StatusNet where there was a really good alignment between what we needed the company to do and what we wanted the software to do. If we had someone go and install StatusNet on their own servers and we helped to make that easier, it was helping the company.
I think that if we were to take our engine out and have people integrate it into their own stuff, we would probably need to support that, and the question then becomes "What would supporting that look like?" and whether we would be able to do it.
I also thing that in a connected world "Does it matter for them?" Does the kind of customer that we're using - are they gonna benefit from taking out stuff and installing it themselves, or is there some value for them in just calling our stuff? It's definitely not something that I look at lightly. For me what's important is that we have an increased democratization of AI, and I think that's something that's gonna happen over the next few years, and I think that tools like Fuzzy.ai can be really helpful in that, but we have to have more people doing more work with AI. If it remains something that's only done by very few companies, like Google, Facebook, Amazon, Microsoft - and the list gets really short after that - and that you have to have these huge resources to even get started, like huge data sets, very expensive data scientists in order to get started, that's gonna lead to a very interesting situation down the road, right? So I think that having a system that makes it easier for more people to participate in AI today is the most important thing to me and my team. How that happens is kind of up to us.
I think for right now having a public API is the way that we think that we can do that the best. Never say never... There's all kinds of things that we think can happen in the future, but for us right now that public API is the best way that we can think of to get that democratic experience of AI happening.
When you say "public AI" what do you mean by that?
Oh, sorry, public API... Just that it's a remote API that's visible publicly.
You mentioned the big players, and what you called it earlier was the moon shot AI method (deep learning, machine learning) - these things that admittedly requires, like you said, an operations team at this point, historical data and lots of effort.
A big investment.
Yeah, a big investment. The trend in technology is that over time those things become more and more accessible to more and more people or more developers or companies. We see that happening a little bit with TensorFlow...
[01:20:02.10] We did a show maybe a year ago now Adam with Eli Bixby about TensorFlow, and back then we had him walk us through "What's it take to get this into my application?" That was the majority of the show.
Training it, having the data... A lot of steps.
Right, but even since then, they've made some moves where certain other models are available as a service, or publically available things... So I think you're fitting into a great little niche here, in between moon shot and nothing, and I see huge value there. My question is like long-term are you afraid of getting squeezed out, as those don't become moon shots anymore, but the more general purpose machine learning things become more available and accessible to people to where your offering is not as good as what's also pretty cheap or easy?
Yeah, that's a good question. I think that for me it's that machine learning experience which -- I think that they're making leaps and bounds in the availability; it's getting a lot easier. But the big thing for me -- one of my friends, Alistair Croll, says "Data is the new oil." It is the thing that you have to put into your machine learning system to make it go, and it's a resource that not everybody has. And being able to instead work with knowledge that exists within your company, or best practices from your industry, or just insights that you have personally and being able to encode that into an AI system - I think that that's gonna be a very competitive part of the AI ecosystem no matter what happens.
We have customers that use Amazon's ML, or they use TensorFlow on Google's system, as well as Fuzzy.ai, because they serve different purposes. One is a very data-hungry system, one is one that really depends on knowledge that comes from your industry, right? And that's the two things.
But yeah, you talk about some of those moon shots... For me, you see these self-driving cars that are going around, and they're great, and I'm really looking forward to the time that we have that, but right now you need two engineers sitting upfront who are like tuning the network just to make it go. That's the self-driving car of 2017. For me, I would really like it if my windshield wipers turned on and off based on whether it's raining or not. I don't wanna have to switch from fast to slow on my windshield wipers every time it starts squeaking. I would like that to be automated.
Wow, I didn't even think about that. You just totally ruined for me now.
Oh, I'm sorry about that...
Oh yeah, but those little bits of automation, little bits of intelligence that we can do, is something that would really -- that changes an experience for us. So I think that for those of us who create software, thinking about "How can we make those little experiences better through intelligence?" - that's where we think Fuzzy.ai fits in.
I don't think we're the only ones who are gonna be in there - I think there's gonna be a lot of different options in there - we just wanna be one of the tools that people have to do that. There's gotta be a spectrum. Just like we use different programming languages, just like we use different protocols for different uses, we can use different AI systems for different kinds of problems.
Adam, quick, a future prediction for you before we close here. My oldest daughter is nine. When she turns 16, is she going to learn how to drive, or not? What do you think?
Man... You're asking me to predict. So she's nine...
That's seven years... Optional - driver's license?
I would say it's an elective at that point.
How do you feel, Evan? Do you think that's about right? On moon shot self-driving cars.
I think that that is a really close one. I think that by that point it's going to be a personal choice. If you're someone who loves cars, you can be like "Yeah, I totally wanna drive. That's gonna be something I'd like to do." But I think by that point you're gonna be able to say "I don't need to. I can let the car drive."
I hope you're right. I don't even want her to have to drive a car. [laughter]
Well, it's been a blast, kind of diving back into your history and pontificating about the future of AI and then what you're doing here on the microsides of it. I think these small wins -- there's a great saying that says "How do you eat an elephant? One bite at a time." How do you create a good user experience? One small win at a time. I think that this conversation certainly enlightened me... Thanks for coming on, man.
Thank you guys so much. I think I told you before we started I'm a big fan of this show, so it's definitely a dream come true to have been on.
That's awesome. It's certainly been fun having you on the show, man... Thank you.
Our transcripts are open source on GitHub. Improvements are welcome. 💚