 So thank you very much for coming Cliff and we're looking forward to your talk. Great. Thank you. Everybody hear me okay? Okay. So mostly I want to talk about why it's important to think about how new people come into your community. To get there I want to give you a little background as to why that's something I care deeply about. Oops or not. So I'm kind of a jack of all trades, master of none. I've done product development, I've done consulting. I've worked with FOSS collaboration tools. Right now most of my focus is I guess you would call open education resources. So I'm involved in two major projects. One focused on helping faculty and students get involved in FOSS for humanitarian purposes. That's the open path project. And the other is something called Pogl which is a very particular style of classroom learning that helps students practice the skills they'll need in open source projects. So I want to acknowledge support from the US National Science Foundation from Google for helping us do that kind of work. On the FOSS side again sort of jack of all trades, master of none. Mostly I've been working with collaboration tools, wikis, content management systems, Moodle obviously as a professor, a little bit of music, lots of different things. So my goals with FOSS have really changed over time. I started using FOSS before FOSS was a term. Then my goal was really to use software to solve problems I had or that researchers around me had. Then in about 2000 I started working with global development teams and doing some consulting with FOSS. So using FOSS tools to help businesses solve their problems. A bit later I came back to academia and now I started thinking how can we use these tools in education. I realized that students needed more experience and FOSS tools could be a way to do it. How can I get students involved in this? And then kind of the most recent shift has been realizing we really need to think much more carefully about how we train students and how we help them think about things. And to be honest I'm kind of uncomfortable in a lecture setting. This would never happen in one of my classrooms but more about that later. So why is this something I think is really important? I can't move around. Got it. Understood. Thank you. Sorry, in my classroom I would be walking all over the place making the people in the back feel uncomfortable. So this is a quote from a marvelous book by DeMarco and Lister. The book is People Where. The quote is, the major problems of our work are not so much technological as sociological. We spend an awful lot of time talking about tools and technologies. That's the easy part, right? The hard part is getting people to work together, keeping track of who's doing what, all of these other things. That's what I as an educator, what we as an academic organization should be really focused on a lot more. So when I talk about skills, I'm mostly talking about these things. Some people call them professional skills, but not just professionals need them. Some people call them the soft skills. I would actually argue they're harder than the hard skills. So my community often calls them process skills, skills in the way you work. So we talk about information processing, critical thinking, all of these skills. I've just added a few examples of how these skills play out in software development. And so my argument when I work with faculty is to say these skills are actually a lot more important to your students than whatever you think you're teaching them about. Software engineering, compilers, chemistry, right? I tell my students half of what you learn your first year is going to be obsolete when you graduate. If you don't have these skills, you can work for two years and you'll have an obsolete skill set. So the sort of thesis of my talk is that every computing student should be contributing to open source. And even further, every student at any institution could contribute to open source. So how many of you contributed to open source projects as students? Wow, much less than I would have guessed. Okay, the people that were students, how many people knew other students at your institution that were also involved in open source? At your university? Within your university? No. A few. How many were at universities where over half of the students in computing contributed to open source? A few. Okay. So that's really where I want to go. So one of the things we did was we started thinking about what are all the ways you could get involved in open source. Those of you that are old enough to remember the Paul Simon song, 50 ways to leave your lover. We came up with 50 ways to be a foster. There's a recording somewhere that we've hidden for legal reasons. But the point is we very quickly came up with over 100 ways that a student with sometimes lots of computing background, sometimes no computing background could get involved in an open source project, make contributions, do interesting things. I think that's really important to think about. So why should students participate in open source? Kind of interested in what people think. Okay, useful job skills, certainly. Ah, connections. Awesome. What was the last word? Learn from others. Collaboration. Yes. So not just code that gets run once and then deleted forever, but code that's used for a long time. Get your dissertation done. Learn how to deal with it. Often in academia the assignment is very specific. All of the tricky parts have been carefully mapped out. Open source is messy. Yes, absolutely. I mean it's absurd. If you were learning a foreign language, would you learn to speak before you learn to listen? Exposure to different technologies and different approaches. Not just technologies, yeah? Yes. So lots of good reasons. So it was interesting, all of the reasons we talked about were reasons that helped students. There are also benefits to FOSS projects and there are benefits, I would argue, to society more generally, right? So the community I'm in is particularly focused on getting students involved in humanitarian projects, disaster management, medical records. We have a group starting to work on food banks for areas where people don't have enough food to eat. That's actually a problem on a lot of campuses in the U.S. So there are lots of benefits there to think about. But another reason to try to bring more people in is to grow the community, the kinds of people that are involved in open source. So we heard a little bit about this from speakers earlier today. We want more different people, different perspectives, more different ideas in our projects. Unfortunately, that often means we need more women because we're in a profession that at least in some countries is very male dominated, not all. So we want to increase these underrepresented groups. Why? Well, I think there are actually several reasons. One is there are historic problems we want to try to overcome. We want to have more people capable of doing these kinds of jobs. It's good for the people. It's good for society. But even if you didn't care about that, it's better for the product. The more different perspectives, the more different ideas, the better you're going to be. I don't want to have a whole talk about how to do that, but I do want to point out that most of the practices that help these groups actually help everyone. Sage gave a great talk earlier. I'm sorry, it wasn't a great talk. It was a talk that inspired and motivated me. Many of the things that help people suffering from imposter syndrome will help everyone in the community. It's like the argument about wheelchair ramps. It's nice if you have a wheelchair. If you've been a parent and you're pushing a stroller, it's nice. If it's icy and you don't want to slip, it's nice. If you're up on the fifth floor of a building and the lift isn't working, that's a problem for everyone, not just some people. So the more we can do these things, the more we can help a larger audience. There's actually a little bit of data to support this. So this was a study. Students participated in a humanitarian open source project. At the end of the course, 63% said it caused me to consider this is a major. 77% said it reinforced my decision. 52% said it caused me to take more courses. What's interesting, though, is the students with less experience got a much bigger benefit from it. The students that already knew they wanted to major, it wasn't going to change their mind. The students that weren't sure, the students that were less confident, the students that might have been suffering from impostor syndrome, big, big difference there. So we talk a lot in fos about icebergs and how the people we see, the public face of the projects are hiding a much larger community that's doing a lot of the work. But I also want to think about this because the students we see involved in open source are also the tip of the iceberg. Often they're the students that are most passionate, that had some connection, that had privilege and that they had the time to get involved, they had more background. We want to try to bring all of these other people into our communities, too. So how do we do this? Well, people have studied this, right? So the general idea is that a community starts with lots of people that maybe use the product, maybe just watch and think about it. A small number of them become users, a small number of them become contributors. Eventually you work your way up. This is not data that I have any source for, but I would argue that this is actually optimistic. 90% passive users, 0.01% core team. So what do we want to do? We want to find ways to help people move up this progression and get involved knowing that they're going to go in other directions, too. People are going to be involved for a little while, they're going to switch to another project, they're going to lose interest, they're going to run out of time and have to back off. Those are all good things. That's all okay. So we often talk about this as a pyramid model and I think that's okay, but the problem with a pyramid is it takes a lot of work to climb up to the top. And I would like to suggest instead we should be thinking about open source contributors as a sales funnel. We're trying to take people that are aware of our product, in this case an open source project, and have them get more interested than have them start thinking about using it, using it, taking action. Take someone that is aware that this is open source, they're interested in contributing, they think about contributing, they actually contribute. We don't want to force people to climb the pyramid to get involved in our project, we want to lead them through a funnel so they can get involved more easily. That's the scarce resource. It's the time and attention of people. Anything we can do to help them do that is a win. Okay, so what are the challenges? What makes this difficult? Why don't all students do this? Limited time? Absolutely. Actually, I was talking to someone yesterday who said in Europe it's actually easier because many European students don't need as much money to pay for colleges as American students do. American students are rushing to graduate. They're working 30 hours a week while they're taking classes. It's very difficult. I'm seeing lots of nodding heads. Don't even know it's an option. When you said lack of resources, I wasn't sure which resources you meant. Yes, so things that help new people get involved and become active in the project. You talked about most of these. I think another challenge is just finding a project you want to contribute to. I think very few people wake up and say, oh, the Linux kernel, that's something I've always wanted to work on. Let me just go dive in. Again, the data shows people start using a project. I was a music major. I started using MuseScore. It does great stuff. There's one thing I wish it did that it doesn't quite do. So I figure out how to use this ticket system and request something. Nobody acts on my request for a year and so I start trying to do it myself. So helping students get through these processes is a challenge. What about the challenges for faculty? If faculty want to help their students get involved in open source? Time? Finding suitable projects? Not having that contact or connection. So actually a lot of the problems are similar. Most faculty have never, they've used open source probably, whether they realize it or not. Most of them have never contributed. Many have never used the tools that open source communities use. There are also curricular issues. Faculty feel like, oh, I have to cover, the book is this thick. I've got to cover this much of the book every day. How am I going to find time for all this other stuff? So I'm part of a large group of people that are working to make this better. The sort of umbrella organization is a site called Teaching Open Source, which is a member of the Software Freedom Conservancy. So our goal is really training and supporting faculty so that they can then support students to get more students involved in these projects for all the reasons we've talked about. So we train the faculty, we build community, we build resources they can use, and we try to connect faculty and communities where it seems like there are good fits. One of the things we do is a workshop program for faculty called POSSI, the Professor's Open Source Software Experience. This was started by Red Hat, I believe, back in the day, and Red Hat has been an enthusiastic supporter all along. The basic idea is faculty spend a month or two doing independent work. We try to introduce them to tools like IRC and Wikis. Then they come together for three days of intensive work, partly learning tools, partly connecting with communities, partly thinking about the pedagogy. How would I use this in my class? How do I get my students involved? And then we hope they can go on from there and use this in their classes, get their students involved, and do new things. So we've run these events all over the world. We've done a bunch at Red Hat and Raleigh. They've been very generous with space. We did one in Vologna, Italy. We did one at Google in San Francisco. We're trying to get as many faculty as we can thinking about using these approaches. Another side of what we're doing is developing classroom materials. Often these are materials we first have the faculty use. So the faculty experience what it's like. Faculty also feel imposter syndrome. I'm new to this community. I don't really know what's going on, but I'm the professor. I'm supposed to be the expert. What do I do? It's very hard for a professor, even though they're in a position of authority to admit to their students, I don't know the answer to this question. It's a collection of materials. Some are very polished. Some are very rough. We're trying to move those forward. This is part of our team at the Google workshop we did. So I want to just walk you through one of the activities that really I think will help you think about this onboarding process. What could projects do to help students get onboard? What can faculty do to help make those connections? This is an activity we do to evaluate a project that you might want to join and get involved in. So we have some overview information. This is mostly for the teacher's reference, not the student's reference. You're going to look at a project. We're going to look at a set of different characteristics, decide whether this is a good approach. So we have some background, and we're trying to give very clear step-by-step directions. Students, especially students that are not the very strongest, most confident students, it's easy for them to get lost and confused. If you say, oh, well, go learn how to use get, figure out where the repository is. You've lost most of them already. So we're trying to be very systematic. So we have a rubric with a set of factors to look for and then sort of scoring to help decide is this a project that I want to contribute to? Is this a project that maybe I should stay away from? So just as one example, if we were looking at the community norms, students don't know what community norms are. So first we explain a little bit about what the norms mean. Then we say, see if you can find a code of conduct. Maybe you can do it. Maybe you can't. It depends on the project. Then go into the forums and look for some actual conversations and interactions. Don't just look for a post and a response. Look for something where there was some back and forth, maybe some disagreement. What did you see? Were people being constructive and respectful and supportive? Or were there people being arrogant and obnoxious and rude? Look at that. Think of that as one factor to consider. So you need to think about licensing. You need to think about the languages. You need to think about the size of the project. You need to think about how active the project is. Sometimes for academics it's actually good to find a project that's almost dead because it doesn't change so quickly. Other times you want a project with lots of people and lots of change happening. So you want to look at these different factors. Again, they come back to the rubric. This has them thinking about all of these different considerations either as a faculty member choosing a project that all of my students are going to work on or as a single student or a small group of students trying to choose a project that they're going to work on. How much time do I have? Awesome. So I want to end just with some suggestions and leave some time for discussion and questions. I guess the first thing I would say to a project is think about how much you can do to support teachers and students. A professor, if they're bringing their class into your project, they need that point of contact. They need someone to talk to. If you don't have the time to help them, please tell them up front. If you do have time to help them, make sure they know who to talk to, make sure they know what they can expect. Please look at your processes and documentation. You'd be surprised how often the install instructions are six months or two or three years out of date. They only work on a particular operating system. They only work if you already understand how to follow them. That's not so helpful for new contributors. Some projects do this. I wish more would flag the tasks that you think a new contributor could do. That's an easy task for the community. It's a very difficult task for a student or a faculty member. I don't know your project. I can guess which tasks are easy. I don't really know. The last thing I would say is first impressions matter. If the first interaction doesn't go well, it's probably over on both sides. Part of what we do as faculty is try to coach students on how to approach the community. We're hoping the communities are thinking about how best to approach the students too. I will stop there. I would love to take questions or share ideas. I would love to hear from people or talk to people going forward. Thank you, Cliff. Applause is great. I was wrong. I think we have time for about three to four questions. We are excited to hear your questions and welcome them. Brian, I think there's space for you to get started setting up. Thank you very much. Two questions but one very quick. How can I set an open source course in my Paris University? If I want to do the same that you do in San Francisco, in the American University, in Paris, how do I do that? Become a teacher of force. So if you want to run one of the workshops for faculty? Yes, in Paris. Talk to me. Okay, I'll come. It helps if you have money. Thank you. The second one is I worked in a French company which is an electrical company and we jumped to open source because our R&D has a lot of line of codes. So for climate change, energy transition, we're trying to jump to open source. We hire a lot of people inside and we push the code on GitHub, but it's not sufficient to ramp the project. How do we ramp the project? I think that's going to be a hard question to answer in 30 seconds. Let's talk later. Hi, you're an established community manager who can help you. Brian, come on up here. Thank you for being patient. Here you go. So I think this is really good. You've given some great examples for projects, what they can do to tag. You've given some great suggestions for students. My experience is that when a student comes in to a project, they're trying to contribute, but there's a lot of labor involved for the project, so there's a lot of both intellectual labor, because usually there's a lot of work to do for any new contributor, no matter what. And then there's emotional labor, especially if it's a new contributor and you don't want...