The Changelog: Software Development, Open Source - Boldly going where no data tools have gone before (Interview)

Episode Date: June 19, 2019

Computer Scientist Yaw Anokwa joins the show to tell us how Open Data Kit is enabling data collection efforts around the world. From monitoring rainforests to observing elections to tracking outbreaks, ODK has done it all. We hear its origin story, ruminate on why it's been so successful, learn how the software works, and even answer the question, "are people really using it in space?!" All that and more...

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash Changelog. This episode is brought to you by DigitalOcean. DigitalOcean makes it super simple to launch a Kubernetes cluster in minutes. The DigitalOcean Kubernetes platform empowers developers to launch their containerized applications

into a managed, production-ready cluster without having to maintain or configure the underlying infrastructure. They seamlessly integrate everything with the rest of the DigitalOcean stack, including load balancers, firewalls, object storage spaces, and block storage volumes. They even have built-in support for public and private image registries like Docker Hub and Quay.io. Developers can now run and scale container-based workloads

with ease with the DigitalOcean platform. Learn more and get started for free with a $50 credit at do.co.changelog. Again, do.co.changelog. All right. Welcome back, everyone, to The Changelog, a podcast featuring the hackers, leaders, and innovators of software development. I'm Jared Santo, Managing Editor here at Changelog. Today, computer scientist Yao Anakwa joins the show to tell us how Open Data Kit is enabling data collection efforts around the world. From monitoring rainforests to observing elections to tracking outbreaks, ODK has done it all. We hear its origin story, ruminate on why it's been so successful, learn how the software works, and even answer the question, are people really using it in space?

All that and more coming right at you. There's probably a thousand ways you can use a computer science degree, right? And being in school so long to get a PhD in computer science must be just a life's journey, right? But I'm sure you've got some extreme opinions on how to best use a computer science degree in these ages. Yeah, I have some thoughts on that. I was in school for a very long time and sort of early in that PhD journey, I like to say, I sort of had a moment where I realized that the stuff that I was working on didn't really, you know, it didn't really matter to people. It didn't seem to have a meaningful impact. It was just like a fun thing

to do. So during that period, I got a chance to travel to some places in rural Africa where I saw how technology could really make a difference. And that really moved me to sort of stop working on stuff that didn't really matter to people and start focusing all the time and energy and school and education on stuff that I thought could really make a difference today to people who needed it. And so I think there's always going to be like lots of people who are working on ad targeting or some of the stuff that big tech companies work on. But I feel a real strong passion for, you know, using technology to help folks who need help.

And so I've dedicated, I guess, most of my graduate career and postgraduate career to working on that problem. Give us an idea of your journey in school. Like just what's required to get a PhD in computer science? Stubbornness. Tenacity. Resilience. Yeah, all those things.

So I have sort of a strange entry into computing. I'm originally from Ghana in West Africa, and I moved to the States when I was about 10, because my dad got a job teaching at Butler University. And I remember coming to the States for the first time, walking into my dad's house, and seeing

a little math SE. And I remember my dad saying, like, don't touch that. And yeah, naturally, I spent pretty much every waking hour I had playing with that computer. Just when I was on a college campus, I got a chance to just, like, go to the library to have old Vax terminals there and play with those. And so I was pretty in love with computing from a pretty young age. I ended up going to Butler University and got a bachelor's in computer science and another in electrical engineering to do both simultaneously.

There's a special program there that you can do both. I went on to do a master's in computer science from UW, University of Washington in Seattle. And during that process, it was sort of when I had this come to Jesus moment about working on meaningful problems. To sort of answer the core question, what does it take to get a computer scientist? I mean, I really think, obviously, you have to have some minimum threshold of interest in computing and be reasonable at math. And then the rest is being fortunate enough to have a good advisor who can guide you. And then, well, stubbornness. I think that's's really the key you might have a interesting opinion on this a little while back episode 339 we had adam bar on the changelog he's a 23 year microsoft vet wrote a

book recently called why smart engineers write bad code and it was critical of academia with regards to computer science specifically. And his reasoning is because he says in his experience working with a lot of schools that during a computer science, and this might be just a bachelor's degree, they do not have the necessary scope requirements, like the depth of the systems that are built, just because of the time involvement because the curriculum and these other things aren't real world enough to actually get you what you need once you get out there you've been you've been in academia for a long time do

you does that resonate with you or do you find that maybe does not or what are your thoughts yeah so um i have been in academia for a long time and my wife is also a programmer and she taught the University of Washington, the intro classes as well. And so, yeah, I have some pretty strong opinions. You know, for me, the goal of a particularly a computer science degree isn't, it's not a trade school. You know, the goal isn't to teach you how to be a good programmer. The goal is to teach you about computing and how to use computing

to solve problems. And so the focus shouldn't necessarily be on languages, it should be more on algorithms, decomposing problems, having sort of the fundamentals that you need to learn different types of programming languages, getting exposure to that. And then the hope is that once you start, once you start getting into the world at large, you have the sort of the basic skills needed to actually build systems and learn rapidly. So that to me is like at the bachelor's level,

what you should be learning at the master's and PhD level, you know, the goal isn't, it's just to come up with a new idea and evaluate that idea on some particular dimension. You will find a lot of PhDs in computer science aren't necessarily good at programming, but they are very good at solving, you know, that class of problem where there's a new problem, a new way of of thinking and they've measured it in some way they've done science on it yeah i mean i think boot camps are more like what um if you want a sort of a more trade approach where you get a bunch of skills that's where you get get that but for me computer science degree bachelor's level it's really about a set of skills you know

a way to think about computing yeah so somebody came up to you today in 2019 and said i want to be a software engineer would you advise them to start in a trade situation start with a boot camp and then backfill perhaps the fundamentals later with a bachelor's degree if they want or would you say go to a four-year college? I'm just curious what your advice would be. Maybe I'm old-fashioned. I'm an academic. My wife's an academic.

My parents are academics. So I would say definitely a four-year degree. For me, it's not just the idea of just getting the skills needed to become a good software engineer. It's also about, you know, I went to a liberal arts school for undergrad. It's also about getting exposure to different parts of the world, you know, language, music, religion, and all of those influence the kind of work that you do.

You know, in my particular case, my dad's a journalist. And so I spent most of my undergrad building an online newspaper. And I learned a lot from that experience. And that informs the kind of programmer and software engineer that I am today. So I think just a strict focus on, you know, acquiring a particular set of skills, it lacks some of the richness that I think a four-year degree potentially gets you.

I think we need that versatility in our education. So you mentioned that many computer science PhDs aren't necessarily good programmers. Would you consider yourself a good programmer today? I would not consider myself a good programmer today. Why not? Why not? One is practice. These days, I don't spend a lot of time writing code.

I'm sort of doing a lot of everything from marketing, fundraising, to community management, thinking about governance. And so day to day, what I mostly do is write emails and think about writing emails write those emails, fill up on those emails. Yeah, that's where I spend most of my time. And really at the end of the day it's like communicating with folks making sure everybody's on the right page and making sure that everyone

in the community, at the company we're all sort of moving in the right direction. It's probably bad for the project if I'm writing code. I guess it means other high-level stuff isn't getting done. Let's turn our focus to the project. We want to hear about how it started. It's called

Open Data Kit, or ODK for short, and I should mention up front here that I would not have heard of this were it not for Brett Neese in our ping repo. So thanks, Brett. And I just thought I'd read what he said was interesting about it, but we want to hear the history of this were it not for Brett Neese in our ping repo so thanks Brett and I just thought I'd read what he said was interesting about it but we want to hear the history of this

before you bring us up to like present day what that community looks like and everything and he says to him what's interesting about ODK is that it's using a lot of different environments than some of the software that we talk about commonly on the changelog he says it's similar to Singularity in that way.

You guys can go back and listen to that Singularity episode if you want another different thing. And he says it seems to target a more academic audience, which makes sense talking to you, Yao. It's used anything from monitoring rainforests in the Amazon to observing elections in Albania to tackling Ebola in West Africa. Brett personally uses it in an engineering firm where he maintains an ODK server to collect data from telephone pole inspections.

So pretty much data collection is what it's about, hence the name Open Data Kit. And really, it seems to be about bringing data collection capabilities to places where it previously wasn't or couldn't be for various reasons. So thanks, Brett, for bringing this to our attention. And we hope you enjoyed this conversation. You were right. This is very interesting.

And Yao has a very interesting backstory on how this whole thing came to be. So Yao, tell us about that. Open Data Kit was part of your work at your university. And it's still going today. So very valuable. How did it start? Yeah, I could talk a little bit about that. So I moved to Seattle in 2005.

I was accepted to a PhD program at the University of Washington in Seattle. And I went there, actually, I was going to study AI. And I sort of, I abandoned that notion pretty quickly, mostly because I found I had a great relationship with a professor there, Gaetano Borriello, who really sparked my interest in, at that time, it's called ubiquitous computing, this idea that you can have computing everywhere and human-computer interaction, human interfaces to these computers. And so I started working with Gaetano. And during probably my second year, I saw a talk at UW from a guy called Nilesh, who

was at that time sort of a wandering guru. You know, he'd walk, he'd travel from place to place, primarily in sub-Saharan Africa, and help hospitals or whomever needed help with whatever computing problems that they had. And that really sort of inspired me. I was going through a time in my life where I felt like the stuff that I was doing didn't really have a broader impact.

And it seemed like, you know, all this education for not a lot of value to the population at large. And so I got a chance, after listening to Neil, I got a chance to sort of put a pause on my master's degree at that time and go to Rwanda to work with a group called Partners in Health. And at that time, they were deploying a medical record system, an open source medical record system called OpenMRS. And so they were doing it in a small town in rural Rwanda. And I saw during those, I think, six months that I was there,

how important an electronic medical record system could be to treating HIV and TB patients. A lot of chronic care like HIV and TB is done on paper, and paper really sort of limits how effective you can be at treating those patients. It's not like malaria where you get treated once and go away. It's like every, you know, every few weeks, every few months, you're at the hospital. So electronics definitely helps. Electronic medical records definitely helps. And so I saw that experience and I learned from it and I saw how important paper was to the process and how critical electronic medical records could be to sort of reduce

medical disease. And so I kept sort of wandering Africa at the time and Gaetano sort of summoned me back to Seattle and said, you know, you've been wanting for a while. And he was going to take a sabbatical from UW to go to Google to work on a mobile data collection project. This was right before Android was released. And so Gaetano had this idea that a lot of his students were sort of working in this technology for development space and that the common themes seem to be moving sort of paper and digitizing processes. So I thought this idea was terrible, to be honest. I was like, I don't really, yeah, I was like, I'd rather just bum around Tanzania for a little bit. I don't really want to be back in Seattle and working on this stuff. But Gaetano and his students,

a friend of mine, Carl Hartung and William Burnett, sort of convinced me that it was worthwhile. So the three of us went to Google as interns for a year and built out what became initially Open Data Kit. And we did it open source from day one because we are, you know, we're researchers and grad students and we thought it was really important to make it open source available to as many people who wanted to do research on it. And at that time, Android just came out. We released the first version of ODK

as soon as Android was publicly released. And actually, funny story, we took, at that time, there were the Sidekick-style devices. Those initial devices, we took 20 of them. I think Carl and myself were the first people to bring Android devices to the entire continent of Africa because we're not released yet. We stuck them in bags and took them to Uganda to do a quick project. And that's what kicked off the project. So that was in 2008. From there, you know to sort of become the standard tool,

a set of tools that folks use when they're collecting data in sort of a field environment. And it all sort of started from that project we started when we were interns. Over a decade ago now. Yeah, it's crazy, right? The timing seemed perfect with Android coming out and the timing with regards with android coming out and the the timing it with

regards to cutting over from paper to smartphones and tablets because now all of a sudden smartphones were available i mean the iphone predated android but it wasn't going to reach into the same places that open data kit wants us to reach into yeah Yeah, and that's one of the great insights of Gaetano was that he saw that this was really a good chance to be on a platform that worked on a number of different devices. You have to remember we're coming from G2ME and BlackBerrys at that time. And so the smartphone was really a powerful platform

where we can build a whole new generation of applications. And because Android was designed to work on a bunch of different hardware from a bunch of different manufacturers, we thought it was going to be really important that the places that we want to serve, you know, Sub-Saharan Africa, you know, remote jungles, that a variety of devices was really important.

And so that kind of was able to convince at that time Andy Rubin, who was running the Android team, this was a worthwhile thing to try, and so he funded us for able to convince at that time Andy Rubin who was running the Android team this was a worthwhile thing to try and so he funded us for that and you know it seems to have worked out very nicely So when we talk about impact

ODK has been used now by thousands of organizations such as the Gates Foundation USAID, World Health Organization, Jane Goodall Institutes collected billions of data points. Could you give us a few highlights, maybe things personally that you've felt good about it being used for out there in the world, helping people? Yeah, there are a number of these kinds of projects.

So just literally two hours ago, we've got a word from the London School of Hygiene and Tropical Medicine. These are the folks who are currently working with the War Health Organization and the Democratic Republic of Congo. So there's currently an Ebola outbreak that's happening in the DRC. I think there's been about 2,000 people infected currently. So in the first 300 or so days of the outbreak, this is the second outbreak that's happened. And so there's been a vaccine that has been created that is going through a set of trials. So I think about 135,000 people have been vaccinated as part of that effort. And the documentation about that vaccine, who's gotten the vaccine, when and where and how much, that's all collected using ODK. And so there's been about, I think, 1 million submissions just from this outbreak alone that have come through ODK

because of the tools that we've built. So that's an example. Throughout another health example, one of my favorites is polio eradication. And so from WHO, World Health Organization's polio eradication efforts from Afghanistan, Pakistan, Somalia, all those vaccination campaigns, when they go out and they vaccinate, you know, hundreds of thousands of millions of kids, the documentation about that vaccination is all done through O.D.K. The Jane Goodall Institute, when they're tracking conservation efforts in Tanzania, they use O.D.K. The Carter Center, Jimmy Carter cried out O.D.K. and he said it was remarkable. That's where my favorite starts. All the recent elections in Egypt and all these places,

all that documentation is done through ODK. The tribes in the Amazon who protect their forests by documenting illegal logging, that's done through ODK. So everything from, there was an election in Albania, like last year, the monitoring was done. So everything from healthcare, climate monitoring, I know the Portland bus public transit people, they do their surveys throughout the day. They have this sort of wide, the tools have this wide usage where, you know, anytime that

you have essentially a piece of paper and you want to collect data on that piece of paper, but you want it to work offline and you want it to have logic and you want it to have GPS coordinates or pictures. Anytime you have this process where you ordinarily collect data on paper, you can use ODK. And so I think over the last 10 to 12 years, I's a project on the space station that uses it. So I mean, we've seen it pretty much everywhere. It's really humbling. Did you know there was an engineering firm out there using it to collect data from telephone pole inspections?

Yes, I did, but I'm not surprised. One of the real challenges of this open source in this way is that we don't really have a lot of visibility. By design, we don't have a lot of visibility into who uses it. We don't want people to own the data. So the telephone pole example is not, it doesn't surprise me anymore. I got an email from a manufacturing firm, I think in China, that makes the chairs, the seats for Teslas. They use ODK.

So it just seems to be ubiquitous now, but nothing surprised me anymore. I was at a dinner party, said what I was doing, and somebody said, oh yeah, I use that. So yeah, it's pretty cool. One of the points for software is to be adopted, right? One of the bigger hurdles of open source is to be adopted, to be widely used. What do you think for ODK was that? Was it simply the need? Was it being open source?

Was it phenomenal marketing? What do you think made it be used so widely? I mean, I don't know about phenomenal marketing. I don't think marketing is that phenomenal. It's mostly me tweeting sometimes. So I think the important thing that allowed us to take off is luck, basically luck and timing. So it was at a stage where Android was just coming out. We had folks who were stopping use of PDAs and data-based phones when they're looking for alternatives. And technology infrastructure in the places that we work, particularly,

you're getting more smartphone and cellular infrastructure in Sub-Saharan Africa that took off. And then, you know, we were, the core team, we're very committed to supporting our users. And so I think for a long time for the project before it really got big, if somebody sends an email out to the ODK mailing list, somebody generally, often me, you get a response in, you know, under an hour. And so being able to support people who are using this piece of software was a big sort of growth driver. And then the other thing is,

I don't think open source matters as much in this use case, but free matters a lot. And so, for example, if you are, let's say you are at the Red Cross and there is, you know, this happened. This was in Mozambique. There was a hurricane, a cyclone, and you need to go out and hand out supplies and document what supplies you're handing out to people.

You're not going to be able to get a credit card. You know, the country office doesn't have a credit card because it's Mozambique. By the time you get through the approval process at Red Cross in DC or in Geneva, the crisis has magnified to the point where it's no longer tenable. So the fact that you can download it and use it for $0 is huge. If it was $1, the adoption wouldn't necessarily be there. But I think the free is an important thing. The fact that it's open source also means that people don't feel locked in.

So oftentimes we work, you know, we have projects with large governments and governments don't want to use, you know, a sales force or something where their data is trapped in services they don't control by companies that they have no jurisdiction over. And so for very large health projects, say in Kenya or in Nigeria, the fact that it's open source makes a huge difference. So I think those are the things that played up,

you know, it's luck and timing, but the fact that it's free and that folks who deploy it have ownership of their data and their infrastructure is really, I think it's a good part of it. This episode is brought to you by GoCD. With native integrations for Kubernetes and a Helm chart to quickly get started, GoCD is an easy choice for cloud-native teams. With GoCD running on Kubernetes, you define your build workflow and let GoCD provision and scale build infrastructure on the fly for you.

GoCD installs as a Kubernetes native application, which allows for ease of operations, easily and maintain go CD using helm scale your build infrastructure elastically with a new elastic agent that uses kubernetes conventions to dynamically scale go see the agents go CD also has first class integration with docker registries easily compose track and visualize deployments on Kubernetes. Learn more and get started at gocd.org slash Kubernetes. Again, gocd.org slash Kubernetes. so free software is nice well-timed software is nice there's lots of like you said luck's always nice as well there's lots of ways that you can get to that ubiquity but you also can't get there

the software doesn't deliver on its promises and so one thing i read is that you you all had some early goals for ODK, and it seems like you achieved them at least to a certain degree, enough that people wanted to keep using the software. And those goals were you wanted it to be easy to try, easy to use, easy to modify, and easy to scale. So the key word there being easy. Curious how that came out and whether you felt you achieved it early on

or today talk about these goals of yours yeah i think it's pretty punchy right nice clever yeah clever uh marketing there did you backfit that one or was it would you write it on day one i think i i think maybe day two or day three i I was in charge of marketing back then. There you go. Did you tweet that one? There was no Twitter, I think. So I think it's in some as an English repository. From my perspective, and I think early founder perspective is that a lot of the folks that

we were working with in the very early days didn't necessarily have technical expertise. So the sort of user that we're dealing with is, you know, maybe a health organization who doesn't have a lot of funding. The people who are going out to collect the data are maybe a subsistence farmer who hasn't at that time seen a smartphone before. And so you're given, I think at that time, the initial devices were $600. We're giving $600 devices to folks who don't have any experience with smartphones. And some of the early problems that we're running into are, for example, I don't know if this is a podcast, but you should look at your hands. And if you feel your fingertips, they're like these soft, squishy fingers. And those work really, really well on smartphones because you don't have any calluses.

If you do have calluses, if you work on a farm every day, your fingers don't really, they don't work on touch screens the same way. And so probably they have contact glasses. Most of our early users didn't have correct vision. And so that's sort of the user base that we're working with. Organizations that don't have a lot of technical capacity, users that aren't very technically experienced. And so easy was the only way that we could ensure that folks would use the tool. And so we spent a lot of time and continue to spend a lot of time in the field working with folks, just watching how they use the software, making those adjustments. So easy to use means that, you know, the average country office or the average person who's

doing the survey can design the surveys and get them onto the device. And enumerators, what we call it, we'll call it the data. An enumerator can take the tool with a very little amount of training and can go out and collect data. So that's sort of the, you know, easy to use, easy to try part. The scale is really critical because a lot of these projects, once they get going, they generate a ton of momentum. You know, I think at this point, if I look at sort of the mobile app,

over the last year, we've had about two and a half million users use it. And a lot of those users are in Nigeria or India. And so these projects collect, you know, they start very small, but they scale up really rapidly. You know, where they have thousands of people out in the field collecting, you know, tens of forms a day. And so it just gets really big really quickly. So we want to make sure that the software, while it is easy to try, that once you ramp up and once you go to scale from your pilot,

it just kind of keeps working. And then modification is also really important because we can't predict everything. And so we never wanted, especially since we were just grad students working on another kind of very small project, we didn't want to be the blocker on some large project or some small project. And that if you wanted to take the software and it wasn't doing what you wanted, you could just take it and just modify it how you see fit to get your work done.

And all these things have come, you know, it's been good and bad. You know, it's been good in the sense that our focus on ease of use with a little bit of flexibility has gotten the software to really get out there. A lot of people use it, but it also makes maintenance, maintaining and evolving it also a nightmare many times there's an old skcd comic where there's a guy who's fixed a bug and you know a user complains that you know this bug is like critical to my my use case i think the bug is something like you know my fans go up to 100 and um and so i fix this bug performance is back down to normal the fans don't pick up anymore and And then somebody writes and says like, oh, you know, this fan, I use like a temperature sensor on my computer to like run this command in Emax.

And so you've broken my workflow, just add a preference. So a lot of ODKs like that, they're stuff that you may think are easy to modify and easy to scale and all this, but the process of maintaining and evolving the software is kind of a fighter, but that's just software, I guess. Yeah, especially valuable software. The more valuable it is, the harder it is to change over time

because the more people are using it, you have more people using it in places where you didn't expect or rely, like you said, they rely on that bug. Hey, I needed that bug. I would imagine, too, that you have some issues potentially because you've got people that are using these devices that may be learning as they go. And it might even be, I'm assuming it might even be kind of hard to get the bug report, so to speak, from the actual user. Yeah, it's a really, it's a very insightful comment because our sort of the person who

touches the software, you know, we have this active community forum with about 9,000 people on it, which is great. And most of these folks on the forum aren't numerators or people collecting the data. And so when we roll out a software update, we know it's going to devices that people are in situations that sometimes are life-threatening.

There are situations where the employee will be there once to collect data. It's sort of a one-shot thing. But they're just using the software. They're not technical experts. And so it's rare that we get a bug report from a user. Our bug reports come through either great logging and betas, and also just being super, super careful about incrementally rolling out things. So we get a chance to gather feedback from folks wherever they are. Yeah, we don't often get bug reports from users. We get stack traces when there's a crash and try to have long betas. We try to get people to try to think out what rules out the population.

Yeah, they're both tough problems. So let's dig into the software itself for a little while here. I think, I'm sure it's changed over time. It sounds like now you have two sets of suites, ODK, which is for the common case, and then ODKX for complex workflows. Maybe we can talk about ODKX a little bit later. But ODK itself also seems to have at least two parts.

Maybe there's more now, but I started off as the collect side, which I assume is the Android app, the data gathering piece. And then there's the aggregate side, which is some sort of service, a storage management thing. That's as well as I understand them right now, uh, unpack that for us and then help us understand how, cause I get the collection and I get the aggregation, but then also how are the surveys themselves defined and designed by your enumerators? Yeah, for sure. So, um, so, uh, because the project has evolved over time, now there are sort of two suites.

There's ODK, which is sort of the classic ODK that everybody knows. And then there's ODKX, which is not really competitive, but it's like a different take on the data collection problem. And so there's tradeoffs as far as complexity and ease of use of power. So I'm going to focus on sort of the core ODK tools that I think most people know. And those are the ones that are just like really widely deployed. So the reason it's called Open Data Kit, and the kit is really important is because it's a series of tools that all sort of plug and play to let you collect and manage your data. And so there's ODK Collect, which is the mobile app, and that essentially renders forms that you collect data.

There's ODK aggregate, which is a server, a Java-based server that runs either locally or in the cloud. We also have ODK central, which is another server, but different stack. We have ODK build, which is a form designer. And then we also have ODK sort of XLS form, which is another form designer. So probably the easiest way to explain this is to sort of walk you through the process of what it takes to sort of get an ODK campaign up and running. So let's say you have a paper form with three questions, name, age, and gender, maybe a GPS location. The way you would get this form sort of designed is that you use a tool like ODK build, which lets you sort of drag and drop questions into a web interface. And once that questionnaire is essentially designed, you get published and it goes to your ODK aggregate server.

And so once that form is on the server, the server takes that form and uses it to build a database backend with all the tables that you need. You connect ODK collect your mobile client to the aggregate server and it pulls down the form, renders it on the device, you can go out, you can collect your data. When you're ready, you hit submit and then that data goes back to aggregate. So you use build to design the form, aggregate to host the form and the submissions, and collect to collect the data. So that's a very typical use case. Because we have a kit, there's other ways of doing it.

So if you don't like a drag-and-drop form designer, we have an Excel-based form designer that's extremely popular, probably the most popular way that people design forms, called ODK-XLS form. And so essentially, each row in your spreadsheet is a question that somebody is going to ask or receive. If you don't like aggregate, which is a Java, robust but pretty heavy Java-based server, we have ODK-Central, which is another server that's built primarily JavaScript-based. And so people can pick and choose which tools work best

for their scale or their users. But fundamentally, you design a form, you put it on a server, and then the phone talks to the server to send those submissions. One important thing to stress in all of this and the real the value add of ODK was a bunch of value adds, but the big one is that it's all offline. So ODK, you know, people think of forms, they think of maybe SurveyMonkey or something like that, Wufoo. ODK is designed to run entirely offline. The forms can be designed offline. You can collect your data offline. You can go out, you have folks in the rainforest, you can be out for months at a time, collect all your data. It can opportunistically send data to the server when it gets it, but it's all designed to

be offline. It's also designed to work really well with the UI, sort of designed to work well with lightly trained users. You'll probably have seen smartphones before. Everything is big, high contrast. It's designed to work in multiple languages. So the mobile client, for example, is translated by our community to 56 languages, last I checked. So you can have the app itself that's translated into different languages. And then the forms themselves that are on the app can be in different languages. So you can have a phone that's configured, all the menus are in French. And then you can open up that survey and toggle that survey between French, Japanese, Swahili.

You can even have an emoji font. You don't need to have text to describe the forms. For example, you can have video or audio instead of like question text. And this is really important for our users who may not be literate. So you can essentially have a survey where it's just a series of videos that are showing the person what kind of information you want to collect. So it ends up being, again, you know, it's like SurveyMonkey, but like crazy powerful and all working offline. So hopefully that should give you a sense. You build a form, you get it on the server, and then you collect the data.

But, you know, it's more powerful than that. I'd be curious, is there any way of printing a form and then ingesting it via OCR or something later? Because that would be the ultimate and going into the far reaches is you don't need batteries, you don't need a device at all, but you could just like scan the answers later. Yeah, so there it's a great idea. So the way we actually handle the battery problem is interesting, because because we're on Android, we run on a bunch of different devices so we have this point 14 000 different devices that we run on and some of those are uh there's tvs we run on tvs if you want to take a tv out into the field to collect data we can we support that but there's also a lot of low power devices like um uh e-readers that the data collection works on

you can handle batteries that way. The variety of devices also lets us handle different use cases. So I'm talking about Amazon Rainforest. But there's places with heavy canopy where you need an external GPS and a device that is extremely humidity-proof. And so we run on those devices as well. As far as being able to do OCR, we do have some sort of researchy apps. One's called ODK Scan that does exactly that, where you can essentially annotate a sheet of paper, collect the data that way, and feed it into the app.

It's not as widely deployed as the rest of the other tools. That's really cool. I love that it runs on e-readers. That's neat. And I mean, TV runs on e-readers. That's neat. And I mean, TV just seems like kind of ridiculous, but okay. It's ridiculous, but it turns out it's great for training. So if you are at some ministry of health and you don't have a device there, but you have an Android enabled TV, you can just go to the Play Store, download the app, and you

can walk through some complex forms and really show folks what the app looks like and how it works. So you never know. Yeah, you never know. What's deployment like to all the different devices? How do they get the forms? Yeah, so there's a couple of ways of doing that.

So I would say, let's take a small deployment. So a small deployment, let's say there's 10 data collectors or numerators who are going out in the field. Maybe one person who's maybe more experienced, a supervisor has designed a form. So they design a form using the Excel-based tool. They've set up a server in the cloud. So they put the form on the server, and then they take the 10 devices that they have. They configure just one, and then in ODK collect, once you've configured the device, it can generate a QR code.

And then you take the other devices and you scan that QR code, and it configures the rest of the devices that way. So essentially, you can either type stuff in manually on all 10 devices, which seems annoying, or you can just configure one and then scan the devices. And so once those 10 devices have been configured, the phone can then download the forms that are available on the server onto the device. And then you can go about your day collecting your data. So that's for a very small deployment. For large deployments, if you have 10,000 phones, then you need more people, but you can essentially also put a settings file onto the device however you want to do that.

And the reason that this configuration is really important is because of the flexibility of the mobile client. So there's buttons on the screen that you may want to hide. You may not want your numerator to be able to delete data once it's collected, for example.

Each device has to be configured for the appropriate permissions levels for a particular deployment. What if you're going to deploy it into space? What if you're going to deploy it into space? Yeah, the space project is really interesting because

it was, they had about 3,000 people in rural Kenya handing out water filtration devices and collecting data, GPS coordinates and barcodes of each device that was collected. And then they were sending it off to a server. And the campaign was run by an astronaut. And so he was in space configuring devices and playing with the data on the server. So it turns out when you're deploying in space, there isn't dramatically, at least for our software, there isn't a dramatically different set of steps that you have to follow. So that's nice to know.

For my next space deployment, I just do the regular thing. Just do the regular thing at a work rate. It sounds like an early need to do offline was a pretty significant thing for adoption because there isn't always a network. I'm wondering, is there like a local LAN kind of scenario where maybe there's a network, just not a WAN? Is that kind of how this works in a way where you may be offline but you're sort of on a local network but still kind of not really online but kind of offline i mean there are some

projects where you know they'll have a hot spot or something and so for those kind of deployments you can imagine you know i'm in a small city in the main city, but I'm a small city. I've sent out a bunch of data collectors to even more rural locations. They come back to the hotel in the small city. They set up a WAN, and then they, you know, they submit data to a desktop computer that's running the server software. That's one kind of use case. But the more common use case is that there's no connection whatsoever, no WAN, no nothing. And so out, you collect the data.

But there's almost always a cell network nearby or close enough. And so it's at that point where if you have a connection, you can send to the server. That's the second common use case. And then the third common use case is that there's no connection, no internet anywhere. And so you just plug the phone into the computer. And then we have desktop software that pulls the data from all the devices that you plug into it and then generates whatever reports it. Good old wires making it happen. Yeah, good old wires.

I love talking about software that's been around and used for a long time because you guys have been through so much like you handle so many different cases it's not like this is a beta or this is a 1.0 we didn't think of that I mean everything was thrown at you you're like oh yeah this is how it works this is how you do it here's a weird scenario it still works it's just not great or whatever

but there's just there's something about software that's stood the test of time and been used in mass for a long time where, sure, it's got its warts, it's got its bugs that are actually features that are actually bugs, but it also has like a lot of weird, strange things that it can manage because it's had to.

Yeah, and one great example of this is we had some folks, one guy show up on our forum and say what he was using ODK for. And as a gift to his wife, he had built essentially a jukebox with a software. So I have to explain this because it's a little crazy. So if you think of something like SurveyMonkey, you can have questions that are radio button questions, right? And then you can have the next screen show results based on those

actions. And so in ODK, you can have text answers, but you can also have audio answers, options when you're doing this radio button. And so he had built a hymnal where the radio button selected the song you wanted to play. When you go to the next screen, it would show you the lyrics of the song, plus an audio snippet that you could play it. And so, you know, when people think of data collection, they really think just purely as a, you know, a replacement for paper forms. But what it ends up being is a sort of a lightweight programming environment for folks who are super creative. And so those use cases, there's use cases where people build a form that's really a triage protocol. And so you can hand this phone to a nurse and they walk through the same steps that a doctor will walk through to sort of triage a patient. So there's all these kinds of use cases

that if you're at it for 10 years, you sort of cover the long tail of what people want to do. That's awesome. Yeah. On our last show we were talking about CSS and HTML and there was a survey that went out about,

and with survey questions about HTML and CSS and one of the questions is, was it HTML, Adam? Is HTML a programming language or is CSS a programming language?

And it was funny because we had a brief conversation about it but then on the interwebs throughout this week there's been the conversation of like, are these things programming languages? And let me just go back. Last week, I was saying it's not a programming language. Okay, CSS can do some crazy stuff I didn't realize. So yes, it's Turing complete.

So I take it back. I was wrong, Adam, you were right. It just shouldn't be. It shouldn't be one, but it is. And so that made me think of, okay, they're using ODK for all these crazy things. It leads to the question, is ODK a programming language? It might be. So I would say it's not, you know, the tools, maybe this gets into sort of the underpinning technologies that we use. So the forms that you're using, the drag and drop form designer, or you're using the Excel-based form designer, all those sort of output an XML document. And that XML document is an Xform. So Xform is this old standard that IBM came up with, open source standard for forms. And I think

ODK and maybe Orbian forms, which is another open source project, are probably the only people on the planet who continue to use Xforms. But we found it a really powerful standard for Turing-complete forms. And our engine is a little, it's not as powerful as it could be, but essentially lets you do all sorts of crazy things with these XForms. And so for our users who are particularly advanced who step outside of the graphical designer or outside of the Excel-based designer and jump into Rock somehow, you can build some really powerful tools using that Form step.

So yeah, it is... I don't know if we can guarantee that it's during complete. We can build some wild stuff. We can build some wild stuff. We can go through wild stuff with these forums. This episode is brought to you by our friends at Rollbar. Move fast and fix things like we do here at Changelog.

Check them out at rollbar.com slash changelog. Resolve your robert.com slash changelog resolve your errors and minutes and deploy with confidence catch your errors in your software before your users do and if you're not using rollbar yet or you haven't tried it yet they want to give you 100 to donate to open source via open collective and all you got to do is go to robert.com slash changelog sign up integrate rollbar into your app, and once you do that, they'll give you $100 to donate to open source. Once again, Rollbar.com. So, yeah, earlier you said that you don't feel like you're a good programmer anymore.

And then you went on to list off what sounds like some pretty amazing software that's come from ODK and that project. So I'm guessing you have more people than just yourself involved because you got a lot of awesome software out there and surely didn't build it all by yourself. Can you tell us about the team, the community, what's grown, who's involved and so on? Yeah, absolutely. So yeah, you're right. I didn't build it all. Actually, I did. It was a long decade of writing.

You know, ODK is possible only because, you know, there is a community of people behind it. And when I say community, I don't just mean the software developers. I mean, you know, everybody who files a bug report is a community member. Everybody who writes a little piece of doc is a community member. Whoever does a training, because it's only through the individual efforts of these folks that the stuff works. And this is really important in our use case, because I think we talked about earlier that most of our users are not technically savvy. And so for some people, we're out in the field and we see that somebody struggling with like a bug, a very subtle bug. And this has been a bug that's been there for a while. And maybe millions of people have experienced this bug, but nobody complained. Nobody said to their supervisor or hopped on

a forum to complain. And so everyone who does that or who contributes to the project really is a member of the team. The project is organized currently as there's a project management committee that sits at the top. Each of the suites of software have their own technical steering committee. And so I'm going to focus on sort of the ODK technical steering committee. We have folks from companies within the ecosystem

who are there as sort of oversight of the project. And then the core software development, the majority of it is done by Nafundi, which is a company that I run. So we have a team now of about 7 to 10, depending on how you count, who do the core

development on the tools. And then we have a number of contributors that have come in to either Summer of Code or just people who use the software, fans of the software, who sort of contribute code. And so the way it typically works is that we start from our forum, where almost all the developers and a big part of the more experienced users live. When they have feature ideas or feature suggestions,

you have those discussions on the forum. Once it's to a point where we feel like, ah, that's a pretty good feature idea, it's been specced out, it goes to the technical steering committee where we sort of discuss it, make sure it's within our scope and what we want to build. And then that goes to GitHub where it's filed as an issue. And then someone, usually somebody

from the team at Nafundi, built it. Its PR is reviewed by somebody else and then eventually gets merged and it's released. You usually have monthly or every two months, it's eventually released to the community. There's a beta, but then it's released to the community. So that's how it works. I would guess most of our contributions come in not... We have a few contributors who are regulars on the code side,

but we have a ton of contributors on the support side, people who show up to our forum, who use ODK, who like it, and who are there to answer support questions from other newer folks in the community who have a lot of those kind of contributors. That's how it happens. That's how the magic happens. I just want to say those kind of contributors are awesome. They just hang out. They're there.

They're part of the community. They answer questions. I just feel like sometimes they're the unsung heroes of communities because they don't normally get the press or the thanks or much, but that hugely valuable and really make a, they make a group feel like a community or, you know, people feel like a family or whatever,

because they're there and they're part of the team, even though they're just happy users, you know? Yeah. And I think in our case, it's so important. Well, one is I'm biased because I spent the vast majority of my time on the project is spent answering support questions.

I find it really valuable because one complaint means that there's probably like 10 people who have that particular problem. And so the more support questions you answer, the more in tune with what the broader user base are. And so at Nafundi, we try to make sure that every dev is on the forum and is answering support questions. Because if you're not doing that, you're not feeling the pain, and you're just building random stuff then at that point. It emotionally connects you to the software you're making

because you can truly see the people that are using it, the impact, the errors or bugs or downsides of software, how they're impacting that person. And it provides an empathy path. Yeah, for sure. Absolutely. So when did you start Nafundi and what gave you the idea to do this and how is it going? So Nafundi started, let's see, ODK started in 2008 and Nafundi started in 2011. It was founded by myself and Carl Hartung. Carl was also my co-founder on ODK. And no longer with the company, but,

you know, we are still here and growing like crazy. So the company started because Carl and I wanted to keep working on ODK. So, you know, eventually you graduate, eventually they give you a PhD. And over, you know, since 2008 to 2011, you know, we had poured a lot of time and effort into not just the software, but growing a community ecosystem around it. I can't speak for Carl, but, you know,

and for me, I felt like a deep responsibility to try to keep it going as long as I could. All agreed. So we also kept getting projects. People kept using ODK at scale and needed help. And so in 2011, when we decided we were going to graduate in 2012, so in 2011, we started the company. I essentially provide professional services on top of ODK.

And so within the first few months, larger and larger products were coming our way. And so our model at that time was, you know, we take consulting dollars, we charge a premium, and then, you know, we do forks or we do core contributions. And whatever margin that we get, we use it to work on the unpleasant infrastructure or core changes that no one was paying for. You know, just standard professional services, open source stuff. Over the last two years, we've moved more into doing grant writing. And so at this time, myself and Alain Martin are now owners of the company. And our model is we do maybe like 25%

consulting work but 75% is grant funded so we go to folks like large foundations, government entities like USAID, and we make the case that ODK is a critical part of the global health

and global development infrastructure and that a lot part of the global health and global development infrastructure, and that a lot of their grantees and their projects use the software, but don't necessarily have a line item to support it. So I think it's really awesome that a World Health Organization or the Carter Center or a Red Cross uses the software. But when an organization with 10,000 users shows up on your forum, that's not a gift necessarily. It's a responsibility.

And the reality of our project is that we need resources to be able to fund developers who are essentially full-time who can make sure that we take a long-term view to support the tool. So we make that case to grants and to funders, and they've historically been agreed with that logic and that rationale.

So we essentially get grants to pay for the core developers who are there every day doing unpleasant stuff, like big-time migrations. Like no contributor wants to make sure that the app, you know, respects time zone or is tested on, you know, every device known to man. So you raise grant funding that way to pay for the core team.

And then the core team's mission really is, you really is to do the messy stuff, but also put processes in place that enable others to contribute. As you know, a lot of open source projects, most of your contributors are going to be drive-by. And so making sure that we're not just fixing stuff, but we're putting together a process that allows external contributors from wherever they are to contribute to the project. That's a big part of what we do as part of the folks that we bring on to work full-time. What I find interesting here is how you've changed how people pay for software like this. It's still free, but it's not free to build. It takes people power, it takes planning, et cetera, support, as you've mentioned.

And rather than having the would-be enumerators or form designers or people who are at the forefront of the problems having to swipe a credit card or find a way to pay for software that they haven't been able to establish a better relationship down the line with the actual organization and potentially get grants to do large amounts of support and or development. That's super cool how you planned that out. Yeah, planned that out is a very kind thing. Stumbled into, maybe? It sort of emerged. I spent a lot of time thinking about

open source sustainability and these sorts of things. And I wish there were a better way of doing it. But the reality of our customer base is most projects in global development, global health, and sort of the cubit of space are funded at a project level. So you will be able to get an organization to, say, do a malaria project or do an election, but there's nobody who's funding improved time zone support. And so we sort of have to, and I think it works best this way, that we treat ODK as a public good, as infrastructure, and convince the folks who, the biggest organizations who rely on that infrastructure to help support it.

One question that I always get is that, is any of this stuff sustainable? I always find it really like an odd question because like, is Subway sustainable? Like, what timeframe are we talking about here? Right. At what point will it become not useful? Yeah. So I think for me, there's a couple of ways I respond to that.

One is that nothing is forever. As long as the software is in use, I thought when we started the project 10 years ago that it was a terrible idea and it was never going to work. Obviously, I was wrong. I've stuck it through. And I always also thought that someone would come up with a better open source thing that would out-innovate us

or out-repeat us in some way. That has not been the case. I think the difference between ODK and some other projects is that people care about the project. And so people show up every day, certainly I do, to chip away at the problem and try to make software that's a little bit better each day. I think if you do that over a decade, it shows. Things get better.

So for me, it's sustainable as long as people show up and use it. And it's sustainable as long as it's solving meaningful problems for folks. And I think that's a very easy argument to sort of make to somebody who wants to support the project. And so it's sustainable in that way. And if that way ends up not working, we'll try another way. That's one approach to it. The other approach is a lot of things that we do in the do-gooder space is not sustainable. It's not sustainable to deliver bed nets to people who need protection from malaria. We do it anyway because it's the right thing to do.

And there's plenty of resources in the world to do it. For me, the value that ODK generates in the world, as far as life saved and data decision making from elections to climate monitoring, it's in the tens of millions, maybe billions of dollars. There's companies built on ODK. There are software companies built on ODK. There are consulting organizations in a lot of countries that customize O2K for folks. And so there's a huge ecosystem there. And so the funding that we typically ask for is dramatically smaller than the value that we provide. And so to me, it's sustainable in that way. So the grant writing, you said you've been doing that for about two years.

Have you found that to be a winning strategy thus far, something that you want to pour more into or is it difficult to succeed in that way? You know, I think the grant writing is, you know, it's not fun. Sure. I love the chuckle afterwards. Yes. You know, it's not fun, but things that are important to do are often not fun. And so I'm committed to doing that as long as I can. And so far, it's been working. And it's been working since 2011. And in 2011, we did not have as much impact as we have now. And so I'm optimistic that it will continue to work.

But it's not the only thing that we do. I'm always thinking of other ways to get a more sustainable, consistent funding project. And so day to day, that's what I'm always thinking about. Because yeah, grants aren't forever. But we have a pretty good consulting business as well. And so as long as that keeps going, we'll be able to manage. Have you tried hosting? Or is that something that you don't want to

touch with a 10-foot pole? I love hosting. I just love DevOps, just as a hobby. I just love hosting servers. I love DevOps. I think the challenge with hosting for ODK in particular is that there are

other folks in the ecosystem who have a pure hosting business. And so I, as one of the project leaders, I want to be sensitive to not competing with our community members. There's no point in bankrupting one partner just to fund the project. And so hosting is something that we've talked about at a project governance level, but I don't think, currently, I don't think it's necessary. I think it's also not in the reality is, so the largest streams of money

at least in our industry, a lot of it comes from for lack of a better word, consulting. So services revenue feels to me like a better way of funding the project. But you never know things change so we'll adjust as necessary on the grant side you mentioned that writing grants is not fun and it's maybe hard to believe but there are people out there in the world who enjoy writing grants and so i would suggest that you try to find one of them and then you hire them to write the grants for you.

And then everything's good, man. It'd be all good. Get you back on those higher level things. That's right. It's the easy button. Yeah. There are people that like writing grants. I mean, maybe they don't love it.

Maybe they don't wake up in the morning and just die into it, but they like it. Well, maybe I'm not being fair to grant writing. It's not the most fun thing to do, but I also don't mind, maybe I'm not being fair to grant writing. It's not the most fun thing to do, but I also don't mind it. Okay. So it's quite all right. You know, I think, yeah, if there, maybe this is a good segue, if there are folks who want to contribute to a project and chip in on everything from grant writing to, you know, all the various things that we have on the project, you know, welcome. And I try to maintain a very open definition of what a contributor is.

We need all sorts of help. So don't let me just have all the fun. Yeah. My next question was thinking about Nafundi being a funding source for this, a sustainable source for this, meaning that you might be hiring more people to contribute,

not just to the project itself, but to the greater goal of Nafundi to do the same goals for ODK. Yeah, I don't know if there are many companies who are, I guess there are some companies that are sort of really closely aligned to a project. For me, the folks who run Nafundi, our goal is to sort of align ourselves as closely to the benefit of the project. So we try to position Nafundi

as a vehicle to grow ODK as much as possible. And it's way more important that ODK as a project survive and thrive than it is for Nafundi to survive. And so, yeah, it's really just a vehicle for us to do that. I look at that scenario like anybody who relies on a piece of equipment, right? Like in this case, ODK is Nafundi's piece of equipment, crucial piece of equipment to do the job which is to create awesome surveys forms data collection processes etc you know like if you swing a hammer and that hammer is your core piece of equipment

how do you treat the hammer you probably shine it you probably clean it you probably maybe even put some special oil on the wooden handle i don't know i just thinking, like you're going to take care of it basically. Like it's in your best interest. I don't think you're going to shine a hammer necessarily. I'm just saying, like you might go overboard at this point in ensuring that this piece of equipment never fails you, that it remains the hammer it needs to be.

Show it with like a samurai sword, then you could sharpen it, you could shine it. Yeah, maybe this metaphor doesn't work. But I mean, I think you're preaching to the choir here because right certainly i i agree with you but when push comes to shove i you know i find that a lot of people i mean if you just look at like open ssl for example there are a lot of companies that rely on this piece of software but they don't

necessarily treat it well and it's a structural and governance issue there. One thing that we're doing at ODK is taking a real close look about how we encourage other organizations to participate. You know, I was saying that we have this technical steering committee with folks from different organizations.

We just launched a new sort of providers page where people who, organizations and individuals who contribute big chunks of time and effort to the project get listed as a recommended provider and try to align the incentives so the more support questions you answer properly the higher up on the odk website you go as a recommended person higher and the questions have to be answered in the open so for our individual contributors

that's like people who are helping get a chance to get hired. And then for the companies, if we see that a lot of your devs are working on the core tools, then yeah, you are absolutely on the provider website if somebody wants a customization or a large deployment that they should hire one of these. Then try to align it

so we don't have to depend on sort of the kindness of companies to do the right thing. It's just like it helps your bottom line to do the right thing. So where does the Open Data Kit community live and what's the best way to get involved? Yeah, that's a good question. We live currently at forum, F-O-R-U-M dot Open Data Kit dot org. I always have to spell it out because form as in the survey form and forum are, yeah, it gets super confusing. Maybe we should just make that an alias.

But that's where the community lives. And so anyone who is interested in participating in the project can go to that forum. It's a discourse forum. Create an account and just introduce yourself. And just say roughly what you're interested in. So that's one way of doing it. And then sort of my commitment, whenever I say this, my commitment to anyone who shows up and introduces themselves and says, I'm interested in helping, is that I will take some time and we will talk about what you're interested in, what your skillset is, how you want to grow, what you want to do, and we'll find a place in the project for you. So that's sort of very hands-on approach,

but it's an approach that we want to take because we want to make sure that it's not just, you know, that's a two-way street. You're helping us and we're helping you in some way. So go to the forum and introduce yourself. If you're a dev and you just want to hack on code, certainly you can go to our GitHub page, github.com slash open data kit, all one word. And there's a bunch of repos there. Some of the started ones are the active ones. And then each repo has good first issues or quick wins. And so you can pick any issue.

You have a contribution guide. You can follow that contribution guide to get your first PR, and then it will be reviewed, tested, and merged. So that's another way of going. But the lowest bar, I think, is just go to the forum, say hi, and sort of join us. I should say that everyone is welcome, regardless of your skill set. If you're a designer, you're welcome. If you're a developer, you're welcome. If you love grant writing,

you're welcome. If you want to help us on social media, you're welcome. Literally anything that you're interested in, we will do our best to find a spot for you. The forum now has, I think, almost 10,000 people, 9,000, 10,000 people on it, all helping each other. And it's, you know, I participate in a lot of open source. I'm a little biased, but I think it's the nicest and friendliest community out there. So we'd love to have anybody who wants to. Well, yeah, it's been an awesome conversation with you, especially digging back into your journey, kind of learning where you came from in terms of all this schooling to get a CS

degree and to use it so wisely, so impactfully. I'm just, I'm taking it back. You did an awesome job with all this and you're running a great community and we thank you for your time. Well, thanks for having me. It's been a sort of a great conversation. And you know, I think I said very early on, I'm a long time listener of the Change Log, so it's really an honor for me to be here and share the work that the folks in our community are doing. Well, let me say on our behalf, we're definitely glad to have you. Thank you so much. It was awesome. Thanks so much. All right. Thank you for tuning into this episode of the changelog. Hey, guess what? We have discussions on every single episode now. So head to changelog.com and discuss this episode. And if you want to help us grow this show, reach more listeners and influence more developers, do us a favor and give us a rating or review in iTunes or Apple podcasts. If you use Overcast, give us a star. If you tweet, tweet a link. If you make lists of your favorite podcasts, include us in it.

Also, thanks to Fastly, our bandwidth partner, Rollbar, our monitoring service, and Linode, our cloud server of choice. This episode is hosted by myself, Adam Stachowiak, and Jared Santo. And our music is done by Breakmaster Cylinder. If you want to hear more episodes like this, subscribe to our master feed at changelog.com slash master. Or go into your podcast app and search for Changelog Master. You'll find it. Thank you for tuning in this week. We'll see you again soon. Bye. you