ACM ByteCast - Yaw Anokwa - Episode 31

Episode Date: November 15, 2022

In this episode of ACM ByteCast, our special guest host Scott Hanselman (of The Hanselminutes Podcast) welcomes research scientist, software engineer, and entrepreneur Yaw Anokwa. Yaw is the founder and CEO of ODK (Open Data Kit), the offline data collection platform that helps fight disease, poverty, and inequity. He holds a PhD in computer science from the University of Washington and likes to keep his bio short and sweet. Yaw describes how he felt the urge to pivot his career into a direction of positive social impact as a graduate student at the University of Washington. A volunteer experience with Partners in Health in Rwanda and a software engineering internship at Google showed him the potential for technology to empower people and change lives—specifically through ODK—which became his chief project and passion. Yaw and Scott discuss ODK’s main differentiator, “powerful offline forms,” as well as user interface affordances made to customize ODK for its users, such as rural farmers in Uganda. He also shares the joy of working on a product that focuses on public good and some principles that have helped him to succeed. Link: https://getodk.org/

This is ACM ByteCast, a podcast series from the Association for Computing Machinery, the world's largest education and scientific computing society. We talk to researchers, practitioners, and innovators who are at the intersection of computing research and practice. They share their experiences, the lessons they've learned, and their own visions for the future of computing. I'm your host today, Scott Hanselman. Hi, I'm Scott Hanselman.

This is another episode of Hansel Minutes in association with the ACM ByteCast. Today, I'm chatting with Yao Anakwa. He's the founder and CEO of ODK. How are you, sir? I'm doing very well. Thanks for having me, Scott. So ODK stands for what? Originally, it standard for Open Data Kit in the sense that it's an open source data collection toolkit.

These days, we just call it ODK in the same way that people don't call IBM international business machines anymore, right? It's just become an acronym that means data collection. Okay. And on its face, it is powerful offline forms. And it's interesting because people pick their taglines and it matters. Those taglines matter. Every word matters. You didn't say powerful forms to collect data. You didn't say data collection toolkit. You said powerful offline

forms. Why is that important? Well, because ODK's value add, its primary differentiator is the fact that the forms themselves work entirely offline. And they're not sort of simple forms like you see in SurveyMonkey or Google Forms. They're really forms that end up looking like mini applications. So the forms can collect obviously text and numbers, but they can collect GPS coordinates. They can collect pictures. They can scan barcodes. They can have complex logic associated with them. So they really are powerful forms and they work entirely offline. Were they always powerful forms? Because I understand that you started this as a software engineering intern at Google. Did you start with like text boxes over data? And then when did you get into complicated data formats? We started complicated. So the story there was that I was a grad student at

the University of Washington in Seattle, and my advisor Gaetano had a sabbatical at Google. And so we went there to build a powerful offline form tool because it was just right around the time that Android was starting. And so as researchers, we thought here's an awesome opportunity to build something on an entirely open source data collection, the operating system, mobile operating system, and do something that you couldn't do on a basic J2ME phone or an Nokia phone at the time. So we went in wanting to build powerful offline forms. And offline meaning it's going to put it on local storage of the device that you're on. And then when it docks or when it gets connection or when does it sync up? And is it a bi-directional sync or a one-way sync?

Yeah, it's a bi-directional sync. And so the typical use case is that you have a data collector or in our industry, we call it an enumerator. Somebody who's out in the field, usually remote place with no internet connection, and they're maybe doing a household survey. They're going house to house and they're filling out forms. And if and when that mobile device sees either a cell connection or a Wi-Fi connection, it sends all the forms that have been finished up to the server. And if there are any updates or new forms, those get downloaded automatically in the background. And we have users who are maybe

in the Amazon rainforest doing community-based forest monitoring. They're out there for months at a time collecting data. And whenever there's a connection, the data goes up and new forms come down. And I'm imagining simplistically people walking from door to door doing censuses, but that's humans talking to humans and helping them fill out forms. But as you said, you're doing surveys. I'm assuming that you're not just talking to humans, you're talking to devices. It's primarily humans in the sense that the typical use case is a household survey, but it varies. So for example, the surveys don't have to be about people. So we have examples of users who are documenting the health of forests or farms or users who are monitoring animals.

The common case, though, is there's a person who is interrogating, asking questions about a thing and collecting data about that and then sending that to a place where the data can be acted on. Help me understand the software architecture here. There's a collector and there's a server, but are you a giant world database? Are you like a Power BI? No, not so much. So we provide software that people can install either locally on their own machine, self-hosted,

or we provide a managed cloud hosted service. And each customer or each user, they set up their own machines or have their own account to collect the data just for them. So the data doesn't flow into one big database. It flows into their database. It's their data and they can do with that data, whatever they want to do with. That's pretty cool. I mean, the idea that this is for the people, by the people, there's nothing underneath it. There's nothing hidden or sneaky in it. It's power to the people in the literal sense embodied by software.

Yeah, that's exactly right. You are some platforms where essentially it's free, you're collecting the data, but behind the scenes, the data is being used and sold and marketed. In this case, ODK is an open source project. It's targeted exclusively towards social impact organizations, folks who work in public health, folks who work in climate monitoring, in election monitoring, and it's their data and they use that data for critical decision-making. And because a lot of the data is sensitive, sometimes it's government data, sometimes it's personal data, we want to make sure that it's clearly belongs to the people who are collecting it and there's nothing sneaky or hidden about it. In the early 2000s, you had your own

consulting company, You did some work at Intel working on some custom hardware. Then it looks like you started doing some volunteer work as a software engineer. Help me understand where you went from the classical working for a big company doing stuff to public goods. Yeah, I suppose it happened. I was a grad student at the University of Washington and I saw a talk by Neil Lesh. I remember this to this very day. And he was talking about how he was sort of a wandering do-gooder. He was nomadic. He was wandering around East Africa. And he gave a talk about how he was fixing computers in hospitals. And I thought that was so compelling that I talked to my advisor and I said, you know, this time I think I was building NFC hardware for Intel as an intern.

And I thought, like, I just don't think that that's the best use of my time. So I volunteered. I actually went to Partners in Health in Rwanda. They were setting up a medical record system there. And I volunteered there for six months. It was mind blowing. I really saw that with a little bit of technology, you could change the lives of so many people. And so what I did there was, you know, I set up a medical record system and I saw that that system,

electronic medical records, could increase the quality and the scale of HIV and TB care. And so having seen that, I thought as a computer scientist, well, can we make this more abstract? Can we make this more usable for folks who don't have to set up a medical record system? And so the general problem of taking a paper form, which is ubiquitous in social impact, digitizing it and giving that data back to the people who are collecting it, that's what started me on that journey. And so, yeah, I gave up on the ubiquitous computing and the NFC stuff. And I thought, well, here is something that is in many ways so simple, but can make a huge difference to folks all over the world.

Now, I recognize that you're not done yet, but I'll a huge difference to folks all over the world. Now, I recognize that you're not done yet, but I'll use the word dedicate your life. Did you know that this was going to be it? Did you find your thing at this point? At that time, I have to admit, I remember when Gaetano, my advisor at that time, called me and I was working on some SMS-based project in Tanzania. I was sitting on some beautiful beach having a beer and Gaetano called me on my cell and said, hey, I'm going to Google to work on this data collection project. And I thought, I'm okay. I'm comfortable here. I'm exploring new research ideas. I don't want to go back to the States to go work in Seattle in some office. So I told Gaetano no, but Gaetano was very

persistent. He called me and my buddy, Carl Hartung, who was also a grad student, called me and said, come on, you got to come back and stop messing about. So I returned to Seattle, to Fremont, and I started working on it. I didn't think it was going to work. I'll be the first to admit it. I thought, I mean, giving at that time $600 smartphones to rural farmers in Uganda just didn't seem super compelling. But I got into it. We deployed the first versions of the software and it was just amazing to see how people took to it and how valuable they found it. And that was about 15 years ago, actually. And you're asking, is it my life's work? I must say it's become my life's work because I've seen the impact it has on people. And if you let me sort of expand on that, you know, you're a software developer. A lot of people on this talk might be software developers as well. And listening to this podcast, it's extremely hard to build software. As you know, it's hard to build software. It's hard to build software that is useful in any way. It's hard to build software that works. It's hard to build software that has an impact. And it's hard to do all of that and make it open source and have

this sort of positive impact. And so over time, I've come to realize that what we've done is really incredible. It's rare. And as one of the founders of the project, we have to keep it going. And at the end of the day, I enjoy it. It's just a fun project to work on, to hear from users about the impact that they're having. And yeah, we just have to keep it going. So yeah, these days is my life work. I get up every morning thinking about data collection. I go to sleep thinking about data collection. It's not a bad life. It's definitely not a bad life. I currently work at Microsoft, so we're making a lot of big software, but it's a bajillion people. And one of the things that I've found is that the engineers and the program managers that don't talk to customers, that don't spend time with them, they have an ennui, a malaise

of just like, time to make the donuts. And they just kind of, but if you sit with someone whose life you changed, it fundamentally changed. It sounds like you got that experience early. You talked to customers and you can't stop talking to customers. Yeah, I always do it. Even to this day, I do a lot of the customer demos for people who are signing up for our cloud hosted service. And so, yeah, pretty much every morning, starting from 5 to 6 a.m., I am in calls with customers showing them the software. So I do that a lot.

ODK, from the beginning, because it's an open source project, has always had a dynamic and active community. And so we have about, I think at this point, maybe about 14,000 or 15,000 people on our community forum. That started as a mailing list. So I talk to those folks all the time. We also have a technical advisory board with people from the community that I talk to every month or so.

So I love talking to customers. It's how we know that we are on the right path and doing the correct kind of work. So there's no on we there. Yeah. You're addicted to it in the best way. Like you have to talk to the customer. Otherwise, how do I know what we are supposed to build next? I mean, we, and we have to do it also because the context in which we work in is like pretty

unique. So, you know, if you're at a Microsoft or Google and you're building software for businesses or folks in the West, then it's very easy because you're functionally building software for people like you, but we are not building software for people like us. We're building software that works in very specific environments under certain constraints. And so the only way that we can build that software and make it relevant is by having an open lines of communication to the folks who are using it. And so that is key to our success. Yeah. And that customer empathy seems to come out in your forms. I've looked at a number of different ODK forms and for some of them,

particularly ones that are in developing countries, I noticed that, I don't know how to say this, the buttons were kind of big. It feel kind of chunky. And I was trying to understand why are these buttons so big? And then I started to apply some empathy to it. And I think I know why. And wouldn't you mind telling me? Yeah. So there's lots of sort of UI affordances, user interface affordances in ODK. And those are things that have been learned over the years. And so the first time we deployed ODK was in Uganda in 2008. We were working with some rural farmers. They were in huts without a lot of electricity. And a lot of them had calloused fingers because, you know, look at your fingers, Scott, your

programmer, your fingers are soft and squishy, no callouses. If you look at a farmer's fingers, they are calloused. And so the way a touchscreen works is through this capacitive touch where electricity sort of passing through your fingers, a small charge. And if you have calluses, that small charge doesn't work so well. And so what we do with ODK is that the buttons are big because our customers, our users, they need a big touch surface. Our buttons are big because most of them don't have glasses or corrected vision. And so there are all these sorts of affordances that, you know, ODK may look chunky to you because you're living a very comfortable life. But I assure you the millions of users that we have use ODK because of that chunkiness. It's because these big chunks are affordances that

enable them to collect the data that they need. I appreciate that. And again, no disrespect intended by the word chunky, just trying to express the sense of, you know, it's a swollen UI. And it made me think about my father who worked with his hands his entire life. And I watched him struggle with his iPhones because he's got big hands that look like banana bunches

that are covered in calluses and he jabs at the screen. But as soon as I just pumped up all the fonts on his phone, everything got better. All the hit points are better. And here's the thing, though. My lack of empathy initially was like, well, I don't understand why you're having a problem

with this. What's the deal? Of course. It's not that hard. Just hit the button. My dainty fingers work fine. What is the problem with you? You're building that empathy all the way through because you've got the collect application

and then you've got ODK Central, right? Now, is ODK Central a database or is it a server that catches data? And where does the data end up? Yeah. So Collect is the mobile app. So it's in the Play Store, the Android Play Store, and Central is the server. And so the server runs on somebody's infrastructure, either on our managed hosted solution or on-premise or locally on somebody's server, and it hosts the blank forms and it also hosts the data that is being sent. So the idea is that maybe a project manager puts the forms that they want the data collector to fill out on the central server. The phone links up to the server, downloads it, and then the submissions go back to the server. And once it's on the server, we make it really easy for folks

to sort of use that data, be it downloading it as a CSV or Excel file where they can do their reports. And naturally, we're programmers. It has a beautiful REST API so people can integrate it with other systems, including tools like Power BI and R and Python to sort of pull that data into their data analysis work streams. You said that you can do that on-prem so you could have that private and self-hosted with a little support, but you also, of course, offer your own reliable cloud version of this as well. That's exactly right. Yep. This is a public good, but to people who are listening right now, if they have a text boxes over data problem, you've solved that.

I think so. And a lot of our users think so. So yeah, it's a nice solution for folks. We didn't always used to have the cloud hosted option, you know, and I want to talk a little bit about that because as computer science researchers or as open source enthusiasts, we always thought like, oh, I mean, obviously people want to run their own servers. So we don't want to be in the business of running servers.

We will just give people the software and freedom, et cetera, et cetera, et cetera. It took us a long time to sort of reach the point where a lot of our users don't want to run their own servers. It is a lot of work. And so we came to a point about two years ago where we wanted to solve two problems. The first problem was that it's really hard to build an open source project and make it financially sustainable when you're giving away the software and applying for grants that come randomly. And so it was hard to sort of thoughtfully evolve the software. So that was

the first problem. And then the second problem was what I just mentioned is that people don't want to run servers. Running servers is hard. Email delivery is hard. There are all these sort of hard problems that you don't want to be taking on as a nonprofit or a government. So we launched our cloud-hosted solution for that reason,

is that it makes it very easy to get an account and just collect the data you need. And it gives us this sort of predictable revenue that we can use to hire people and sort of thoughtfully evolve the software as opposed to randomly evolve the software based on what grant we get at what particular time.

Right. And that now is self-sustaining. And like you said, you're talking to customers every day and they're signing up every day. Yeah, it's been really amazing to see. I suppose it took us, you know, 14, 15 years to get there. But yeah, we're much, it's a very popular service, cloud service. It's enabling us to sort of ship more software quickly. ACM ByteCast is available on Apple Podcasts, Google Podcasts, Podbean, Spotify, Stitcher, and TuneIn. If you're enjoying this episode, please do subscribe and leave us a review on your favorite platform. When did you know though that it worked? You just said that 14, 15 years. So I'm getting this sense that you're an overnight success in just 15 years.

So anyone can do it. Just grind alone in a room for 15 years. I think that's the key to it. You know, we always talk about like, you about, there's lots of things that we could be doing better, but there's something to be said about showing up every day and just trying to get better every day. And so when we started in 2008, I knew it was working because I got an email maybe a few months in after we deployed the software from a group in Kenya. And they said, we have deployed ODK on 3000 phones in rural Kenya. When the project is over, we collected so much data. They were distributing water filtration devices. I'm addicted to email. Instead of doing my graduate research, I'm just responding to

support posts because that's more fun. And I responded immediately. I was like, did you mean 30 or 300? And they're like, no, no, no, no, 3,000. And that's when I was really blown away because at that time I didn't know we had that many users. And to me, it was mind blowing that somebody would take just random software from the internet, put it on a bunch of devices, deploy it to the middle of nowhere on 3,000 phones and have success with it. And so I knew that we were on the right track then because it had sort of, somebody had found it useful, had success with it, and we were not involved at all. That's when I knew. But yeah, that was like in 2009 or something like that. And then we've been grinding ever since. From a technical perspective, were you in any way surprised

that that production load test worked? They could have said we put it on 3,000, but it only worked on two. I was very surprised because I have to be honest about that. As grad students at the time, your job isn't to write production quality code. Your job is to write the minimum amount of code needed to test an idea, evaluate it, and write your paper. And so anything that looks like production code means that you've spent too much time on the engineering side and not enough time on the research side. So obviously, you know, we try to make it as robust as possible. But yeah, I was surprised. We've made a lot more progress since then. Yeah, we've been very fortunate. The first Android phone came out just 14 years ago. Like Android has taken over the planet,

and particularly the African continent. You can't go anywhere without bumping into an Android phone on the continent. But that means that in summer of 2008, there wasn't an Android phone on the African continent. That's correct. Yeah. Or was there? There wasn't. And in fact, I'm sure the statute of limitations have passed by now, but myself and Carl Hartung, who's my co-founder in ODK, we were, again, interns at Google, and we're pretty sure we brought the first Android phones to the African continent. Now, we didn't tell anybody we were importing these new devices, but we loaded up 20 phones into our bags, flew to Uganda for a project, and brought the Motorola, I think they were G1s,

HEC G1s. The little flip phones. HEC G1 was October of 2008. Yeah. We brought those phones, 20 of those phones to the continent. Now, you know, Android is everywhere throughout the world. ODK runs on, see, last I checked, maybe like 22,000 different Android devices. It runs on TVs. We actually have maybe about five or six users who use ODK on TVs, which it doesn't really make sense. Like, how does that even work? But the analytics show that people are using it on TV.

So yeah, it's crazy. Do you ever dig into that? Like, I'm imagining someone coming into like a health clinic and they're sitting in the room with a smart TV on the remote filling out a form waiting to get seen. Like, do you know what they're using it for? You know, we anonymize all this stuff. So we know that people are using it on TVs, but we don't know who and why. My guess is that it's really nice on a big TV when you're doing a training.

So, you know, you have a team of 500 people who are going out to collect data and you have an Android TV. Well, you might as well install Odacade there and then people can see the interface. And so they must be using it for training. But I can't imagine somebody in the rainforest carrying around like a 27 inch TV on their back and using that for data collection. Now, this is an open source. It has a wonderful API. You pointed out that it has a rich web API. Does it have plugins and the ability to talk to other systems or does it talk to other systems via its open data formats? interact with ODK is two ways. The first is by forking it in some way. So ODK is kind of the first and most well-known sort of data collection platform in the global health and development space. And so there are a lot of derivatives of ODK that are out there. And so chances are,

if you see somebody collecting data in the field somewhere, either they're using ODK or they're using an old clone of ODK or they're using ODK's format in some way. So that's sort of very typical. The other way that people interact with it is with our API. So we have specs and APIs that a lot of platforms implement. And that's been kind of nice because we have this sort of standard representation for a form that people can implement their own ODK compatible services. And there are a bunch of those. And you do have a relationship. I understand that XLS form is a standard for building forms in Excel. And is it true that ODK can speak Excel forms? It's more than that. So XLS form is a format that was developed and pioneered by a company called Ona, great group of folks over

there. And now the ODK team maintains it. So we maintain and evolve the XLS form standard. We maintain and evolve a platform called Enketo, which is a web renderer for that form standard and a lot of the core libraries under the hood. And these are standards, like published standards that we can go and learn about and use. Yeah, they are published standards. They're not like WC3 standards in that way, but they're sort of the de facto standard for data collection, particularly offline. So, yeah, both the forms, the underlying libraries, the APIs, we maintain all of those. I'm just kind of thinking about the timeframe here.

I think the cloud just started when you started and Android phones just started when you started. You really had a good idea at the right time. I mean, how good is that? Yeah, we feel very lucky. You know, we're at the right place at the right time with the right team. It just sort of worked out really nicely. Very fortunate. I do have a weird relationship with the word luck. So I want to gently push back. And I think you'll probably agree with me that luck is opportunity plus being prepared. And you were absolutely prepared and an opportunity presented itself. So you didn't get lucky, you made lucky. I understand that point for sure. As I think my

wife says it, you get dealt a set of cards and you play them well, but I also never want to discount sometimes the randomness of it. So maybe I was lucky in 2008 and then I've been working at it for a long time since. Yeah, that is the thing. It's hard work. There's luck that you see in a press release or a single Instagram post, but then there's also the five years of grinding. That makes the big difference as well. Now, I understand that ODK is being used in the public health sector. It's being used for large-scale disease surveillance. Largely, it's humanitarian. It's the public good. Are there commercial uses? Are people using it just in companies to do late stage capitalism? Or do you discourage that?

We don't discourage anybody. You know, we believe in sort of freedom in the sense that you can use it for whatever. I know of militaries that use it. I know of banks that use it. I know of a seat manufacturer for an electronic car company whose name starts with a T that uses it. And so what could it be? Can't win them all. In many ways, we don't want to prevent anybody from collecting the data they need, but our focus always is on the social impact sector. So those are the folks who determine what features we build. And if banks or other companies

want to use it for capitalism, that's fine. It's their prerogative. I hope this isn't too personal of a question, but you could turn on the marketing machine and hire a bunch of salespeople and turn this into a money printing machine. But you, at every turn, have not done that. I don't even know if you have a marketing department. I am the marketing department. You've chosen, though, not every turn, have not done that. I don't even know if you have a marketing department. I am the marketing department. We don't have a marketing department. You've chosen, though, not to turn this into a machine. I guess I don't get, maybe I'm simple-minded.

I'm not, you know, a business mind or whatnot. Yeah, I just don't get the point of all of that. There are plenty of data collection platforms that have great marketing. Our job, the team's job, our focus is just to build the stuff that folks find useful, relevant to their work, and allows them to do that work. We generate enough money to do that and no more, and we have a lot of fun doing it. And I think our marketing machine really is our community, the people who use it in the field. And sometimes when I get on calls with customers, I ask them always like, how did you find out about ODK? And often the answer is, oh, we use this other platform and our data collectors refuse to use it because they get

paid per submission. And if the submissions get lost, they don't get paid. And so they really trust ODK and they refuse to use something else. And I think that trust comes from years of us doing the right thing when the going got tough and not using it as a money printing machine. We really genuinely, everybody works with the team. We believe in producing a public good, making it as widely available as possible and helping folks who are helping others do their work. And if I want to do something else, yeah, I could just get a job somewhere else. But what's the point of that? There's plenty of people who are doing that. You have enough and you sleep better at night and you are affecting the lives of millions and millions of people, which is exactly the whole point. It's a pretty good upside. I just don't

understand why more people don't do it. I have to be honest with you. It just seems like, to me, it's such a joy and a privilege. I don't know why people aren't stopping what they're doing now and doing similar stuff. But yeah, different strokes for different folks, I guess. I love that you say that your marketing team is your community. I know that you are a big fan of discourse, not discord with a hard D, but discourse. That's correct. And you run your forums on discourse as well. So when you're out there deploying open source software, you're also recommending other open

source projects for deployment. Yeah, for sure. You know, I am not sort of religious about open source. I think it prevents locking in these kinds of things. But to me, the very idea that other folks are out there building software and essentially giving away and giving folks the power to do what they want with the software is just a nice thing to do. So I love Discourse as a platform. We use it a lot in ODK. And whenever I get a chance to advocate for it, I'm the first one to do that because it ultimately, it's been the heart of our project because it enables us to connect to our community and get input from the community. And that's essential to building great software. Very cool. Well, folks can check out ODK at getodk.org.

That's correct. You can learn all about it. And I think the number one thing as a member of your community, as the open source community, as the technical community, as a computer scientist myself, it's about awareness. So I'm happy to be a member of your community and your marketing department now. Perfect. And if folks are listening right now. Yes, if folks are listening and you have a problem and you think, wow,

ODK has solved that problem, then you can check it out at getodk.org. Thank you so much, Yao Anakwa, for chatting with me today. Thanks for having me, Scott. Yeah, if there's any way I can help anybody listening to the podcast, my email, I always like to share my email. My email is whyanakwa, first initial, last name, at getodk.org. You can send me any question you'd like about open source, about data collection, and I commit to answering it. So send those emails in. Absolutely brilliant.

This has been another episode of Hansel Minutes in association with the ACM ByteCast. If you're listening to it at Hansel Minutes, there's other shows that you can listen to. And if you're listening to it at the ACM, be sure to explore the back catalog of the ACM ByteCast. And we'll see you again next week. ACM ByteCast. And we'll see you again next week. ACM ByteCast is a production of the Association for Computing Machinery's Practitioner Board.

To learn more about ACM and its activities, visit acm.org. For more information about this and other episodes, please do visit our website at learning.acm.org slash ByteCast. That's B-Y-T-E-C-A-S-T, learning.acm.org slash ByteCast.