Contributing to Open-source Software as Capstone Projects: an Experience Report

Abstract
Open-source software development model has proven to be effective in collaborative
development of large-scale software with quality. The unique characteristics of the model, such
as the transparency of the development process and artifacts, the community involvement, and
the underlying hacker culture make it a rich learning tool for aspiring software engineers.
Contributing to open-source projects exposes to the students state-of-the-art software
engineering practices and tools and can potentially benefits the open-source community, which
is a win-win situation. This paper presents our experience getting students involved in open-
source projects as their capstone project.

Introduction
Software engineering is hard and it is not getting easier, as Fred Brooks puts it -- there is no
silver bullet (at least not in the foreseeable future). The difficulty lies in the abstract nature of
software products, which makes it hard to conceptualize and communicate them, and such
complexity only intensifies as the projects evolve and the team sizes increase. After decades of
research with limited success, people start treating such challenges as facts to be accepted
rather than problems to be solved. New process models, such as Agile method, are invented
and practiced to better cope with changes in software development processes. Good software
engineering practices often slowly find their way from industry to classrooms. Unlike other
disciplines software engineering (or computer science) programs traditionally offer no
apprenticeship programs to help students gain practical experience in real-world situations. The
closest experience students may get includes capstone projects, in which they solve real-world
problems for real clients. Computer science departments often struggle to identify and create
such projects for students and the result is often not real-world enough in terms of the scale and
the complexity of projects. Many good software engineering practices just make no sense
unless in real-world scenarios. For instance version control and issue tracking only become
essential when developers need to collaboratively create a code base without interfering each
other. Faculty members often found themselves inadequate to advise the teams because they
are not necessarily well versed with the best practices either. At the same time another world is
out there called open-source community that has endless real projects that seem fit the bill.
Contributing to open-source projects offers opportunities for students experience real-world
software development with lasting impact. In the rest of the paper we will introduce the open-
source concept, the benefit of involving students in open-source software development, and our
experience engaging students in such development as their capstone projects - challenges and
lessons learned.

The Definition of Open-source

Unlike proprietary software open-source software (OSS) grant users not only the right to use the
software (binary) but also a license to use the author's copyright (otherwise reserved by the
copyright law) to copy, modify and redistribute modified source code as long as the obligations
of the license is maintained[1]. There are over a thousand different open-source licences that
have different restrictions on how the modified source code can be distributed. Some licenses
are more permissive, such as MIT licenses and BSD licenses, by allowing redistributor to
restrict access to the modified source code. On the other hand, free software [11] license, such
as GNU General Public License (GPL), guarantees the central freedom of the users is never
stripped away by allowing no restriction on access to the modified source code. Such central
freedoms/liberty of software users include [11]:
● freedom to use the software for any purpose
● freedom to study the source code and make changes
 ● freedom to distribute copies to help others
● freedom to distribute improved versions of the software
Basically the copyleft provision of free software allow a user do anything to a copylefted
software except to restrict any of the central freedoms. This makes free software and all
modified and extended versions truly free forever.
Open Source Initiative (OSI), founded by Eric S. Raymond and Bruce Perens in 1998 [1],
advocates the open-source movement aiming to engage software users and developers to
create and improve source code while distinguish themselves from politically-focused label "free
software". Richard Stallman, the founder of the Free Software Movement, recognizes that
"Open source is a development methodology; free software is a social movement."
Often time the two types of software are identified collectively as Free and Open-Source
Software (FOSS) for practical purposes. We will use the term open-source to mean FOSS in
this paper.

The Advantage of the Open-source Development Model

The open-source development model is becoming a prominent software development model
because of its track record of producing high-quality large-scale software, such as Linux,
Android, Apache HTTP Server, Mozilla Firefox, Chromium, and LibreOffice. Most development
are done by a network of volunteer programmers. The open-source community seem to have
found a way for distributed teams to collaboratively develop large-scale software, which shows
great advantage over traditional development models. The principles of open-source software
have been applied in other areas for decentralized innovation and production by loosely
coordinated participants (open collaboration), such as open-source hardware, Wikipedia, and
open-access publishing [1]. Such collaborative development requires absolute transparency in
practices and artifacts. Through sharing the development cost is shared/lowered; better
software is produced with more eyes on the code and more people fixing bugs; software can
outlive its creators and intended hardware platforms because it can be studied and repurposed;
projects can be forked to meet people's needs [2].
Eric S. Raymond in his book "The Cathedral and the Bazaar" [3] analyzed the
surprisingly effective bazaar style open source development. He argued that open-source
culture's strength comes voluntary work done by many egoless people who are genuinely
interested in solving the problems under a leadership that practices the principle of
understanding. Such synergetic work results from virtuous pursuits by many people can
overcome seemingly disorganized development and increasing communication cost effectively
defeating Brook's law.
The principles open-source software can be summarized as the transparency in practices and
artifact - everything is done in the public. Such an open/hacker culture provides the internal
motivations for individuals to master one's craft and help others better theirs [4]. Hackers earn
their ranks and gain respect by making lasting impact. As Linus Torvalds puts it "Talk is cheap.
Show me the code." Most hackers are master programmers but they are also competent
communicators who are passionate about what they do. Students can learn social skills by
interacting with the community because they will learn to receive and offer help and keep their
code well documented by writing professionally.

Experiment Design
To experiment with involving students in open-source development our department assigned a
team of students to work on the mediawiki project [5] as their year-long capstone project.
Mediawiki is the software package that powers wikipedia and many other wikimedia foundation
[10] projects. Because it is open-source software anyone can use it to setup a wiki site with the
same functionalities as wikipedia.
The goal for the project is to help students gain experience contributing to open-source software
projects. They will study the mediawiki project: its design and architecture, the development
model, and tools used by the community. As the students explore the project and understand
the culture of the community they will discover ways to make meaningful contributions, which
can happen on various levels, such as reporting issues/bugs, improving documentation,
reviewing code, writing tests, and implementing new features or extensions. We ask students
focus on their own areas of interests because we believe they must be internally motivated to
persevere in this type of task.
Initially we gave the students a general goal and some vague objectives such as to serve the
mediwiki developer community by making meaningful contributions, to explore and learn the
practices and the culture. The faculty mentor for the team initially served as the project sponsor
by learning with the students, giving them reading assignments on open-source development,
and connecting them connected to the community.
Fortunately we were able to contact a developer at wikimedia foundation by asking for help on
the mailing list. He helped us overcome the first hurdle in committing the first change to the
code base. During the first several pair programming sessions we learned to setup the
development environment with the tool chain and learned about the workflow for submitting
code changes for review. The developer has agreed to take over the project sponsor
responsibilities and will offer guidance and directions to the students. The first task the students
were asked to do is to make a single contribution, however small, to the project as their ticket to
enter the partnership.
So far the students have gained experience with the following:
● version control with git
● issue/bug tracking with Bugzilla and Phabricator
● communication and collaboration via IRC, mailing lists, and Google hangout
● automated UI/browser testing with Ruby and Cucumber
● getting unstuck by being bold and asking for help

Challenges and Lessons Learned

Getting involved with large open-source project can be messy. The sheer scope can be
overwhelming to students who lack real-world software development experience. Our students
were "productively lost" [2] for a couple of months studying the documentation without a clear
direction on how to find their way out. Such experience can be intimidating to the faculty mentor
as well because the mentor is no longer the expert of the subject matter but instead a fellow
explorer and learner. It is also a humbling experience for the faculty mentor to learn from the
community and sometimes from the students. Another challenge is finding an appropriate
project for student involvement. Heidi [6] and others have researched this topic and suggested a
rubric for assessing open-source projects. We also need to grade the student work differently.
Initially students will spend lots of times learning the development practices, the tool chain, and
the culture. We asked our students to document their learning on their wikis and graded them
on the progress they made and the participation in some prescribed activities, such as IRC
meetings.
The project has passed its midterm checking point. We are confident that students in this team
will achieve our desired learning outcomes and potentially more than the students who work on
more traditional capstone projects.
So far we have learned the following lessons:
● start reaching out to the community early by explaining your purpose and asking for
assistance (most open-source community greatly value such student involvement
because it introduces the project to students, who may become the future contributors)
● encourage students to earn their rights to ask for help by making best-effort contributions
 ● identify a developer in the community as early as possible to serve as the project
sponsor
Through the process we also discovered other resources for getting involved with open-source:
● Google Summer of Code [7]
● Google Code-in (for high school students) [8]
● Facebook Open Academy [9]
The Open Hatch site [13] posts volunteer opportunities in free and open-source software, e.g.
"bite size bugs" for beginners. Opensource.org [14] is Redhat sponsored community site
publishes information on how open source is applied to different areas including business,
education, government, health, law and other disciplines of life.

References:
[1] http://opensource.org/history
[2] Practical Open Source Software Exploration: How to be Productively Lost, the Open Source
Way http://teachingopensource.org/index.php/Textbook_Release_0.8
[3] https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
[4] How To Become a Hacker http://www.catb.org/~esr/faqs/hacker-howto.html
[5] Mediawiki http://mediawiki.org
[6] Heidi J.C. Ellis, Michelle Purcell, and Gregory W. Hislop. 2012. An approach for evaluating
FOSS projects for student participation. In Proceedings of the 43rd ACM technical symposium
on Computer Science Education (SIGCSE '12)
[7] Google Summer of Code https://code.google.com/p/google-summer-of-code/
[8] Google Code-in https://code.google.com/p/google-code-in/
[9] Facebook Open Academy https://www.facebook.com/OpenAcademyProgram
[10] Wikimedia Foundation http://wikimedia.org
[11] https://www.gnu.org/philosophy/free-sw.html
[12] The Open Source way
https://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway
[13] Open Hatch https://openhatch.org
[14] http://opensource.com/
[f] Teaching Open-source http://teachingopensource.org/

[g] Free as in Freedom: Richard Stallman's Crusade for Free Software

http://www.oreilly.com/openbook/freedom/index.html

[b] https://en.wikipedia.org/wiki/Open-source_software#Definitions

https://www.mozilla.org/en-US/about/manifesto/details/

John David N. Dionisio, Caskey L. Dickson, Stephanie E. August, Philip M. Dorin, and Ray Toal.

2007. An open source software culture in the undergraduate computer science curriculum.

SIGCSE Bull. 39, 2 (June 2007), 70-74. DOI=10.1145/1272848.1272888

http://doi.acm.org/10.1145/1272848.1272888

http://dl.acm.org/citation.cfm?id=2157136.2157413&coll=DL&dl=ACM&CFID=606719359&CFT

OKEN=56820364

Involving students from a wide range of backgrounds in Free and Open Source Software

(FOSS) project communities gets them a hands-on, portfolio-building experience in the creation

of a real-world project while simultaneously building their institution's public profile. The

Teaching Open Source (http://teachingopensource.org) community is an emergent (3 year old)

group working on scaffolding to bridge the cultural differences between academic and FOSS

communities of practice. Join us to share questions, challenges, and triumphs of incorporating

FOSS participation into existing and new curricula as well support resources for doing so.

Alumni and current members of the POSSE (Professors' Open Source Summer Experience,

http://communityleadershipteam.org/posse) will attend in mentorship roles. Faculty attendance

at the SIGCSE 2010 BoF on Teaching Open Source (TOS) indicates that student involvement in

FOSS projects is a teaching and learning approach of interest for many faculty members. The
transparency of both artifacts and process make FOSS an attractive real-world experience that

enhances peer learning and intrinsic motivation for a diversity of courses, from introductory,

interdisciplinary, and non-major classes to software engineering core offerings and senior

capstones. However, such student participation involves a significant learning curve and effort

on the part of the faculty member, and support structures for faculty are still maturing. 2011-

2012 marks the 3rd academic year the TOS community has explored this realm together, and

the past year has seen the emergence of more best practices, support resources, and curricular

material. Community members are starting to design cross-institutional research on the impact

of FOSS participation on students. BoF attendees will be encouraged to ask questions, network,

and take advantage of the TOS community as a support structure for their own courses and

projects.

The audience is expected to consist of instructors who 1) are interested in learning how to get

started in involving students in FOSS projects; or 2) have involved students in FOSS projects

and are looking for better ways to facilitate student learning within FOSS projects.

motivated by internal reasons

http://myweb.lmu.edu/carnegie/webport/Knowgrid.htm

Free Software has provided a template, and a kind of inspiration for people to experiment with
new modes of reuse, remixing, modulating and transducing collaboratively created objects.

social and technical skills

Involvement with an OSS community in the

pursuit of knowledge

these projects typically involve implementing

code “from scratch” and focus most heavily on the first

stages of the waterfall model: requirements analysis, design,

and implementation, rather than on testing, software maintenance,

and deployment. O

Open Source Contribution As An Effective Software Engineering Class Project