Localized Open Source Collaboration in Software ...

Localized Open Source Collaboration in Software Engineering Education Kevin Buffardi Computer Science California State University—Chico Chico, California, USA [email protected] Abstract—Involving computer science students in open source software projects provides opportunities for them to contribute to real products with more authentic scope than typical computer science assignments. However, the environment of collaborating with external, distributed teams also poses unique challenges and may distance students from the potential for valuable, direct contact and mentorship from software professionals. In addition, while the technology industry continues to grow, smaller communities have a vested interest in growing a culture for collaboration between students and local software developers. We formed a local open source organization to collaborate on a product by combining efforts from students and professionals. This paper describes the localized free and open source software (LFOSS) organization and reports initial findings from software engineering students’ involvement. Keywords—computer science education; software engineering; industry collaboration; free and open source software (FOSS); humanitarian free and open source software (HFOSS); motivation; team projects.

I. INTRODUCTION Teaching software engineering in traditional educational settings poses the challenge of teaching principles and practices with limitations imposed by academic calendars and budgets. In particular, common fifteen (or fewer) week academic terms restrict students from producing large-scale projects from scratch even when an entire term is dedicated to a single project. Consequently, students in computing disciplines may not be exposed to projects with long enough lifespans nor large enough scale to appreciate software qualities such as maintainability and reusability. Meanwhile, learning software development methods and conventions in a classroom setting alone may feel contrived and detached from actual professional applications. A hindrance of contemporary computing education is that programming projects usually produce “toy applications”— those with little practical use outside of the classroom and whose lifespans rarely extend past the academic term in which they are assigned. However, in an effort to mature from “toy” to extensible and useful software projects, some software engineering instructors advocate incorporating Free and Open Source Software (FOSS) projects [1]. These projects offer publicly available code where students can often contribute to

software products that aim to solve real problems and will continue to be used and maintained beyond the completion of school calendars. The following Background section discusses general advantages and challenges to integrating FOSS projects in the classroom. In Chico, California—a city with a population of approximately 100,000 and with no Fortune 500 software companies [2]—we organized Chico Open Source Consortium (COSC) to help bridge a disconnection between the university students and the local software professionals. Independently, both students and professionals had expressed frustration of a missing “technology culture” or “software community” despite the resources available. COSC formed as a localized FOSS organization comprised of a professor and twelve software professionals from three companies within the city. With the opportunity to engage students with local software professionals on a FOSS project that could have local impact, students in an upper-division software engineering class were given the option to use this project as their semester-long team assignment. Meanwhile, students were provided the opportunity to choose their team projects, including options to contribute to remote FOSS projects or to propose their own products. We used surveys to gauge students’ experiences with their respective projects at the end of the term. In this paper, we compare student experiences and opinions from a variety of projects and discuss implications of local and remote FOSS collaboration. Lastly, we identify other benefits and lessonslearned from the first semester of student collaboration with a localized FOSS organization. II. BACKGROUND Thanks to the contributions of worldwide software developers, many Free and Open Source Software (FOSS) products have gained popularity, including Mozilla Firefox web browser [3]. Just like the commercial software it often competes against, FOSS products require software design, development, validation, and maintenance with care not normally afforded to traditional educational computer science assignments. Consequently, introducing FOSS projects to software engineering students exposes them to challenges like those they will face as professional software developers. In

addition, by collaborating with the FOSS community, students potentially gain insight and mentoring from more experienced developers. Nevertheless, involving students in FOSS projects also introduces new challenges, such as working with geographically remote (non-classmate) collaborators whose active participation and communication in the project may be unpredictable. However, despite its challenges, there are strong pedagogical and curricular rationales for using FOSS projects in software engineering courses. Auer, Juntunen, and Ojala describe FOSS projects as a viable application of constructivism learning theory. Constructivism explains learning as a processes of building (or constructing) new knowledge based on connecting new information to learners’ prior knowledge. Additionally, project-based learning contextualizes learning new skills by directing students to solve real-life problems. Experts (i.e. experienced software developers) may scaffold students’ learning by following an apprenticeship model whereby the novice students gradually develop and adopt the experts’ skills through mentorship [4]. However, Auer, Juntunen, and Ojala acknowledge that connecting suitable projects with experienced software developers can be challenging. Meanwhile, In an effort to connect students with “education-friendly open-source projects,” the Repository for Open Software Education (ROSE) collects a list of projects that may be suited for classroom use [5]. Moreover, the Humanitarian Free and Open Source Software (HFOSS) Project advocates contributions to humanitarian projects that “intrinsically benefit a non-profit organization pursuing some kind of public-service mission” [6]. As an example, they submit Sahana, an application to help manage disaster relief. However, the potential benefits of HFOSS extend beyond the altruistic nature of the projects. ABET accreditation criteria specify that student outcomes include “an ability to analyze the local and global impact of computing on individuals, organizations, and society” [7] and involvement in HFOSS certainly lends itself to analyzing its social benefit. In addition, the HFOSS Project reports that experience with HFOSS influences positive perspectives of computing majors and careers, particularly among students with less programming experience [8]. An preliminary experience report also suggests that HFOSS Projects could help recruit underrepresented minorities in computing who may have a stronger interest in “applications that benefit society” [9]. If true, integration of HFOSS in computer science curricula could begin to address the lack of diversity in the discipline, particularly concerning the disproportionately few women. III. METHOD A. Localized Free and Open Source Group After talking and identifying a mutual desire to organize collaboration between software engineering students and professionals in the local area, the a group of twelve individuals formed through existing professional and person

networks. The group comprised of the software engineering professor and eleven professional software professionals who worked for three different employers in Chico, California and named itself the Chico Open Source Consortium (COSC). Over the summer, COSC met and discussed project ideas that we thought would be useful to their respective companies as well as to the general software developer population. Together, COSC brainstormed the idea for BossyUI, a web toolkit that would include a collection of widgets (common components used on websites, such as calendars and data grids) that could be reused and adapted for different web pages with adaptable visual styling and automatic data binding. The idea for BossyUI developed from a common appreciation for existing web toolkits like Bootstrap [10] and jQuery [11] while avoiding frustrations and limitations that the team found with existing products. In addition to identifying BossyUI as its first FOSS project, COSC set expectations for the core members of the team. COSC scheduled a weekly 1 hour meeting at which the members would share updates and discuss issues with the project. In addition, each member agreed to devote 2 hours per week to the project. In recognizing the value of the project, two of the three employers agreed to donate their employees’ 2 hours per week workload so that they could support the project. Once the product had been identified and the COSC team solidified, the next task was to find software engineering students who wanted to collaborate. B. Student Teams In an upper-level, undergraduate software engineering course, teams of students were assigned a semester-long project to practice and demonstrate the software development techniques taught in lecture. According to the suggestion that ideally, students’ involvement in FOSS should be voluntary [4], we gave the teams the option to choose their own projects. Although HFOSS shows promise of attracting new audiences, we recognize that different students may have different motivations. In particular, a student with an entreprenurial motivations may be more interested in creating a commercial product that is not freely-available to the public. Accordingly, we allowed teams to either identify an existing FOSS project or propose an original product to maintain on an either public or private repository. During the first week of the semester, students formed groups of 3-7 members based on the projects and technologies that interested them the most. Altogether, there were 75 students divided into 16 teams. Three of the teams (n=17) chose to pursue original commercial products in which they could keep their code private within the team (and overseen by the professor). Eight teams (n=41) also identified unique products that they wanted to develop but without aspirations to profit from them and consequently chose to make their products free and open source. One team (n=4) chose to contribute to Spyral, a library specific to the XO “One Laptop Per Child” non-profit initiative [12]. Spyral was an existing library but its original authors had identified new features that the software engineering students could add to it.

Finally, three teams (n=13) chose to contribute to BossyUI, the COSC project. Each of the three teams needed to produce independent deliverables for the class (since teams belonged to different sections of the software engineering course). Consequently, with some guidance from COSC, each team identified a subset of the BossyUI widgets that they would work on. Once the semester began, the student teams were given prominent roles in developing the widgets, while the COSC team agreed to mentor the teams and to help provide specifications. Effectively, the COSC team became both clients and technical supervisors for the student teams who assumed the lead in development. C. Course Overview The software engineering class used for this project is a upper-division class for computer science majors after they have completed the Introduction to ProgrammingProgramming 2-Algorithms and Data Structures three-course sequence. Software engineering concentrates on students learning Agile software development methods, version control, testing, software quality metrics, and design patterns. Teams were required to have (at least) weekly meetings and demonstrate that their software has been designed appropriately and validated thoroughly. The teams presented their product at the end of the term and are assigned team grades (with adjustments made when the instructor deems necessary due to inbalanced contributions and peer-reviewed ratings). Every team’s code was maintained in their own GitHub [13] repository, which tracks each individual members’ code contributions through version control. At the end of the term, there was also a project showcase on campus that was open to the public so teams could demonstrate what they contributed. D. End-of-Term Survey At the conclusion of the semester, students were asked to complete a survey to summarize their opinions, expectations, and experiences with their team projects. The survey included the following questions: • Outside of lecture and lab, estimate how many hours you spent per week on your team project. • (T/F) I plan on continuing to contribute to my team project after this semester is over

• (T/F) What I have done in Computer Science and Software Engineering has made a positive impact on the world. The survey had 66 (88% of 75) responses and students identified to which team they belonged so their responses could be associated with what type of project they worked on. IV. FINDINGS The team projects were grouped into four categories: commercial, HFOSS (Spyral project only), LFOSS (localized FOSS BossyUI project only), and FOSS (open source projects started from scratch not categorized as HFOSS nor LFOSS) and survey responses were aggregated accordingly. First, we compared the responses for the estimated amount of time spent per week and the true/false questions, as shown in Table I: TABLE I.

Category

REPORTED HOURS PER WEEK, EXPECTATION TO CONTINUE, AND POSITIVE IMPACT Hr/Wk

Continue

Pos. Impact

Commercial

M=6.86 sd=4.30

64%

93%

FOSS

M=8.17 sd=7.39

36%

72%

HFOSS

M=3.63 sd=1.60

100%

50%

LFOSS

M=4.04 sd=2.57

75%

83%

In Table II, we summarize the Likert scale responses (1 strongly agree to 5 strongly disagree) by category for each question: expectations for other programmers to use the code, expectations to become commercial product, and serving school, local, and international communities. TABLE II.

LIKERT SCALE RATINGS AGGREGATED BY CATEGORY

Category

Other Prog

(M, sd)

Comm

Serve School

Serve Local

Serve Intn’l

Commercial

3.57, 1.34

2.43, 1.45

3.21, 1.47

2.36, 0.93

2.50, 1.22

FOSS

3.58, 1.02

3.78, 1.24

3.11, 1.24

3.11, 1.19

3.22, 1.27

HFOSS

3.00, 1.41

4.50, 1.00

4.00, 0.82

4.25, 0.50

2.25, 0.50

• I believe my project can help serve my school (and/or affiliated groups)

LFOSS

1.50, 1.00

3.58, 1.68

2.25, 1.14

1.83, 0.94

2.25, 1.06

• I believe my project can help serve the local community

When analyzing these findings, one must keep in mind that this study was exploratory and not intended to explicitly test hypotheses. There are several limitations and confounds that would make any attempt to generalizable conclusions

Rate the following from 1 (Strongly Agree) to 5 (Strongly Disagree) • After the end of the semester, I expect other programmers (bsides my team and instructor) to use my project’s code • After the end of the semester, I expect my project to become a commercial (for sale) product

• I believe my project can help serve national or international communities

inappropriate from this data alone. First, the sample size for the Commercial, HFOSS, and LFOSS categories were very small and consequently, the aggregated data could be dramatically skewed by even just a single student’s response. Perhaps even more importantly, one must keep in mind that the students chose their own projects so the results are confounded by any personal characteristics that may accompany the selection bias. In particular, we anecdotally observed that in general, the students who chose either Commercial or LFOSS projects tended to be stronger selfstarters and generally higher-motivated (to either create a profitable product or contribute to a FOSS project while networking with professionals). While these confounds hinder the experimental design of comparing end of term attitudes, they also illustrate the attraction that both commercial and LFOSS projects have to students. While we will continue to monitor the lifespan and activity of these projects for future longitudinal studies, it is also worth noting that two of the three commercial projects have publically released their products (one as a mobile phone application and the other as a website) and that BossyUI (the LFOSS Chico Open Source Consortium product) is preparing its initial release for Summer 2015. Unfortunately, Spyral (the HFOSS project) was trumped by a similar product that rendered it obsolete for all practical purposes. Although the HFOSS team met their goals for the semester, the parent product itself unexpectedly was abandoned approximately at the same time the semester was concluding. The exact timing and communication to the HFOSS student team is imprecise so we do not know if it influenced their survey results. We also observed several valuable outcomes from the LFOSS project. Foremost, one of the students from an LFOSS team was recruited and hired as a paid intern as a direct result of his interaction with the professional developers on the COSC team. That networking and mentoring between the LFOSS students and the COSC was very positively received by both sides. Although the HFOSS students had mentors to guide their project, the weekly in-person interaction between the LFOSS students and COSC seemed invaluable and unmatched. Anecdotally, we noticed the LFOSS students mature most distinctively as software developers as they adopted the habits and the language of their professional mentors. From the first semester of this study, we are inclined to believe that the in-person interaction of LFOSS projects may offer more impactful learning experiences than collaborating with a distributed team can. These promising anecdotal observations give us reason to continue studying the impact of LFOSS projects. Although the preliminary data must be accompanied with caveats of multiple confounds, the general trends seem to suggest that options to pursue both commercial and LFOSS may compliment HFOSS opportunities for students with different motivations. Nurkkala and Brandle identified the lack of software maintenance and lack of customers as vital limitations of

traditional (“toy application”) software engineering projects [14]. Any projects that start from scratch at the beginning of the semester will suffer from the former. In that regard, existing and active open source projects (of any variety) will have a distinct advantage over students who begin development of a new product regardless of whether it is intended to be commercial or not. In this study, the new FOSS (but not HFOSS nor LFOSS) projects lacked both maintenance and a customer. Many of these new FOSS projects could be considered “toy applications.” Consequently, we discourage allowing students to pursue new FOSS products as they tend not to bridge the gap between education and industry. ACKNOWLEDGMENT We extend a special thanks to Build.com and LuLu*s for their sponsorship of Chico Open Source Consortium by donating time to the project. Even more importantly, the BossyUI core team provided essential guidance and mentorship for the students. The core team includes: Carly Culver, Andrew de Sena, Dani Dirks, Dan Green, Tauseef Jamadar, Geoff Lawson, Erik Mellum, Jason Merino, Adrian Miller, Tuhin Shukla, and Daniel Sluis. We greatly appreciate their effort and contributions. Thanks also to GitHub for providing educational accounts for hosting online repositories. REFERENCES [1]

[2] [3] [4]

[5]

[6]

[7]

[8]

[9]

[10] [11] [12] [13] [14]

G.W. Hislop, H.J.C. Ellis, A.B. Tucker, and S. Dexter, “Panel: Using Open Source Software to Engage Students in Computer Science Education,” Proc. of Computer Science Education Symposium (SIGCSE), 2009. Chico Chamber of Commerce [Online]. Available: http://chicochamber.com/ Firefox [Online]. Available: http://www.mozilla.org/ L. Auer, J. Juntunen, and P. Ojala, “Open Source Project as a Pedagogical Tool in Higher Education,” Proc. of the 15th International Academic MindTrek Conference, ACM, 2011, pp. 207-213. A. Meneely, L. Williams, E.F. Gehringer, “Rose: A Repository of Education-Friendly Open Source Projects,” ACM SIGCSE Bulletin 40 (3), 2008, pp. 7-11. R. Morelli, A. Tucker, N. Danner, T.R. De Lanerolle, H.J.C. Ellis, O. Izmirli, et al. “Free and Open Source Software for Humanity,” Communications of the ACM, Vol. 52 No. 8, 2009, pp 67-75. ABET (2015), Criteria for Accrediting Computing Programs, 20152016 [Online]. Available: http://www.abet.org/accreditation/accreditation-criteria/criteria-foraccrediting-computing-programs-2015-2016/ G.W. Hislop, H.J.C. Ellis, R. Morelli, “Evaluating Student Experiences in Developing Software for Humanity,” Proceedings of the 14th annual ACM SIGCSE conference on Innovation and technology in computer science education, 2009, pp.263-267. H.J.C. Ellis, S. Jackson, D. Burdge, L. Postner, “Learning Within a Professional Environment: Shared Ownership of an HFOSS Project,” in the Proc. of the 15th Annual Conference on Information technology education (SIGITE), 2014, pp. 95-100. Bootstrap [Online]. Available: http://www.getbootstrap.com/ jQuery [Online]. Available: http://www.jqueryui.com/ Spyral [Online]. Available: http://github.com/platipy/spyral/ GitHub [Online]. Available: http://www.github.com/ T. Nurkkala and S. Brandle, “Software Studio: Teaching Professional Software Engineers,” SIGCSE, 2011.