Mo Duffy, a UX designer at Red Hat, discusses the importance of user experience (UX) in open source software development. She explains that UX is critical in ensuring that software is usable and meets the needs of its users. Duffy emphasizes the need for UX designers to understand the problems and goals of users and to advocate for their needs during the development process. She also discusses her work on Podman Desktop, a tool that brings a user interface to the Podman container creation experience. The goal of Podman Desktop is to make it easier for developers to work with Kubernetes environments. Duffy also touches on the role of diplomacy in open source development and the potential of AI to improve user experiences.
“A technology is just a tool. What UX designers bring to the table is, 'what is the human problem this is solving?' People do not want to sit in front of their computer for hours, just spending all this time and luxury in your application. They want to go in, get it done, get out, go home to their kids, have a nice meal.” – Mo Duffy
Katherine Druckman: Thank you so much for joining me in our KubeCon fishbowl. This is what I like to call it because-
Mo Duffy: It's just very blue and fun in here.
Katherine Druckman: Yeah, it's a little bit like an aquarium. It is very blue, Intel blue. Thank you so much for taking time out and pulling yourself away from all the other stuff you're doing.
Mo Duffy: Sure, it's my pleasure. Thanks for inviting me on.
Katherine Druckman: I'm really excited about this conversation because we get to talk about something that I have a lot of affinity for and don't actually get to talk about very often, and that is UX, user experience. I think it is critically important in open source software, as in all software. This is going to be really good because I'd really like to get your insights about a lot of things, among them, what is unique about UX and open source, but also the importance of acknowledging that if nobody uses your stuff because it's too hard to use, then what's the point?
Mo Duffy: Right, exactly. You have all the features, but if people can't actually achieve anything with them, then do you really have a feature?
Katherine Druckman: Exactly. If you wouldn't mind, please introduce yourself a bit and tell us what you do at Red Hat and in the open source community.
Mo Duffy: Sure. I am an OG Linux contributor. When I was in high school, my brother brought home Red Hat Linux, I think it was 5.1. I was a chatty teenage girl tying up the phone line so he couldn't telnet into his university to compile his homework, so he got Red Hat Linux, so he had GCC so I could talk on the phone to my heart's content. Not that that wasn't without conflict. In putting Linux on the family computer, I was like, "Hey, this is kind of cool. I can do all this crazy customization of the desktop and I can make my own custom icons and I can do this stuff so easily."
The app that most captured my attention being a designer was the GIMP. I don't know if anybody used the GIMP in the early days.
Katherine Druckman: I did.
Mo Duffy: It was a little difficult to use, and that kind of ignited a spark in me like, "Hey, maybe I could go to college and study how to make this stuff better." I did a dual degree in computer science and electronic media arts, and then I stayed for a master's degree in human-computer interaction. Throughout my entire academic career at the university level, I was very interested in how we can make all of this amazing new open source software that's coming out more usable because you have to be pretty technical and pretty in the weeds to make use of it.
These were the days when I believe GNOME 2 was new if anybody remembers those days.
Katherine Druckman: Yeah, absolutely.
Mo Duffy: When I was in my master's program, I was interested in doing this as a research topic. I had a friend who worked at Red Hat, and I kind of just drove out to the Westford office, and I was like, "Hey, can I help? Can I study you and see how you build the software?" Because the idea is that to understand how to design UX for free software, you have to understand how free software developers actually do their work. While they're all over the world, mostly remote, you find a Red Hat office, you have a bunch of Red Hatters co-located. For me and for my academic purposes, it was a great place to go and study in one place over an extended period of time, not just a conference. How did they actually do their work and how can I integrate a UX practice into that?
Katherine Druckman: Wow, that's a really good story. I'm kind of inspired myself now. I have to agree with you. I was also an early user of many of these things. I got my start in the open source world with Drupal, but also I worked for Linux Journal for many years.
Mo Duffy: Oh, wow. Okay.
Embracing Open Source Design Tools
Katherine Druckman: We tried to eat our own dog food. In creating the website, I used things like GIMP and stuff like that on a daily basis. I ran everything on an Ubuntu desktop back 100 years ago. At the time, I too, thought that it needed improvement and I'm very glad that there were people like you to take initiative to make that happen.
Mo Duffy: This is something that I like to talk about in open source. When you have technical people who code, a lot of times that early motivation to code is because they want something to make their own life easier.
Katherine Druckman: Yes, absolutely.
Mo Duffy: I am in the same boat. My entire career, I'm using Inkscape, using GIMP, I'm using Penpot. It's a newer UX design tool. I'm using a Fedora Linux desktop. My whole team focuses on upstream community design work, and we all have standardized on these tools. There are a lot of reasons for that, but I think the most important reason is, yes, there is the dogma of the whole thing. Yes, I do believe in it, but it also makes the practice of design in the open source community more accessible to more people. We've had people in our design community upstream who can't afford a license for proprietary design software.
Katherine Druckman: Sure, absolutely.
Mo Duffy: We just download it from here, here's all our templates, here's all our files, join in the fun, and they can get started. There's no economic barrier. Really, the only economic barrier is their bandwidth. That's pretty much it. I'm sorry guys, I can't solve that for you. I feel that because the developers are able to scratch their own itches by open source designers using the open source tools, they make them better because they have their buddies who are the developers and they can exert a little bit of pressure. Our design team in Fedora has a really good relationship with the Inkscape team.
Martin Owens, the lead UX developer on Inkscape, is actually in the Boston area, not far from the Red Hat office, to be quite honest. We talk to him a lot, and we let him know, "These are the things that are hanging us up. Could you do this? Could you do that?" They're so responsive. That's how the software gets better: People use it, and then they contribute back either issues, or fixes to the community.
The Unique Challenges of UX Design in Open Source
Katherine Druckman: Yeah, that's fantastic. Let's talk about the challenges that are unique to open source.
Mo Duffy: As a designer practicing in open source... Well, just generally, remember I talked about developers coming to open source, scratching their itches? That is something you can kind of do in a drive-by fashion. You can just do a PR, "Hey, I got my little thing fixed." All right, I'm off to the races. I'm done. For UX design, it is not something you could really do in a drive-by fashion.
Katherine Druckman: Right, yeah. There's a lot of planning.
Mo Duffy: You really have to have a depth and you have to have a bit of a tenure with the team, and you have to build a rapport with the team too, because honestly, I feel bad about it, but as a designer, I'm basically telling developers what to do. I'm coming up with a mock-up. I'm saying, "It should look like this. It should function like this. I'm not doing the code. You are." It's really interesting too because honestly, as a person, I absolutely hate politics, but UX is political because you are not the person slinging the code, so you have to build-
Katherine Druckman: And you're not the end user either.
Mo Duffy: No, you're not. You're almost like-
Katherine Druckman: You may be a user.
Mo Duffy: I used to describe it as an ambassador, but you're really kind of a political representative. You're politicking the developers to do things on behalf of the users, and you have to have a strong story and a strong rationale and data to back up what you're trying to convince them to do. I think that's good too. I don't think it's necessarily a bad thing.
Katherine Druckman: No, absolutely.
Mo Duffy: Because developers shouldn't be spending time implementing something that doesn't actually solve a real problem. If you can demonstrate that it solves a real problem and it's going to help users, then that's a reasonable bar.
Katherine Druckman: I remember having that conversation in a previous life. I constantly had to remind myself that the things I was working on weren't necessarily for me. I was working on things for other humans, lots and lots of humans who were not me. It's really important, I think, to put yourself in that head space of, "This is not about me."
Mo Duffy: Exactly. You don't need any fancy tools or fancy processes. One of the things that I personally... I have a stronger affinity to the open source community than the UX community. Sorry guys. The UX community likes to make all these fancy names. Somebody will release a book and they'll come up with some term for some technique, and it's like, guys, you're just playing with Post-It notes. Why did you come up with this fancy term? To understand and to keep the users and what they're trying to do, the users who are not you, what they need and what their problems are in mind when you're building software, just talk to them. You don't need some fancy protocol or whatever framework, you don't need to buy anything. Just talk to them. That's all you need to do.
Katherine Druckman: I think that's so important in all software development. It's just the communication. Everything is really about communication and diplomacy, like you say. Everything in open source is diplomacy at the end of the day.
Mo Duffy: It really is.
Katherine Druckman: You can't get your PR merged if you're not a little bit of a diplomat. You can't collaborate across organizations with many, many companies and all. You have to be a diplomat. It's just a thing.
Mo Duffy: I appreciate that you mentioned that.
Podman Desktop: Bridging Developers and Kubernetes
Katherine Druckman: I wanted to talk a little bit about some specific projects you work on, and I know one of them is Podman. What can you tell us about the work that you do with Podman?
Mo Duffy: I have been working on a tool called Podman Desktop that brings a UI to the Podman experience of creating containers. Our goal with Podman Desktop is to basically shift left developers towards Kubernetes environments because traditional is of course very relative, but say the traditional experience of a developer would be like, you have some containers, you have a pod, you're using Docker Compose to organize things, and then it gets handed off to Ops, and then it gets converted to Kubernetes.
Then you have a bit of a wall that it's getting thrown over. Something happens in production, but you're not the person who wrote or maintains the kube YAML. There's sort of that handoff and that wall in between that makes it a little bit more difficult. With Podman Desktop, what we're doing is, hey, so you have this tool, it lets you run your app in a pod locally using Podman as the engine. It's cross-platform, so you don't have to worry about... It makes a push button simple to set up a Podman machine and you can run stuff on it.
Then once you're comfortable, like, "Okay, I have the app running reasonably," it has tools so you can deploy a local Kubernetes cluster right on your desktop. We have plugins for Kind, we have plugins for Minikube. Then you can take your pre-existing pod on Podman, basically push a button and push it into your local cluster. Now you have a single-node cluster at a Kubernetes environment so you can then see, well, how is the app behaving in this environment? Once you're happy with that, and you may be doing a little bit of a developer inner loop trying to debug things and make sure it's working just right, then you can push it to a remote developer cluster.
It brings the Kubernetes system more left towards where the developer is doing the work. It makes it feel more native and more friendly to them. The UI is done in a way that is very targeted towards developers. It's not trying to be everything to anyone. The main filter for how we design that UI and what functionality we put in it is, will this help a developer?
Katherine Druckman: I love it. I wish more things in life were created through that lens.
Mo Duffy: It is so hard too, by the way to say, "Listen, I'm focusing on this user. I don't want all this other noise, just this user." People are like, "Oh, you got a good thing going. Can you throw this in and that in?" It's like, well-
Katherine Druckman: Clutter. Feature creep.
Mo Duffy: Yes, if it doesn't help the developer, no. It can be so hard to say no, especially in an open source project. It can be so hard. Somebody does a PR and it's like this really great code, but it's not for our user. We have to say no. And it feels really bad. That hasn't really happened in Podman Desktop that I can think of, but I've seen it in other projects too. It can be hard. Again, like you said, it's diplomacy. It's really a people problem.
Katherine Druckman: Yeah. Well, like all things in life.
Mo Duffy: Yes.
Katherine Druckman: I think I have my own ideas, but I'm curious to hear more about yours, about why it is so important to have that more native shift left experience, as you say. Can you go into a little bit more detail about what problems that solves for the developer to make it a little bit more close to home? Because people get into sort of a groove of doing things a certain way, and even though when you're making an improvement and a perceived ease of use solution, you're solving a problem that we think that a person needs, but when they're kind of in that established system and then you kind of move their cheese, there is a little bit of a... I don't know, you can find resistance a little bit.
I wonder how you're solving that problem in a way that you're convincing the end user that their problem is solved, if any of that made sense.
Mo Duffy: Sure. Yeah, it makes total sense. There are two things I'll say about this. The first thing is that when I look at designing interfaces, I'm a little bit of a language nerd. I speak Irish, I've studied Japanese, I've studied Czech. The thing that I love about language learning is when you're trying to learn a new language, it breaks your habits. It's so natural for me to walk around and speak in English and not even think about my speaking English. But here we are in Paris. There are tons of French speakers here. The thing about it is when you're walking around outside on the streets, you see signs in French, there's no English. When you overhear people, you're walking by, they're speaking French.
It's sort of slowly habituating you to the fact that, wait, there's another language, and hey, people actually speak it, and I can do things with it. In the same way, you can shift the Kubernetes way of doing things to the developers in the place that they're doing it. For Podman Desktop 1.8 we just released this week, we've surfaced now some new UI in the tool that will let you show for your local cluster, let you show your deployments, services, ingress and routes. It'll also read in your kube context. You can switch between kube context. In that way, because they're already doing their work locally with their pods on Podman Desktop, they'll see this new information in the same way you're walking around Paris.
I don't know about you, but for me, in my hotel, I have learned the French words for push and pull just from the doors when I'm trying to get to the hotel in the morning. When you see it and you can encounter it on your everyday workflow you were going to do otherwise, it habituates you to it, and you start learning. The best way to learn something that's new, that breaks a habit that you have in place, is for you to learn it just in time when you need it. That's a principle we're trying to take here, is when the developer is already developing their tool, can we surface this alternative method of, "Hey, you can use kube YAML to make a pod rather than use Compose."
Then when you have it as kube YAML, you can push it to a cluster. It makes it more natural, and it's surfacing those tools right when the developer is ready to use them and open to learning. That's how you do a little bit of a shift. It can be difficult. One of the challenges that I have spoken about with end users out in the community, I'll give an example. I know somebody who works at a government agency and they have a Kubernetes cluster and they don't have a lot of usage of it. They're struggling to hire developers that have Kubernetes experience because it's a state government.
They don't have huge salaries to hand out. All of the salaries are regulated, and Kubernetes developers can be very expensive. Their tact is, why don't we get fresh grads in and we'll train them up? The reason I came to talk to this individual, because they were excited about Podman Desktop because this is approachable for somebody. The reason I bring this up, it's because somebody who's graduating fresh from college, they have no preconceived notions of how things should be done. It's sort of a blank palette, and we can train them up in the cloud native ways from the start to build an app.
Katherine Druckman: I love that.
Mo Duffy: We don't have to break any habits on that.
Starting in UX Design
Katherine Druckman: I love that education angle. I think we talk to a lot of the same people who are having the same conversation, and I do love the idea of training up a next generation of open source developers and making things easier from the start, making security easier, going cloud native easier, making all of these things just out of the box... The default is the easy way. I do love that idea. I wondered if you had any thoughts just on a personal level about people who want to go into your field of UX and particularly open source. It's fantastic that you have the background that you do combining the technical field with the UX education, but I also wondered if you had advice for people who may be making a career change or don't have that same background and are looking for a path into this field?
Mo Duffy: What I advise people who ask me, "Hey, you're a UX designer. I'm kind of interested in that. Could I do that too? How would I get started?" I think it starts with... I'm actually not sure which it starts with, but I'll say having an interest in the technology and having excitement and passion for how it can change human lives.
This is something maybe could lead in to the next topic, but a technology is just a tool. What UX designers bring to the table is, “What is the human problem this is solving?” People do not want to sit in front of their computer for hours, just spending all this time and luxury in your application. They want to go in, get it done, get out, go home to their kids, have a nice meal. They don't want to spend all this time in there. So many people don't realize this when they make these tools and they have all this elaborate stuff. I think that if somebody wants to get started in the field, develop that empathy, you can do this by going into an open source project and trying to identify for that community, how is this impacting the end users?
I'll throw out an easy example of something that anybody could do if they're trying to dip their toes in the field. I would talk to the community and I would ask, "Hey, so what is your vision? What is your roadmap for this tool? What are the specific problems and the users that you want for this tool? What problems do you want to solve?" Then come up with a list of, and you do this with the team by the way. Don't go off on your own and do it. You have to build those relationships because like we said earlier, this is a diplomatic process. This is not like a lone wolf coming in from left field and telling the developers, "Here's how you fix all your stuff." It's a group effort.
So, go in and build the relationships with the developers. Come up with a list. Honestly, it could be five things. If a user is going to use this tool, these are the five things they should be able to do. Then just go out and find users. You can go into the Discord communities or the Slack communities or whatever communities have been built around that project and just ask users. Honestly, I prefer doing online video calls, but you could do chat sessions, you could do anything that the end user is comfortable with. Book a half hour with them and just walk them through "Okay, so here's task number one. Can you tell me how you do this in this tool? Are you able to complete it?"
You get a wealth of information just from asking five questions for the five most important user tasks for the tool. Then you can do that, you can talk to five users, you could talk to 10 users, and then just go through the results and let the development team know, "Hey, so you have these five tasks. I talked to five users. None of them could complete task five." Just start talking to them about "Here's the feedback, here's the specific detailed feedback we got from the users when they attempted to use this feature," and collaborate and brainstorm with them.
You don't want to jump to solutioning super quickly because developers got to develop.
Katherine Druckman: Yeah, got to get stuff done.
Mo Duffy: It's your job as a UX practitioner to constantly be focusing on what the user's trying to do. "Hey guys, they're trying to do this task number five," and then solution A, solution B, solution C. Be involved in the discussion, have a seat at the table and work out a solution, and then coach the team on actually bringing it in. I think anybody can do this. I don't think you need a fancy degree. I don't think you need to read 20 books about UX to do this. It is literally talking to people, and we all know how to talk to people.
Katherine Druckman: Well, that's a topic for another episode.
I think a lot of development teams may be smaller and don't have the luxury of having a dedicated UX expert to work with and will find themselves in the position of having to make it up for themselves. I've been in that position when you're having to do everything, and I actually do have an art background, so I tried to pull from some of that. Ergonomics, German kitchens of the 1930s, when you kind of think in terms of human interaction with the world around them, which translates to the virtual world hopefully.
I wonder also, what advice do you have for those types of groups? You're not necessarily an expert, but you do have to put yourself in the position of your user to try and meet their needs. Maybe you're working on a fledgling project, maybe you just don't have a big team.
Mo Duffy: Honestly, I think the same principles apply. I will say, this is my own personal take. I'm sure folks will argue with me, and that's totally cool. It's interesting. Related to my education, I studied computer science, electronic media arts, and I tried to do both classes during... It was a four-by-four schedule, so I tried to do two computer science classes, two electronic media classes each semester. My brain could not do it. I could not be in both places at once.
Katherine Druckman: That's interesting.
Mo Duffy: What I ended up doing was all computer science one semester and then all electronic media the other semester. I did much better. I felt like I was getting more out of the material. I felt like I was progressing a lot faster. The challenge there that I would pose here is when you're the person writing the code, it's really hard to also be the person designing how the interface works. It's similar to building design. You'll have a civil engineer and you'll have an architect, and they're separate roles for a reason. If you're the person writing the code, sorry, I do do a bit of coding, so I don't mean to be mean or anything, but man, it's so much work to implement it that way. I'm just going to take a shortcut. Sorry, users.
The way that I think about it sometimes is if you write the code to do a certain thing, and yeah, it's a lot of work for you as the developer, that one thing that, say it costs you an extra four hours in development time, that will exponentially decrease the amount of effort that the user will have to do. You have a lot of power as the developer in that relationship, and you have your own needs that you bring to the table. It can be very easy to sit back and say, "I don't think I want to spend an extra four hours on this," and then the effort gets passed on to all of your users' time, however many users you have.
When you have a designer as a separate representative of the users involved, that makes the power relationship there a little bit more fair in that the users have an advocate who is not at bat to actually do the implementation work. You can have sort of a collaboration and a back and forth and weighing pros and cons. That's a little less self-contained. The thing is, again, people know how to talk to others. People know how to think through this stuff. If it's a small team, say there's three people, you could do a relationship where you say, "Well, hey, we have feature one we want to work on. Hey Person A, you're the development lead. Person B, you're going to be acting as the user advocate for this feature."
You could just trade off or pair off on that stuff. A developer can totally do that, but I would just always recommend for this feature X, try to be in one bucket or the other. Don't try to do everything in one brain.
Katherine Druckman: Narrow your focus a little bit.
Mo Duffy: Yeah.
Katherine Druckman: Yeah, that makes a lot of sense to me. Do you remember by any chance a woman named Kathy Sierra?
Mo Duffy: I do. She gave an excellent keynote at GUADEC.
Katherine Druckman: I was going to say South by Southwest.
Mo Duffy: South by Southwest too.
Katherine Druckman: It was probably the same one, and then she kind of disappeared. That's a horrible story about being a woman in tech. I remember something very clearly from her slides, and I've carried this with me since 2008 or whenever I saw it, and it was a slide, and it said "Well, what do you think your users are doing?" And it's a person with glasses poring over a manual. What they're actually doing is giving you the finger. I feel like that kind of is the essence of user experience to me.
Mo Duffy: Yeah. Pretty much.
Katherine Druckman: Anyway.
UX in Software Development and Adoption
Mo Duffy: All the decisions that you make as the person creating the software, you're pushing that cognitive load onto your users instead of taking it yourself. When you're developing software, you have all this data. The lazy way to create a user interface is just plop it all on the screen. It takes effort to actually sift through that and think through. When I talk about UX design sometimes, I talk about it being theatrical. There's an opening, and then there's scene one, scene two, scene three.
Katherine Druckman: It's like storytelling.
Mo Duffy: Exactly. You have to surface just the right bits at just the right time when the user needs it. It's a lot of work.
Katherine Druckman: I love that analogy though. That's absolutely the case. Yeah, you don't need to see this button until you need the button.
Mo Duffy: Exactly. And if you don't do that work, you are pushing that work onto your users. Like I said, the person, the team that's making the software, that's a finite set of people, but when you're unleashing it, and I'm sorry, I used the word unleashing, maybe that's not fair, but when you're unleashing it on the open source community, that's a massive number of people to have a set of cognitive load pushed on them. Whereas if you had just done it yourself, you would've saved them all the effort. Also, you would've driven in better adoption and affinity with your application and it would be more successful because people don't want to work. They're lazy.
Katherine Druckman: Yeah, that's true.
Mo Duffy: Just let me do the thing I want to do.
Katherine Druckman: Yeah, that's absolutely true. Well, this has been delightful, number one. I love getting to talk about this stuff because I so rarely do. Is there anything that you wanted to talk about that I didn't ask you?
Leveraging AI for UX Design and Beyond
Mo Duffy: Yes, and it's sort of related to one of the topics that's penetrating KubeCon today, which is AI.
Katherine Druckman: Oh, yes. Of course. How can I forget AI?
Mo Duffy: It's all good. The thing that I wanted to talk about is as a UX designer, I think the people who practice UX have a unique perspective on AI. I think AI is really, like we said, about, oh, there's all this data and you have to sift through it, and that's kind of the work of a UX designer, right?
Katherine Druckman: Yeah.
Mo Duffy: I'm not afraid. I'm not afraid.
Katherine Druckman: No.
Mo Duffy: But there's a lot of data out there too that there's no possible way you can get a human UX designer designing what bits of the data should be surfaced. A good example would be error logs. An error log is going to be... It's a time-based thing. It's very environment-specific. There's no UX designer inside the app designing what should be surfaced to the developer to let them know which bit of most importance should be raised to their attention. Could we use AI to do things like that? I see AI as just a tool. It's like a library, it's like an API. You don't do AI to do AI. You do AI to solve a user problem.
Katherine Druckman: Right. Sure.
Mo Duffy: I think if you think of it that way, it maybe reduces a little bit of the fear because again, who wants to sit through parsing error logs?
Katherine Druckman: Sure. Yeah. Yeah, that's a perfect-
Mo Duffy: Let the AI do that.
Katherine Druckman: ... application. Yeah, I like it. I am interested in what AI can do to make people's lives easier. I try to not approach it from that cynical angle that I think a lot of people do. I try. Sometimes it sneaks in, but-
Mo Duffy: When you have the UX approach you're talking about, you're always bringing it back to what's the user problem?
Katherine Druckman: Exactly.
Mo Duffy: What's the user need to solve? I read an article in the MIT Technology Review last night, and they were talking about how just to make it a very human problem to solve.
We have all this data out there of all these research papers on medicines that, for example, could treat cancer, but we haven't done trials. To do a trial and to do all of that is so arduous. There are all these combinations of things that we could use to treat some disease. You could use AI to go through all those papers and figure out, oh, actually this might work. Then it would suggest different combinations of things to try. They were talking about there was a man who was 88, he had a rare form of blood cancer. There was no protocol for treating it, and they used the AI to go through the different possible medications that could work. It suggested a drug that actually worked, and apparently he's cancer-free now.
Katherine Druckman: That's amazing.
Mo Duffy: It's one of those amazing things that it has a clear human impact. It solves a clear problem. That's what technology is at its best.
Katherine Druckman: Yeah, I agree. I think a lot of what people are exposed to in the AI hype cycle is the very large scale, impersonal types of generative AI. Look at all the fake content we can create or whatever it is.
Mo Duffy: Right.
Katherine Druckman: I think thinking in terms of bringing it closer to home, bringing it back to a more personal experience, something that can actually do for you as an individual human, I think that's a more valuable use of this type of technology.
Mo Duffy: Exactly.
Katherine Druckman: I was actually at an event recently focusing on personal AI and what does that mean, and imagining all of the different solutions that one might have. If you had something local, not something global, something local that could just process your own information and do it in a way that respects your privacy and all of those things. Imagine the kind of crud that we all have to sift through. Doing our taxes. Imagine the things that this could solve for us. Anyway, we'll see. We'll see what happens.
Mo Duffy: That would be incredible. I hate doing taxes. It's almost that time that I got to sit down and-
Katherine Druckman: Here, just push a button, go through all of my records on my laptop, and just do it for me. Wouldn't that be great?
Mo Duffy: It would be amazing.
Katherine Druckman: Yeah.
Mo Duffy: Saving human lives.
Katherine Druckman: Exactly. Well, thank you so much. This has been fantastic, and I really appreciate it. I hope people have learned a few things about being a human in technology.
Mo Duffy: Yep. Very important. I appreciate it.
About the Author
Katherine Druckman, Open Source Evangelist, Intel
Katherine Druckman, an Intel open source evangelist, hosts the podcasts Open at Intel, Reality 2.0, and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she’s a longtime champion of open source and open standards.