POSSE 2017 An experience report

POSSE (Professors’ Open Source Software Experience) is a workshop aimed at bringing world-wide professors to discuss how they can improve their CS courses in order to take advantage of free/open-source software (FOSS for short). FOSS is a topic very dear to my heart. When I was a student, I participated in several FOSS conferences and I also used to contribute to some FOSS projects. As a researcher (and, eventually, as a professor) I shifted my interest a bit. Although I’m not coding as much as I would like to, I’m still interested in FOSS. Indeed, some of my research research is about FOSS (e.g., communities, engagement, perceptions, etc). In addition, as of today, I’m a faculty running for tenure, with nearly no previous teaching experience. Needless to say that I was with high expectations for the workshop.

This year the workshop took place at the beautiful Bologna, Italy. This blog post describes my personal yet biased view about the 2 intensive days of chatting with other professors about CS courses, open-source, pasta, and wine. The workshop was a mix of several lectures and group activities. Although I agree that both parts are equally important, this blog post is focused on the lecture part, which I took some notes (I did not have time to write down notes during the group activities).

One of the first advice for professors that want to introduce FOSS in their courses is to inform students upfront that the course will not be a normal one. That is, the professor is not supposed to know everything about the FOSS under study (in fact, depending on the FOSS, no one knows), although, professors have to figure out with students what they do not know — which is perfectly fine. It is important to note that the learning curve is significant for both faculties and students. On the other hand, this approach provide excellent opportunities for technical/non-technical learning. We need to adapt the learning approach, though.

To minimize the learning curve, professors need materials. Good materials can be found at the teachingopensource.org and at the foss2serve.org websites. Take the time to explore them – they have a rich database.

While you learn something new from these websites, think about how students can contribute to open-source. One point that was largely debated is that open-source contributions is not only about code. There are many many ways that one can contribute – code is only one of them. Indeed, in order to be a FOSSer, a student does not even need to commit changes to a repository. A FOSSer can (1) create a blog post, (2) test the software, or (3) answer questions in a malling list. There are, at least, 50 ways that one can contribute to FOSS. Find one that can fit your needs and tell students to do that.

However, we cannot throw a student that does not how to swim in the deep end of a pool and say: swim. We need a scaffold. Some questions you should ask yourself: What we need to do to contribute to FOSS? What are the steps? Forget students! What I have to do? After you figure out, think about how can you teach students to do that?

Since both professors and students are immersing into not well-known waters, it is important to have a contact within the FOSS community, who could provide help. How to find a contact? One way is to observe the community. Examples include: (1) Go to an IRC channel, (2) assign a malling list, or (3) participate in a slack group. After a while, you would be able to answer questions such as: Is this community active? Do they answer novice questions? Can you tell who are the core developers?

If this community seems to be a good one, then it is time to introduce yourself, explain that you have some students that might be able to contribute, describe your goal, etc. Is someone willing to help? Good! No? Do not give up. Repeat until you find a suitable community. If we have success finding good communities, the chances that students succeed should be higher.

Some students have a hard time trying to find meaningful things to contribute during the short term of a course. Some FOSS projects provide labels for “easy” tasks, while others provide Roadmaps (i.e., known features/bugs that the FOSS project want to have done/fixed for the next release). These are good ways to search for meaningful tasks. However, Roadmaps might contain critical bugs. Although the community do want to get them fixed (therefore they might provide good support for the student), such bugs might be non-trivial, requiring students to spend much time in learning (instead of coding) activities. It might be tempting to work on such fancy bugs. However, the suggestion is not to work on the critical path! This might delay the contribution process — and demotivate students.

Another thing to pay attention are the release dates. If there are releases scheduled during the course, contributions might be frozen for a while. Another challenge is related to architectural changes. If that is the case, some contributions might not be needed anymore (e.g., thanks for the fix, but this feature does not work like that anymore). The best way to prevent such problems is by understanding your community. Invest some time to figure out its needs and where it plans to go.

Remember that the goal is to engage students. Therefore, in some classes (e.g., high school, introductory classes), placing a source code contribution is not necessary. In some cases, understanding the steps for contributing might be ideal. In any case, some professors mentioned that the acceptance of a contribution should not be graded. This is out of the your (and students’) control. Instead, students can earn additional credits if the contribution is accepted.

It is important to change the mindset of having everything done before publishing. This not gonna work with FOSS. Teach students to release early and release often. This should be the norm. Also, tell students to avoid risks by working on small problems. One way to start is by working with documentation issues. Remember students that a lot of bugs are not code bugs. Typos are bugs! It is also important to engage students early – do not way for the last minute to provide a patch. How to do that? Create such assignment: get a patch by the end of this week.

After passing the first contribution barrier, prepare students to become independent in the FOSS world. Most of it is done by teaching students how to ask good questions. Rule of thumb: if Google has the answer, it is not a good question. I heard that it is better to have students that ‘‘know how to ask good questions, rather than students with great technical skills’’. The rationale here is that when you get stuck (and you will), you should know where to find help. Finding help, however, is not only about asking for help, but also about asking politely and asking at the right place (or for the right person). That is, communication skills are highly demanded. If you have students such as this one:

Just heard from a student: "I joined CS because I don't need to talk to anybody". What we did wrong?

— Gustavo Pinto (@gustavopinto) July 2, 2017

Remember them: Communication is part of your job!

All in all, I think this approach can lead to significantly improvements, in terms of both technical and non-technical skills. I will give it a try soon (and report the result too, hopefully).

If you have experience teaching CS with FOSS, why not reporting them? I’d love to read.