The Changelog: Software Development, Open Source - The power of wikis, the problem with social networks, the promise of AI (Interview)

Episode Date: July 14, 2017

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.

Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com. And we're hosted on Linode servers. Head to linode.com slash changelog. This episode is brought to you by Linode, our cloud server of choice. Everything we do here at Changelog is hosted on Linode servers. Pick a plan, pick a distro, and pick a location. And in seconds, deploy your virtual server.

Jewel-worthy hardware, SSD cloud storage, 40 gigabit network, Intel E5 processors, simple, easy control panel, nine data centers, three regions, anywhere in the world they've got you covered. Head to leno.com slash changelog and get $20 in hosting credit. Hello and welcome to the Changelog, a podcast featuring the hackers, leaders, and innovators of open source. I'm Adam Stachowiak, editor-in-chief of Changelog. On today's show, we're talking to Evan Perdomo about his history in open source. He's someone who's been involved in open source since the early days. We talk about his open source travel guide, Wikitravel, the open source social platform called StatusNet, and the follow-up platform called Pump.io. We also talk about Fuzzy AI, a service that lets you create agents that add intelligence to your applications

and a lot of fun stuff around intelligence and user experience. All right, let's get to the show. All right, should we start? Yeah, we should start. You mentioned open source since the 70s. I'd say let's... Well, not since the 70s. Sorry.

He's 48, so that's 10 years your senior. So call it 90s. Yeah. Sorry. That's my that's my earliest time. Yeah, my I think my Whoa, that's a that's a really good story. Actually. Are you guys recording? We are right there. Yeah, tell I was working for a very big company based out of Redmond. And 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. And 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. I'm like, what should, you know, how do I do this? And 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. And 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 email, 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. And then I published a big FAQ. It was basically a how-to for using Pearl on Windows NT. And I'll never forget that experience

of publishing. This is a relatively small open source participation, but publishing that and just having this flood of dozens of emails coming in saying, thank you. This is exactly what open source is about. Like, we're so glad you did this. This has saved my life. This has been so important to me. Keep doing this. And I was like, this is amazing. In my entire life, I'd only been doing software

for about five years. And 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. So that was it was a really, you know, I think for a lot of people who get involved in open source, that feeling of gratitude that comes from people who use your, your software gets kind of addictive. It's really like, you're like, I'm making a difference for people with something that I didn't even know, uh, would matter to them. What year is this? You said Windows NT, so that's like mid nineties. Five. Yeah. It would be 95, uh, or early 1996. Yeah.

Yeah, it was a really good experience. I mean, Pearl 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. Great experience there. And I think that, you know, the other projects that I've launched and have had that great feedback, like it is, it is a high that like, once you've had it, you just want to keep getting it again and again. Tell us about some of those. I know Wikitravel sounds like it was a big success. Tell us about that story. 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, you know, was trying to figure out what I was going to do next. So we were traveling around the world. We were doing all kinds of interesting travel. And we were using, you know, at the time what everybody used, which was great big guidebooks, you know, those big like 500 page guidebooks that would say name of publisher 2003 right and uh you know we we used one to get to a hotel in thailand on a uh on an island called kosomet and we had to take a ferry from the mainland to this island and then a jeep to get to this hotel no internet for this hotel no phone right this is a this is a backpacker kind of

place and 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, right? There was just like a little bit of, of detritus around on the ground. So as we were doing the five mile walk back to the Harbor town, um, we were, we were asking each other, like, what are we going to do about this? Right. The, I think the thing that really surprised us is that we had just had an experience where our guidebook was catastrophically wrong for us. And it wasn't that big a deal.

We could recover for it. But the worst part being that there were going to be hundreds of other people that would come make that same mistake, right? That listing was going to remain in that guidebook. Unless we reported it, it just was going to stay there forever until they came out with a new edition or they sent a writer out. And we were like, this is something that makes no sense. Like, 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 is that most travel guides are updated on a three to five year editorial cycle, right? 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 a writer out more than once every three or five years. I had been looking at Wikipedia. I was really interested in it. 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. That if there were changes in prices, if hotels or restaurants opened or closed, that kind of stuff would get updated immediately. And so 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, like our first articles were on Advogado and Corrosion. There are two names I've not heard in a long time. But they gave us, and Slashdot, and they gave us the boost that we needed to really get that virtuous cycle going with that site. But another one of those experiences where people are writing and emailing us and telling us like, you saved our vacation, I got stuck at an airport, and I needed to find something to do with my kids. And so we use WikiTravel. And so it's been a really successful project. Are you still involved in it today or is this in your timeline only?

So here's what happened with WikiTravel is that 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, et cetera. 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. And it's now a Wikimedia project called Wikivoyage. And so the two still exist.

Wikitravel is moving more to a read only version. Wiki voyage is where all the, all the big action is. Um, but, uh, I have been, I'm at this point, uh, I answer questions when people ask. Um, I don't do a lot of speaking about it as much as I used to. Um, but, uh, I try to be passionate about You sound like you're still passionate about it, though. I am. I think it's a fantastic project, right? When we launched the Hungarian version of WikiTravel, we needed to have a core of admins.

And they told me that a country of 8 million people at the time, 8 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, you know, travel to Cuba, travel to Angola, right? Like they were only within the communist world. world and uh you know for people who are um living 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 uh you know brazilian portuguese uh it's very hard to get a travel guide to iceland a travel guide to goa a travel guide to Goa, a travel guide to South Africa, right? They don't, they're much more limited options. So having a system like Wikitravel really helps more people travel in a lot, a lot of different ways. And I think that's, that's been exceptional. I'm very

proud. Obviously not arrive at a hotel that's not there anymore. Right. Well, let's hope not. I mean, I think the other thing that's been really interesting that's happened with Wikivoyage and Wikitravel is that it's become the kind of default data set for a lot of the travel apps on iPhone and Android, right? So because it's Creative Commons, 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, you know, MediaWiki, the software that runs Wikipedia and Wikivoyage, the whole Wikimedia group has a really great actually mobile experience. And so 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. And I think that 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 know, you would go to an internet cafe and sit down, rent your PC by the hour and try and do your editing there. And the mobile aspect has made that two-way process much, much easier. It was like the, just looking at it, um, I know it's quite different surely today than it was even when you, your day-to-day involvement stopped, but, uh, the name, the website, you know, the software that runs it, um, started in 2003, Wikipedia, 2001, like you said, you were inspired by it. Curious if there were efforts to like be part of Wikipedia.

I know that there's slightly different goals with a travel guide versus an encyclopedia, but was there ever like, you said there was some cross-pollination with people that were editors. Was there any other involvement with Wikipedia proper? Well, obviously we used MediaWiki,

and so I was a core committer on MediaWiki for quite a long time. I built a lot of the extension mechanisms that work in MediaWiki. So your ability to write extensions, the whole hooks architecture for MediaWiki, because I needed it for Wiki travel. MediaWiki was very monolithic for running Wikipedia when I first started. And so that was one of the first things that I really worked on. So there's that relationship. But I think that 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, right? 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, we tended to have abbreviated, um, histories, abbreviated information. You're not looking for the full encyclopedic listing of the Eiffel tower and, and its full history and what kind of steel was used.

Um, you're looking for when it opens and closes and whether it's open on Sundays after 10, right? Like, so that's the kind of thing that people are looking for in a, in a travel guide. Um, you're looking for when it opens and closes and whether it's open on Sundays after 10, right? Like, so that's the kind of thing that people are looking for in a, in a travel guide. Um, for a long time, we had this kind of, uh, you know, doesn't make sense for us to be part of the Wikimedia foundation or should we be on our own? Um, I think there was also an expectation that not every wiki in the world

needed to be at part of the Wikimedia Foundation. So 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 and so we felt like we were part of an ecosystem there um we had a good tie to uh wikimedia and wikipedia but we didn't think that we had to kind of merge in so and uh yeah it uh i think eventually the um it having wiki voyage be part of the wikimedia 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, uh, you know, putting out very

specific errors and then the fixes to them, if it turns out that's a huge value to people who are also pasting those errors into Google. And so you have like, you know, heaps of praise, um, for saving somebody, you know, maybe a minute, maybe an hour, maybe a day of their life. And we've all probably also been on the receiving end of that. I know I have, where people have saved me countless hours. Your Wikipedia article says you're 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's that coming from? Well, I think part of that is that experience from the web. For me, having worked at Microsoft and then having had this transformative experience of open source, I began a really deep involvement in web technologies. And when you're talking about, I mean, even today, web technologies are 95, 98% open source anyways, right. But, you know, especially at that time, it was, you know, LampStack. 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. And the first O'Reilly conferences were starting, and I spoke at one of the first Perl conferences. And there's that.

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, right? So WikiTravel is Creative Commons licensed and it's by SA, right? So it's a share-alike 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. So 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 slash federated open source social networks. Give us a little bit of history of your work with Identica, Pump.io, StatusNet, these things. Yeah, yeah. So partly because my experience with 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. And this is like 2006, 2007. So I was part of the group, the Franklin Street group that did some discussion and put out a statement, the Franklin Street statement about free and open source software in a kind of cloud computing world and ways that people can be kind of preserving their freedom in that kind of world. At the same time, a lot of the social networks that we take for granted today, we're just starting to break through, right? So like 2007, Twitter had their launch at uh south by southwest um or their big

public launch right their big the uh the classic epic launch itself south by southwest facebook opened up their hockey stick began to exactly exactly everyone's been chasing that same hockey stick since right like everyone who goes to south by southwest is like yeah it's going to be guaranteed that's what's going to happen for us. That's what happens there, right? Yeah, exactly. Facebook in 2007 launched platform and opened up for non-college email addresses to really big steps there for Facebook. And I was really interested in social networking. At the same time, we had some really interesting social, quote unquote, open stack, although that name has been used for other things now, of OpenID, OAuth, personal contact, a number of other interesting projects that were making it possible to have open standards for web applications, and 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. And so that's when I started a project that eventually became known as StatusNet. It's now new social. So it continues to live and breathe. But at the time, it was actually called Laconica. But 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 microblogging 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. They're still an active community, but a lot of that community has kind of moved on.

It is a, I think that, you know, as the period from, you know, 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 a, 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, Snap, and Twitter. And so the, and Google Plus, I guess, if you're a certain group of people.

So I think that a, there you go. I think that it's a, 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 O-Status.

And then Diaspora came along and they built their own federation protocol that lets 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 10 years that have gotten a lot of media attention and look like they were going to break through. But we keep having this kind of not invented here syndrome where we like, you know,

make our own protocol protocol make our own systems and and we don't make them interoperate what uh a project that i've been working on in the last two years um has been for the w3c um to take best practices for from all of these different systems and make you know the one ring ring to rule them all social standard. And that has been really a successful project. So we've been working over the last couple of 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 ActivityStreams called ActivityPub. And the combination of those two means that it's very easy to set up a federation system

in a lot of different applications. So we're getting a lot of the applications like Diaspora, GNU Social, Mastodon is working on it, et cetera, to start moving towards a single protocol for federation. And 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, microblog and GSON feed from Manta Reese 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. This episode of The Change Log is brought to you by TopTal, a global network of top freelance software developers designers and finance experts if you're looking for contract or freelance opportunities apply to join toptow to work with top clients like airbnb artsy zendesk and more when you join toptow you'll be part of a global community of developers who have the freedom and flexibility

to live where they want travel attend toptow events all over the freedom and flexibility to live where they want, travel, attend TopTal events all over the world, and more. And on the flip side, if you're looking to hire developers, designers, or finance experts, TopTal makes it super easy to find qualified talent to join your team. Head to TopTal.com, that's T-O-P-T-A-L.com, and tell them Adam from the Genius Log sent you. All right, 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 know potential you know twitter replacements or you know facebook replacements like you mentioned diaspora i remember i recall identica i don't know what's what's still going on with identica um recently we've had mastodon there's people talking about scuttlebutt uh matt and reese has a new thing called micro blog there's yeah 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. 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. And 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 going to rise up that offers similar things I feel like it has to unlikely that something's going to rise up that offers similar things. It has to, I feel like it has to be a brand new thing to replace. And right now it's like, well, we don't want to wait for that brand new interaction, but we also want something that's open and federated.

And so you have this social web working group. Let's just kick back off there and tell us about what specifically the working group's working on and what's come of it. The working group has 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. Have they, you know, Evan liked Adam's post and Jared posted this text, right? So being able to describe in a JSON blob, you know, 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. So that similar to like the Facebook API or the Twitter API, you're able to build clients that not only do like basic posting and listing, but also can do some of the really creative stuff that we've seen in like the Twitter ecosystem and to some extent in the Facebook ecosystem. The third part and the third major deliverable is a federation protocol, right? And when we talk about federation, that means a server 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, that we can actually interact in a social way without having accounts on the same server. The same way that we use email or that we use

some other systems, telephone systems, right? 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. We've done a combination of those three things, the activity streams system, the activity pub. Activity pub 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 social. So MicroPub is kind of a slimmed-down version of ActivityPub. We have a system called WebMention, which is a very, it's like kind of a modernized pingback mechanism that does a very nice job of giving a federation experience. And so we're basically like doing a lot to put these things out there. But a lot of my work over the last couple of 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. So, and it's been a very successful process. We're really happy with the uptake 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 doesn't work. Like I'm going to write my own Adobe Illustrator and it's going to 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 a project because of that negative foundation. Like I hate Illustrator. I love whatever replacement I would use, Inkscape or something. right and so like none of us think of ruby as like oh yeah i hate c sharp i use ruby instead right like we think of ruby as something that's on its own that it isn't uh an anti-brand it isn't a negative space and i think that's not a social network oh yeah ruby is not a social network that's good observation jared well yeah that's. That's why they pay me the big bucks. But so can these open source social networks

take on a life of their own that isn't just about like getting off Twitter or getting off Facebook or sticking to the net? They all seem to rise from that though, right? Like it's something negative happened on a network and either harassment or racism or anything is happening on the network and it's not being policed well enough to a certain group's feelings and or whatnot. And they're like, let's,

let's move to somewhere else in hopes of having, you know, good things, better community. Right. Yeah. But for, for whatever reason, it never catches on because it takes critical mass or then you kind of wish that in your case like you're saying here you wish that network interrupted with you know let's just use twitter for example you know yeah exactly exactly and there's that and there's that feeling that like grandma's on facebook right like eventually i'm gonna have to go back and and say thanks for thanks for the happy birthday, grandma, right? Like there's that, like it pulls you back in because they do have that critical mass

of people. So I think that tools that integrate using the custom APIs of Facebook, Twitter, Instagram, et cetera, those are ones that are more successful. I think also one, so you can keep your existing networks without kind of giving them up. I think also ones that stimulate kind of hackerly instincts are also like really powerful, right?

The more that we have cool, you know, third-party clients, the more that we have cool hacks, games that integrate with a social network, et cetera, the more that we have cool hacks, games that integrate with a social network, et cetera, the more likely we're going to be to use that kind of thing. So that's the, and I think that it's really a, 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, you know, if you're like, there's no crueler fate than being a Twitter developer over the last 10 years, right? Like there's been so many ups and downs. And you know, one week, they're encouraging one thing for you to do and the next week they're saying that that's forbidden and they're going to turn off your api key right um same thing with facebook they've been definitely like back and forth on what they want to encourage people to do and not encourage people to do with uh open source networks and open standards it's like nobody can tell you what to do. If you want to, you know, build a competitor for the default Android client, like go ahead. No one's going to stop you. Right. And that's, that I think could be really powerful.

So like kind of getting outside of those big companies, main business models and saying like, we are going to build our own system that doesn't depend on that. How it sustain though i mean that's the one thing i wonder is i mean obviously facebook is one thing and it makes a lot of money so it's able to progress its network you know whereas with the wc3 uh obviously you have members and different corporate interests there how does you know how does the does the motivation remain? Somebody's got to 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 slash funding slash sustainability come from with this particular effort? Right. Yeah, absolutely. That's a really good question. Right. So like there is there's definitely, you know, different sources of who's going to pay. I think for like enterprise, a lot of enterprises have their own social network that they run internally, right? So they'll have a Jive or a Yammer or, you know, or they'll use a messaging system like Slack or HipChat, right? And so having something that's internal that they can also connect to partners and customers with is really powerful for them. And, you know, something that they own, they know where the data is, they're not, you know, they control the user accounts is very attractive for those enterprises. So we had a number of companies that participate in the social web working group because they think social for business is an important aspect. And for them, having multiple vendors, having a choice in terms of the software that they use is really important.

I think that there are a lot of, you know, people like us for whom like, you know, spinning up a digital ocean droplet and putting a Docker image up is like really, you know, easy. And we're like, oh yeah, it's a few bucks a month. Like, I don't mind doing that. But for the wider internet, you know, user community, if we could even say that, like. My aunt is not going to want to do that. I guess that's just people now, right?

Like there's no such thing as the internet community. It's just like humanity. They don't. Yeah, the world. They don't pay for, they don't world yeah the world they don't pay for they don't pay for the software right like they don't like asking them to pay for their social networking is not going to work right so it's going to be um i i think that in a federated world what happens is you probably have a mix of advertising based systems that uh you know 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, 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, I can start a new network and there 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 part of this federation. Right. Um, and so that is like, that 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 going to 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 and the protocol has to be independent, right? Like the ability to do so shouldn't, doesn't play to the same motivation for why you want to do it, right? So, you know, all these different components to it, the social web protocols, being able to and the motivation to do so are two different things. Like we have to give the web and the open web a standard for which to do so. Right. And that's, it seems like what this effort is, is less on like,

why would somebody want to do it, but more so how they should be able to do it. Yeah. Yeah, exactly. I think of like email is also a good model here and it's definitely a model to it. There are some like negative aspects to it too,

but like, you know, we have people who use free email systems like Gmail that are advertising supported and they're happy with that system. A lot of enterprises who are like, you have to use the company email for company business. And everyone knows that that's the way that works. As well as people who are like, hey, I'm just going to spin up my own mail server and use my own domain, right? And we have a, I think that we have a good mix of that on the internet.

There are definitely downsides to that too, right? It is really hard to run your own email server in 2017. It is an uphill battle, but still possible, which I'm glad about. I'm glad that it's still there. One of those things, it's one of those tasks that I do that I'm like, I just have to keep doing this. I have to keep doing this because I want to believe that it's possible, right? And yeah, and it's definitely an interesting fight. But, you know, so seeing that same kind of pattern in the social world is possible too. And again, with email, 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 email is the best success story to use because it's used globally by everybody. It's on open protocols, SMTP, POP and IMAP, and it's completely federated. I think a failure case, if you wanted to say what worked for email 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. Email was used by everybody. IRC never made it outside of hacker circles. And even amongst us, like, you know, most people of us are, we're on Slack, you know, because they provide overall a better experience. And so what, I'm not necessarily asking you to answer this, Evan, I'm just kind of throwing this out as a, as they thought is like, what worked for email? Why did email get traction and IRC never did? Or even remain. Not so much as traction, but remain.

Well, IRC's still out there, but it's not. Yeah, but so like there are a couple things in there. And obviously hindsight's 20-20, right? I don't know, but it's kind of easy to say, like looking back, but there are a couple of things that I think are interesting there about IRC. One thing about SMTP is like, it's super simple, right? The protocol is very simple, but extensible, right? And in a lot of ways, it's a little bit janky. Like if you start getting into some of the weird extensions, like it get really, really funky. But it has been this kind of layered thing that started with something simple,

and then we needed something else put on top of it, and so on and so on, right? Whereas IRC is just gigantic, like the protocol is really big to start off with and it's really complicated right and it maintains these uh live connections and so there's a lot of you know a lot of stuff that you have to do that's really um that's really kind of tricky so i think that's one thing is that um you know you mentioned uh pop imap and smtp um as well as like as well as the email message standard, MIME, the way that we do attachments. All of this together is one thing on top of the other. If you want to build email, you're going to 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 Slack bot. If you have any web programming skills, you can build one in an afternoon. Using the hook system is uh really fun and easy and uh and you can get some really fun behavior out of it whereas building an irc bot is like it takes a long time you have to have a live process that

maintains these connections and it's definitely a lot more complicated. So that third party developer experience where it's like, hey, I'd like to add a little, 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 is something that's really easy with a slack and hard with IRC not impossible but definitely not as fun right yeah email is somewhere in the middle right like so a lot of us build applications it's just like fire off email but doing things like mailbox management is is it's kind of a mess right like that's that that's not much fun. So it's kind of lies somewhere in the middle there. So like those are a couple of things,

like can you get that, can you get something that's like fun for hackers, right? Like look at this cool, funny thing I built, right? And like, and that's the kind of thing that just like, once you've got the hackers, then you've got their friends and, and friends and family coming on. Cause they love looking at that, at that stuff. Like how many of us use Twitter because of all the hilarious bots that are on there?

Right. Like that's a, that's a big part of a lot of people's Twitter experience. Right. most Twitter experience, right? And that is largely because they built an API early on that was fun and easy to use, right? You really don't need to know much about the Twitter API to be posting. And 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.

One other thing I'll add is even a more basic concern with regards to just going back to IRC versus email, why one took off, one didn't. Email appealed to humans at a level they already understood. So you already know how the mail system works. I'm talking conceptually now, not technically or anything like that. This is mail for your computer. And that's something that everyone was like, oh, okay, I get mail. This is internet mail? Okay, I'm going to get mail on my computer.

I'm just talking about human buy-in to the network, not just how it works in the federation. Because no one's like, oh, is it? 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 email account? They're thinking, is this going to provide value? Is this something I understand and can use?

Whereas IRC was very technically challenging, like you said. Very insider. And actually, when I was exposed to IRC as a young lad, I probably was like 16, 17, it was scary, weird. Just the whole interaction with IRC was something that not... Yeah, foreign. And it had a bit of a...

Even then, this is again, the late 90s. To me, at least, the way it was introduced to me, it had this underground, scary, forbidden fruit thing that to me was interesting. But to most people, they're like, keep me away. And so 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 is going to 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 the 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, you know, a lot of times we see a gap between like the user

and the thing that they want to get done. And, you know, we think of that gap as the user's fault, right? Like if someone says like, oh, I don't understand how to like use IRC, right? And it's like, oh, okay, this is what you have to do. Look for an IRC client for your platform on the web, right? Install it, then find the right network and then, you know, register a NIC and then do,

do, do, right? And it's like, and here are all these things that you have to do and hear all these steps. And they're like, I'm never going to do and and and hear all these steps and they're like i'm never going to do those things right versus versus having say a web-based experience like a slack where it's just like i go in i punch in my email address it sends me a link and boom i'm in the community i want to be in right and that's a and we tend to in the open source software community, think like you must be at least this tall to make it into this ride, right? Like 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, right? Nobody wants to be told that they're not good enough. And nobody's going to not do a task because you told them they're dumb. They're going to go find someone who says you're smart. And they're going to go find someone who says, here's the easy way to do that, right? And how many of us, I think things that we do, like having cut and pasteable curl outputs to Bash, curl shell scripts down and then output them through Bash and do an installation. Everybody knows it's the wrong thing to do and everybody has criticisms, but it's so easy, right? It's like one copy and paste, right?

And, you know, 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 it's the, and I think that it's really up to us rather than up to the users to, to close that gap. Yeah. Well, speaking of not using software and making things easier to, before we transition and go to a break and transition to the next topic, I want to ask this about a tweet you had about Mastodon, which is one of the most recent efforts to, to do a federated social network. And you put out 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. So I'm the one not using software. I'm a liar. Well, I'm sure he has more to say and I'm giving him a chance to say it right here. So like, 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. Give them the pitch of why ActivityPub should have been used and be the first steps. So first of all, there are Mastodon developers who are working on implementing ActivityPub right now. So 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 you know i think for me so like mastodon uh uses a protocol uh o status that like i was one of the main authors for right so like i it's not like it's a problem for me that they're using O status. The thing is, is like, oh, you know, they're so, they just started something new. They started this new project.

And like, we've been working on this great improvement over, you know, 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? Like, 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 mean, I love Macedon's beautiful system. And they're doing a lot there. I think it's, I take it more as a criticism myself, like, I wish that we had had the product there ready for them, for them to choose, right? Like,

and I think that that's the, that's my big disappointment. That said, I'm excited that they're picking it up. Canoe Social, Diaspora, Pump.io, we're seeing some really good movement in the activities pub space. I think that I've said also a lot of things about Federated Social Web that apply to Mastodon right like you can't you can't live forever being the anti-twitter right eventually it has to be something that's valuable in in and of itself uh supporting third party developers the honey the attractant but it can't be what keeps yeah yeah because people don't like they don't stay angry forever like they don't net's ploy at first was like you know we're not this thing

and that thing was twitter and that was what was supposed to attract and keep and it eventually you just posted to twitter and app.net and then it was like well why am i doing this but maybe you had longer conversations there was there was a small group of people who had a good experience there but in the end they just didn't stay. And Twitter does attract more people, the masses, the mainstream. So when more and more people are there, you can't deny the network's presence. So, I mean, I think that for people who are passionate about Mastodon, right? Like, what they need to be doing is, like, don't be the doomsayers. Like don't be the Cassandras. Don't

be bringing everybody down by saying like, you really shouldn't use Twitter. You really shouldn't use Facebook. Do like, you know, build a cool app that uses Mastodon, right? Build something really fun that's only on Mastodon. Like make a cool bot. Make a cool account. Make something that's fun and interesting there. Because that's how you get a community that's excited about being 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 talk through ways to add simple, intelligent responses to your apps that have a huge impact on the user's experience. Evan also makes a huge claim by calling data the new oil. It's required for machine learning engines, yet it's a scarce resource and one that not everyone has. All this after the break. This episode of The Change Log is brought to you by GoCD, an open-source continuous delivery server from our friends at ThoughtWorks.

GoCD lets you model complex workflows, promote trusted artifacts, see how your workflow really works, deploy any version, anytime, run and rock your tests, compare builds, take advantage of plugins and so much more. Check out GoCD.io slash ChangeLog to learn more. And now back to the show what's this next thing for you you got uh where you're at now is is in ai uh we've kind of shared evan's, so to speak, your history through the social networks, creating standards, and we're at a place now where AI is taking far more presence in things. You've got machine learning, you've got deep learning, you've got all these different sects 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 mentioned a number of different systems for doing AI. So 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 really interesting stuff happening.

There are downsides to those systems too, right? over the last few years. Like we've seen a lot of really interesting stuff happening. There are downsides to those systems too, right? Like to get a deep learning process going there, 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, et cetera, what kind of inputs you're putting in, you can get very different outputs, right? 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, right? that is a very, so 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, you know, this isn't your bet the company artificial intelligence. This isn't putting a brain under the hood of the car.

This is like, hey, maybe we could make our menu organization a little bit more adaptive for our end users. Maybe the emails that we send out could be a little bit more sensitive to their particular context, right? All those little experiences that we have with software, could we make them a little bit more intelligent? And 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 kind of assets to apply to improving web experiences. But we can do off with rules, you know, explicitly stated 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. So let me think of an example really quickly. Let's say that we were trying to do a system that sends an email to new web users after a few days,

just saying, like, how is it going? Is this working for you? And we want to know how many days out to send it, right? Do we send it one day? 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 email 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 as in the same language as I've just given, and use that to make the first decisions. And then based on whether people actually respond to the email, we can then say, oh, that worked. This person responded to the email, 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'll actually learn what input data actually maps well to the output data. And the reason that I like it is that I often want to put intelligence into my software. And I was getting really frustrated with these kind of moonshot machine learning processes. I was like, we're not going to dedicate six months of training and hiring and getting a data scientist on board just to decide when to send the emails out. But this is something that can actually optimize our business. And making those small optimizing changes are really important for any kind of online business. And they can have big payouts too.

Yeah, exactly. Making the user happy that quickly for using this as an example, that email as an example. I mean, you can really have a huge impact very quickly on a brand new user or whatever the case might be. Yeah, I mean, and that's's really the difference between frustrating a user

and delighting a user is 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 want to do this. Quit popping this up to me. Or I want to 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. And the apps that are very rigid and don't adapt to us, those are the ones we get frustrated

with and eventually stop using, right? That's the, you know, no one likes to feel like their software is framing them in. So the idea, again, with Fuzzy AI is like, can we build, 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? Will you use the email as an example?

Are there other examples that are perfect fits? Because obviously every intelligent response or every intelligence you require in software isn't perfect for fuzzy AI. So like, aside from the example here, what other good examples can you give that are just like, not dead 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. So, you know, I think, I'm only joking but that is a lot of things but you know we do like like that constant declaration is such a great example though because like how many times have like you sat there and been like wow i i wonder

how long we should wait for that email let's say seven days right like put it in there and then those things stick around in your code forever right and it's like well you know that's just based on my guess i made on a tuesday before the software had to ship right like it's not it doesn't have anything to do with the reality of the world um and uh so you know know, 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, right? 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? So those are a couple of things. We also use them for things like when do you show a pop-up? If you show a pop-up, like 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, right? Like people might not like it. Or you could pop up exactly what they need and want, and you've just added like $10 or $100 to your sale, right? So knowing when to do that the right way is really important. So those are a couple of things.

I think another thing that's been really interesting for us is the growth of chatbots. And 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, right? Like 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, right?

Like it should learn eventually that I really like pineapple and it should learn, I don't like pineapple, by the way. I way prefer anchovies. I probably should switch that around. 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.

And so taking the initial assumptions of your software and exposing them to a testing environment, you know, in a lot of the ways that we do with like 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. You know, this may be in the future, we do different things, but, you know, 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.

And so it sounds like this is a perfect kind of tool for user experience designers, marketers, people who want to make wiser choices on things they want to do, but not do for every single user type. And so extending from that, is the UI for training it? Is it easy to use? How does that work?

Yeah, so we have a developer environment. I think that for me, the user experience had to be really good because we were looking for something. 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. So we really lucked out. 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. While you're talking about your team real quick, we also tell you James Walker is a longtime community member and a friend of ours. That's another person about your team real quick, I will also tell you, James Walker is a long-time community member and a friend of ours, so that's another person on your team. In fact, I didn't realize Fuzzy AI, on the About page, you've got five folks, so just getting started. Small team. I remember asking James, do you know Evan Protermo? Because we're going to interview him.

He's like, yeah, I know Evan. I was like, of course. Hi, James. Yeah, so, you know, getting James on was just fantastic. James is one of the most versatile developers I've worked with, like very smart, very quick, very quick at, like, learning new things, really thorough, like I've really, he's someone, we worked together on StatusNet too. And so when I started Fuzzy AI, I was like, I know one person I need to kind of 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. I hope you cut all that out because it's going to blow his head up. No, we're leaving you there. 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 rules-based system. So you can kind of put together your inputs and your outputs, and you 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. Don't show it to me, man.

You wouldn't want to show it to the Jarets. I'm the guy that you don't want to ever pop up anything on me. I'm just going to get mad. And there's some people who are like, thank you for sharing that you have an email list, i can extend my experience that's what i mean like there's there's a flip side that you know it takes a human touch to figure it out but if you can train a fuzzy kind of thing in this case right do the classification as you mentioned your 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, like that's a huge gap being missed. Yeah, yeah. And I think it's like, you know, I think it's an exciting part of, you know, it's not the entire AI ecosystem, right? It's not everything that's happening in AI. But like any software ecosystem, like it's going to be, I think that there's going to be a lot of different players. Like there's

going to be a lot of different things going on there. And for every like, you know, exciting AlphaGo, right? Like that is pretty amazing. Like it's pretty amazing that the that those systems work um i think that we all have to understand that there are going to be lots of sharp edges that we will buff off using ai right and it's going to make using software a lot better like we're all going to enjoy it a lot more it's going to be something that we're going to actually like be looking forward to. And we've done a lot of work on this over the last 10 or 20 years to the point that people are almost in this addictive behavior with their software. But I think that there's going to 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 a commercial operation, so to speak, with potentially no open source aside from SDK. 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. 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, a lot of our stack is open source. So we publish a lot of what we do either out through GitHub or through NPM. But there are some parts that aren't, like 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, right? So if we had someone go and install StatusNet on their own servers, and we helped make that easier, it was helping the company. I think that if we were to take our engine out

and have people integrated into their own stuff, like we would probably need to support that. And the question then becomes like, you know, what would that, what would supporting that look like? Right. And whether we would be able to do it. And I also think that like in a connected world, um, does it matter for them? Right. Like does our kind of, does the kind of customer that we're, that we're using, are they going to benefit from taking our 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 going to 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. 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 going to 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. And how that happens is, it's kind of up to us. And 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 earlier was the moonshot AI method,ologies like deep learning and machine learning. These things that admittedly requires, like you said, an operations team at this point, historical data, lots of effort. Big investment. Yeah, 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. We did a show maybe a year ago now, Adam, with Eli Bixby about TensorFlow. 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, having the data, a lot of steps.

But even since then, they've made some moves where certain of their models are available as a service or publicly available things. And so what I think, I think you're fitting into a great little niche here in between the moonshot and nothing. I see huge value there. And my question is, long term, are you afraid of getting squeezed out as those don't become moonshots 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, 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, right? Like it's getting a lot easier. But the thing for me, like the big thing, one of my friends, Alistair Kroll, says data is the new oil. It is the thing that you have personally and being able to encode that into an AI system. I think that that's going to be a very competitive part of the AI ecosystem no matter what happens. So we have customers that use like Amazon's ML or they use TensorFlow on Google system as well as fuzzy AI, right?

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, I mean, like, you know, you talk about like some of those moonshots, like for me, like you see these like 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 up front who are tuning the network just to make it go.

That's the self-driving car of 2017 and uh for me there's like i would really like it if my windshield wipers turned on and off based on whether it's raining or not right like i don't need i i don't want to have to switch from like fast to slow on my windshield wipers every time it like starts squeaking um i would like that to be automated right oh wow i didn't even think about that you just totally ruined it for me now. Oh, I'm sorry about that. I'm going to think to myself, why am I adjusting this thing again? 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. And so I think that for those of us who create software, like thinking about how can we make those little experiences better through intelligence and that's where we think Fuzzy AI fits in. And I don't think we're the only one that's going to be in there.

I think there's going to be a lot of different options in there. We just want to be one of the things, one of the tools that people have to do that, right? Like there's got to be a spectrum. And, you know, different times, 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 future prediction for you before we close here. My daughter, my oldest daughter is nine. When she turns 16, is she going to have to

learn how to drive or not? What do you think? Oh, man. You're asking me to predict. Yeah. She's nine. That's seven years. Seven years. I would say it's an elective at that point.

Seven years. Yeah. How do you feel, Evan? You think that's about right? On the moonshot 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. So if you're someone who loves cars, you're going to be like, yeah, I totally want to drive. That's going to be a personal choice right so if you're someone who loves cars you're going to be like yeah i totally want to drive right like that's going to be something i'd like to do um

but i think by that point you're going to be able to say like i don't need to i can let i i can let the car drive yeah i hope you're right yeah yeah i don't ever want her to have to drive a car well yeah it's been a blast blast kind of diving back into your history and pontificating about the future of AI and then what you're doing here on the micro sides 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, right?

And how do you create a good user experience? One small win at a time. So I think that this conversation certainly enlightened me. And thanks for coming on, man. Well, thank you guys so much. I think I told you before we started, I'm a big fan of the 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. So thank you. All right, that's it for this week's episode of The Change Log. We love talking to people like Evan who make the community awesome, make it thrive.

If you enjoyed the show, share it with a friend, rate us on iTunes, help us spread the word about the show. Thanks to our sponsors, Linode, Top Tile, and GoCD. Also, thanks to Fastly, our bandwidth partner. Head to fastly.com to learn more. We host everything we do on Linode servers. Head to Linode.com slash changelog. Check them out. Support the show.

This show is hosted by myself, Adam Stachowiak, and Jared Santo. It's edited by Jonathan Youngblood. And the awesome music you've been hearing is produced by the mysterious Breakmaster Cylinder. You can find more episodes just like this at changelog.com or by subscribing wherever you get your podcasts. Thanks for listening.