Open Source Software Development, NYU, Klukowska
Jklukowska (Talk | contribs) (→Experiences and Assessment) |
Jklukowska (Talk | contribs) (→Experiences and Assessment) |
||
| Line 103: | Line 103: | ||
'''Changing projects''' <br> | '''Changing projects''' <br> | ||
| − | At the start of the semester, students perform a project evaluation exercises for several different projects. The goal of these exercises is to develop skills that allow students to recognize projects that 1) are suitable for contributions made by first-time developers, 2) have an active community, 3) have enough of issues appropriate to the students' level, etc. Unfortunately, an evaluation is a fairly passive activity and even students sometimes try to get involved in projects that turn out to be inappropriate for one reason or another. Some groups decide to change the project after they have invested some time into it. This may be a good idea or a bad idea and the instructors should be involved in making such a decision. In some cases, students might be simply overwhelmed by the initial steps and hope to change to something that may seem more beginner-friendly (although, there is never a guarantee that this will be the case). In other cases, the response (or lack of it) from the community or difficulty with installing development environment might be clear indicators that students will not be able to succeed and they should not be spending more time on such a project. | + | At the start of the semester, students perform a project evaluation exercises for several different projects. The goal of these exercises is to develop skills that allow students to recognize projects that 1) are suitable for contributions made by first-time developers, 2) have an active community, 3) have enough of issues appropriate to the students' level, etc. Unfortunately, an evaluation is a fairly passive activity and even students sometimes try to get involved in projects that turn out to be inappropriate for one reason or another. Some groups decide to change the project after they have invested some time into it. This may be a good idea or a bad idea and the instructors should be involved in making such a decision. In some cases, students might be simply overwhelmed by the initial steps and hope to change to something that may seem more beginner-friendly (although, there is never a guarantee that this will be the case). In other cases, the response (or lack of it) from the community or difficulty with installing a development environment might be clear indicators that students will not be able to succeed and they should not be spending more time on such a project. |
| Line 109: | Line 109: | ||
------------------------ | ------------------------ | ||
| − | Students work in groups of 2-5 for the last several weeks of the semester with the goal of contributing to a single existing open source project. | + | Students work in groups of 2-5 for the last several weeks of the semester with the goal of contributing to a single existing open source project. |
| + | In the past two semesters, almost all groups were able to make accepted contributions to those projects. | ||
| − | In the | + | In the first offering of this course, there were eight student groups working on eight different projects. Seven of those groups were able to make contributions to open source projects. One group chose to work on a plugin for an application that was not completed by the time the semester ended. One of the groups that made contributions did not have those contributions merged into the actual project by the time the semester concluded. One group changed the project after the initial attempt of reaching out to the community of their first-choice project; another group changed their project after a couple of weeks of unsuccessful attempts at working with the code base. |
| + | |||
| + | In the second offering of this course, there were eleven student groups working on ten different projects (two groups worked on the same project but independent of one another). All groups were able to make contributions to the projects. Several groups worked on writing documentation and translations for the projects that they were involved with. Students from one group were asked to join the maintainers for the project on which they were working. Two groups considered changing the project after some initial unsuccessful attempts, but eventually stayed with their initial project and were able to contribute to it. | ||
== Notes to Instructor == | == Notes to Instructor == | ||
Revision as of 21:20, 26 December 2019
Overview
| Course | Open Source Software Development (OSSD) |
|---|---|
| Institution | Courant Institute of Mathematical Sciences, New York University |
| Instructor(s) | Joanna Klukowska |
| Term | First offered Spring 2018, course website with 38 students. Revised and improved for Spring 2019 and Spring 2020 semesters. |
| Course Overview | This course prepares students to become active participants in open source projects. It begins with an overview of the philosophy and brief history of open source development, followed by an in-depth look at different types of open source projects and the study of various tools involved in open source development. In particular, it covers the collaborative nature of open source projects, community structure, version control systems, licensing, intellectual property, types of contributions (programming and non-programming) and the tool-chains that enable such contributions. The students are expected to contribute to existing open source projects. |
| Course Length | 15-week semester |
| Student Characteristics | This course is an upper-level undergraduate elective. The first time this class was offered, there were 38 students. |
| Prerequisites | Familiarity with a programming language for the chosen FOSS project. Basic familiarity with command-line tools and a version control system. Formally: Computer Systems Organization course (required prerequisite for all electives). |
| Infrastructure | The class meets twice a week for 75 minutes each time. In general, one of the class meetings will consist of discussions of the reading assignments and/or guest speakers, and the other class meeting that week will be for learning activities, project status updates, and presentations, or time to work on the project.
The use of specific software and technologies depends on the chosen FOSS projects. The instructor should have a GitHub organization (or equivalent) to which all students are added at the start of the semester. The students should have the right to create repositories within this organization. Students should be able to bring their computers to class meetings. |
Learning Objectives
Students will gain experience in:
- understanding the origins and implications of open source development;
- interacting with a community of developers and users;
- managing code using a version control system;
- reading/modifying/testing within a substantial existing code base;
- recognizing the ethical, legal and social implications of computing.
Course Deliverables and Assessment Methods
Students are graded based on
- participation (10%),
- contributions to open source projects (40%),
- quizzes and two exams (50%).
The types of graded activities are
- Weekly blog posts. Students are required to make weekly blog posts containing answers to posed questions and reflections about readings and invited speakers. Counts towards participation.
- Participation in class discussions. Students are expected to actively participate in class discussions about assigned readings, course activities, invited speakers' lectures, etc. Counts towards participation.
- Small individual contributions. Students are expected to make a total of 20 small individual contributions. These include (but are not limited to) course website contributions, Wikipedia (and other Wiki projects) contributions, OpenMaps contributions, etc. The contributions to code projects can be in the form of comments on existing issues, reporting new issues, documentation edits, code fixes to reported issues. Counts towards contributions to open source projects.
- Team project contributions. Students spend the last 6 weeks of the semester working on a team projects. Their individual contributions to the team effort count towards their own grade. Counts towards contributions to open source projects.
- Quizzes. Students are given a couple of quizzes during the semester. Counts towards quizzes and two exams.
- Midterm and final exams. Students take a midterm and a final exam. The two exams are open-computer. Students are expected to evaluate open source projects, understand bug reports, understand commit diffs, as well as be able to answer more theoretical questions. Counts towards quizzes and two exams.
Course Outline and Materials
The day by day outline for the Spring 2018 instance of this course. The day by day outline for the Spring 2019 instance of this course. The day by day outline for the Spring 2020 instance of this course. (in progress)
Course materials (slides and activities) are available at OSSD materials repository.
Foss2Serve activities used:
Experiences and Assessment
No formal pre- or post-surveys were performed in this course.
This section is based on personal reports by students made during workshop days and final presentations, and on students' success in making contributions.
Student Expectations and Experiences
Creating an open source project vs. working on an existing project
One of the major objectives of this course is to give students the experience of working on a large third party software base and interact with the community that maintains the project.
Some students come into this course hoping that they can create their own open source project and are disappointed when they learn this is not the case. The reasons they cite for wanting to work on their own project are: 1) being in charge of all the code, 2) creating a large project that can be included in their portfolio, 3) not wanting to deal with existing communities. Most realize the benefits of working on an existing project after the initial discussion, but not all.
Selecting large cool and fast-moving project to work on
When students select projects to work on, they often start with the large popular projects that are widely used. There are two reasons for this: 1) students are familiar with those projects, 2) students view those projects as prestigious and contributions made to such projects seem more significant. Large active projects have their benefits for first contributors, but they also have some major drawbacks. Such projects usually have very active communities and it is relatively easy for the students to get responses. On the other hand, the very active community also implies that many issues (especially the easier ones) get resolved quickly leaving students with not much choice of the issues to work on. In the past, several student groups realized that picking such a project was a mistake and they would have had a much easier time working on a project if they picked one that is smaller and not as fast-paced.
Large vs. small contributions
Most students have high expectations of what they will be able to accomplish when they start the class. They expect to be able to make significant code contributions (i.e., implementing a new feature or adding something that involves on the order of hundreds of lines of code). They do not see much value in smaller code contributions, in contributions to documentation or in bug gardening (commenting on the existing issue). Students tend to get frustrated with the small contributions and need regular reassurance and reminders about the importance of such contributions. Some open source communities are very good at stating appreciation for all contributions when they are merged, but that is not always the case.
Interacting with the community
Interacting with communities of other developers who are not just other students is one of the largest challenges for students in the class. Many groups attempt to actually solve the problems before they reach out to the project communities rather than trying to get feedback and advice from the more experienced developers or people more familiar with the project in advance. This is somewhat to be expected, but instructors need to constantly remind students about the importance and necessity of reaching out to the community before spending any significant amount of time on solving issues. Ultimately, most student groups report on successful communication and positive experience with the project community. Many of them mention that, in retrospect, they wish they had reached out to the community sooner.
Changing projects
At the start of the semester, students perform a project evaluation exercises for several different projects. The goal of these exercises is to develop skills that allow students to recognize projects that 1) are suitable for contributions made by first-time developers, 2) have an active community, 3) have enough of issues appropriate to the students' level, etc. Unfortunately, an evaluation is a fairly passive activity and even students sometimes try to get involved in projects that turn out to be inappropriate for one reason or another. Some groups decide to change the project after they have invested some time into it. This may be a good idea or a bad idea and the instructors should be involved in making such a decision. In some cases, students might be simply overwhelmed by the initial steps and hope to change to something that may seem more beginner-friendly (although, there is never a guarantee that this will be the case). In other cases, the response (or lack of it) from the community or difficulty with installing a development environment might be clear indicators that students will not be able to succeed and they should not be spending more time on such a project.
Students' Success/Failure
Students work in groups of 2-5 for the last several weeks of the semester with the goal of contributing to a single existing open source project. In the past two semesters, almost all groups were able to make accepted contributions to those projects.
In the first offering of this course, there were eight student groups working on eight different projects. Seven of those groups were able to make contributions to open source projects. One group chose to work on a plugin for an application that was not completed by the time the semester ended. One of the groups that made contributions did not have those contributions merged into the actual project by the time the semester concluded. One group changed the project after the initial attempt of reaching out to the community of their first-choice project; another group changed their project after a couple of weeks of unsuccessful attempts at working with the code base.
In the second offering of this course, there were eleven student groups working on ten different projects (two groups worked on the same project but independent of one another). All groups were able to make contributions to the projects. Several groups worked on writing documentation and translations for the projects that they were involved with. Students from one group were asked to join the maintainers for the project on which they were working. Two groups considered changing the project after some initial unsuccessful attempts, but eventually stayed with their initial project and were able to contribute to it.
Notes to Instructor
This course has been offered once so far. It will be revised before the next offering in spring 2019. The revisions will be based primarily on student feedback and instructor experience. (See the Moving Forward section for some directions of revisions.)
Feel free to contact me with any questions regarding the materials and the structure of this course.
Moving Forward
The course will be revised before its next offering in spring 2019. Some of the changes suggested by students and/or instructor:
- start working on projects earlier in the semester (not necessarily "real" projects, but maybe another type of the website project)
- create a list of "easy for beginners" projects
- reorganize order in which topics are covered
- go deeper into how version control works
License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
.
Materials linked to by this page may be governed by other licenses.
