Teaching Collaborative Software Development:A Case Study

Terhi Kilamo, Imed HammoudaDepartment of Software Systems

Tampere University of TechnologyTampere, Finland

firstname.lastname@tut.fi

Mohamed Amine ChattiInformatik 9 (Learning Technologies)

RWTH Aachen UniversityAachen, Germany

chatti@cs.rwth-aachen.de

Abstract—Software development is today done in teamsof software developers who may be distributed all over theworld. Software development has also become to contain moresocial aspects and the need for collaboration has become moreevident. The importance of teaching development methods usedin collaborative development is of importance, as skills beyondtraditional software development are needed in this modernsetting. A novel, student centric approach was tried out atTampere University of Technology where a new environmentcalled KommGame was introduced. This environment includesa reputation system to support the social aspect of the environ-ment and thus supporting the learners collaboration with eachother. In this paper, we present the KommGame environmentand how it was applied on a course for practical results.

Keywords-collaborative software development; SE education;case study

I. INTRODUCTION

Software is created by people, with people and for people.These people may work in varying environments, may havetheir particular backgrounds and act under different condi-tions [3], yet sharing in many cases the same activities andinterests. This is exhibited in recent software developmentsettings such as pair programming, global software engineer-ing and open source software, where individuals –from de-velopers to users– join together to work on common softwareengineering activities. In many such settings, developers areexpected to collaborate with other members with limitedface-to-face contact. This leads to new kinds of softwareengineering problems including technical, organizational,and social challenges.

Understanding team work in collaborative software en-gineering is crucial to understanding how methods andtools are used, and thereby improving the creation andmaintenance of software systems as well as the managementof software projects. A natural starting point would be tointroduce those concepts to software engineering graduates.In this regard, a number of approaches have been proposed[8], [14], [16], [25]. However, many software engineeringcurricula still lack education on collaborative software de-velopment. In particular, the software engineering education

community is continuously seeking innovative ideas, effec-tive tools, and valuable experience.

Driven by social learning theories, this paper introducesan approach to teaching collaborative software developmentwhere students collaborate collectively to achieve a commongoal. The approach is based on adapting reputation systems[11] and using them to compute and publish memberscontribution in a team. The approach allows students togenerate new knowledge through interaction with the teamspast experience and contribution with new ideas. The ideais also inspired by the experiences of using reputationsystems to reward and recognize developers in open sourcecommunities such as Qt [23].

We present an example reputation model and a concretereputation environment known as KommGame that mim-ics real team projects. The environment has successfullybeen tested at Tampere University of Technology (TUT)to introduce community driven development to softwareengineering students.

The remainder of this paper is structured as follows:Section 2 gives the background of our work, includingsocial learning theories, personal learning environments,teaching collaborative software development and reputationsystems. Section 3 presents an example reputation model andenvironment for collaborative software development trams.Section 4 presents a concrete course setting applying theproposed approach. An evaluation of the course and theunderlying approach is presented in Section 5. Finally weconclude in Section 6.

II. BACKGROUND

In modern pedagogical approaches, the learner plays acentral role. Learning is seen as an active effort of the learnerwith intrinsic motivation towards learning and it builds newknowledge based on the learner’s previous experience. Therole of the instructor is to assist the learner throughout thelearning process by applying the right teaching methods andby providing a suitable learning environment. In collabora-tive software development, the software product gets createdby a team, or a community, of developers, who keep in

978-1-4673-1067-3/12/$31.00 c© 2012 IEEEICSE 2012, Zurich, SwitzerlandSoftware Engineering Education

1165

close communication throughout development. Collaborativesoftware development is utilized within companies bothin-house and to run multi-site development. Open sourcesoftware is also developed through collaboration of globallydistributed developers. As learning is a social process as wellas an individual effort, teaching collaborative software de-velopment benefits from adding social aspects into teachingmethods to reach the best learning outcome.

A. Learning is Social

Learning is social in nature, as has been emphasizedby many researchers. Lave and Wenger [18]., for instance,introduce communities of practice (CoP) as ideal vehiclesfor leveraging tacit knowledge and learning and explore theparticipation metaphor of learning. More recent research alsoview learning as a social process. Most of the computer-supported collaborative learning (CSCL) literature relieson the socio-cultural theory of learning, such as socialconstructivism [22], [32] and activity theory [32], [10].Recently, Siemens [26] stresses that knowledge resides innetworks and points out that the challenge today is not whatyou know but who you know, and introduces connectivismas a new learning theory, which presents learning as aconnection/network-forming process. Chatti et al. [5] discussthe Learning as a Network (LaaN) theory, which puts thelearner at the center and represents a knowledge ecologicalapproach to learning. LaaN starts from the individual learnerand views learning, for an individual, as an issue of con-tinuously building, maintaining, and extending her personalknowledge network (PKN). A PKN is comprised of a myriadof explicit knowledge nodes (i.e. information) and tacitknowledge nodes (i.e. people) with complex connections.In order to learn, we build, maintain, and extend our PKNwith new explicit/tacit knowledge nodes and when neededwe activate the nodes that we believe are able to help usin mastering a learning situation. The process of developinga PKN is driven by the learning demands of the individuallearner. In LaaN, participation suggests permanent listening,active networking, and genuine knowledge sharing withothers, thus enabling each participant to build and extendher PKN, and in so doing learn.

Recognizing the social aspect of learning, learning ini-tiatives need to place a strong emphasis on knowledgenetworking and community building to leverage, create,sustain and share knowledge in a collaborative way, throughparticipation, dialogue, discussion, observation and imita-tion.

B. Personal Learning Environments

Learning is self-directed in nature. Among others, Haseand Kenyon [31] argue that this rapid rate of change suggeststhat we should now be looking at a learning approach whereit is the learner who determines what and how learningshould take place, and point out that self-organized learning

may well provide the optimal approach to learning in thetwenty-first century. In recent years, self-organized learningis increasingly supported by personal learning environments(PLE), where the learner is in control of her own de-velopment and learning. The PLE concept translates theprinciples of self-organized learning into actual practice.From a pedagogical viewpoint, a PLE-driven approach putsthe learner at the center and gives them control over thelearning experience [4].

C. Reputation Systems in Teaching

Reputation systems are used to measure the contributionof individuals in many online communities. They are alsoapplied in versatile other fields such as e-commerce, searchengines and social news. As reputation systems are appliedfor measuring online activities one can argue that they can beapplied in the e-learning educational context where most ofthe activities happen online in order to support the learningoutcomes and activities. Students today are already childrenof the web 2.0 era and thus well accustomed to existingreputation models. Furthermore, those who are active inonline communities on their free time are used to gainingreputation through their activities.

The reputation for any entity, such as a person, an activityor a product, can be decided in several ways: by givingfeedback to the entity, by rating the entity with a pointssystem, by marking the entity as a favorite or by voting forthe entity. All of the models mentioned above are simple, butsimple does not mean less powerful, less useful or that theydo not produce desirable results. A more versatile reputationmodel suited for a more complex setting such as a collab-orative software development environment can be built bycreating an aggregation or a fitting combination of the moresimple models. In [11] Farmer discussed different reputationmodels, which are listed in Table I with a description of theirreputation values.

Table ILIST OF REPUTATION MODELS

Model Reputation valueRating The average of all ratings that the entity

has been given.

Favorites and Flags The number of times the entity hasbeen marked.

This-or-That Voting The number of votes to the entity.Voting for a particular entity withina bounded set of possibilities.

Points The sum of points for different actions anactive entity has engaged in.

Reviews The number of normal ratings or freeformtext comments.

Karma The aggregate of all online activities ofinterest.

1166

In a rating model the entity is rated by giving it a valuefrom a given range. There are different types of ratingmodels in use, e.g. a points scale rating, a star rating, orthe so called HotOrNot rating where only two rating valuesare used. Through rating it is quick and easy for the usersto provide reputation feedback, for example www.imdb.comprovides this kind of a model for users to rate movies.

The favorites and flags model gives control to the com-munity for identifying entities of exceptionally high or lowquality. There are three variants of the model: vote topromote, favorite, and report abuse. Vote to promote modelis for users to vote for the supporting a particular itemin a pool of choices for it to gain a step up. A favoritemodel keeps track of the number of times a particular entityhas been bookmarked as someones favorite, thus increasingthe reputation of that entity. Report Abuse is a negativereputation model. This model is used to avoid bad contentor to identify it so it can be removed if necessary. In thismodel total reputation is the number of times particular itemis flagged as abuse and the higher the reputation gets, themore likely the item is abusive.

The this-or-that voting model is used when the best optionwithin a bounded set of options available needs to be chosen.An example of this type of model is when someone answersa question, the other users can vote for the answer as helpfulor useful. As the votes accumulate the option most perceiveas useful rises above the others.

A points model is used when a very specific value ofuser activity is desired. When a user is engaged in variousactions, these actions are recorded, weighted and summedto calculate a value representing the total reputation. Thereviews model is also a combination of rating models orfreeform text comments on a particular entity. For exam-ple in www.amazon.com users can write review commentsabout the product they bought. The reputation increases ordecreases based on the review comments.

The term karma is used to refer to the results humans getdue of their past actions. A karma model of reputation isused in particular when the entity to which is the reputationis subjected to is human. There are two primitive formsof karma: participatory and quality. Participatory karma isused on representing the amount of contribution the user hasmade. Quality karma on the other hand focuses to representthe quality of user contribution over simply the amount ofit.

D. Related Work

Collaboration has been used in teaching different as-pects of software development to university students. In[31] requirements analysis is taught by using collaborativestudents teams. Collaborative software development itselfis in focus in [12] where students from different countriescollaborate on a software learning project. Similarly in [3]a multidisciplinary environment ranging several universities

was tried out to create a more realistic setting for learningcollaborative development. Teaching collaborative aspects ofsoftware engineering is also reported in [16], [14] and [25].In [8] a tools perspective is taken.

While global software development is not necessarilyalways collaborative in nature, multi-site projects can alsowork on a joint software project in collaboration with eachother. In [7] the authors describe an environment to teachpractical software engineering in a setting mimicking aglobal multi-site project and with a collaborative approach.Similar endeavors that address the global aspects of softwaredevelopment are reported in [15] and [7].

As open source software (OSS) had gained importancealso a software business model, the need for OSS profes-sionals has become apparent. The collaborative nature andthe key principles of open source development are discussedin [24]. In the recent past collaborative software developmenthas already been taught from the OSS perspective [19],[20], [4]. Also, some universities have tried out teachingsoftware engineering by using OSS as a collaborative learn-ing environment [27] [13], to help students learn basic andadvanced software engineering topics. In [2] open sourceevolution is taught in software engineering courses to givestudents a more realistic experience. On a similar noteGoogle and The Finnish Center for Open Source Solutions(COSS) have conducted summer code camps to encouragestudents collaboration and participation in real life opensource project. There are some communities like TeachingOpen Source [29] and OpenSE [21] dedicated for promotingand researching open, online and collaborative learning.

Reputation systems have been a popular method of moti-vating the participants of online communities. Even thoughonly a few OSS communities have adopted the reputationsystems for motivating developers, it is discussed in [30] thatreputation systems suit small groups of young participants;they have a high competitive sprit, which makes learningmore active and motivated which supports the suitability toteaching environments. A Reputation system can be appliedin the CoP [6] context. In [33] it is showed that reputa-tion systems are applicable in the context of e-learning.A web based reputation system called SocialX [28] wasdesigned to support collaboration and social aspects of e-learning. SocialX lets the students to sharing and exchangeof solutions, to discuss solutions of exercises through aforum, and to participate in project activities. Combined withour findings these support the use of reputation systemsin educational context in combination of a collaborativedevelopment environment built for educational purposes.

III. REPUTATION ENVIRONMENT FOR TEACHINGCOLLABORATIVE SOFTWARE DEVELOPMENT

In collaborative software development the software de-velopers can be widely distributed over sites separated bygeographical distance and time zones. The consequence of

1167

this is that most of activities and communication are carriedout online. Hence, collaborative development requires aninfrastructure where the developers can perform their projectrelated activities. For example such an infrastructure caninclude a bug tracking system, a wiki system, a discus-sion forum, a version controlling system, an IRC channeland mailing lists. The most common activities in softwaredevelopment relate to bugs, features, improvements, anddiscussions on development details between developers viadifferent methods and among variant groups of people.

A reputation model for online software development ed-ucation that incorporates collaborative aspects of the de-velopment work should be designed so that most commonactivities are taken in to consideration in order to give thelearners a realistic experience and thus promoting apprehen-sion of key skills. From a developer community and softwaredevelopment perspective all kinds of contributions are ofimportance and there is no one good metric with which tocompare or quantify different types of contributions overeach other. In an educational context, however, the coursemoderator or tutor can decide which types of contributionspromote key skills and should thus be emphasized. Takingthis viewpoint, we can design a reputation model whichsupports learning the right skills and in the same timesupports collaboration.

We argue that the karma reputation model fits well withthe activities and the nature of collaborative software de-velopment to enforce social learning and uphold motivationamong students in an online learning environment at thesame time. Both forms of the karma model, i.e. participatoryand quality, can be used to measure both the amount and thequality of contributions.

Table IIACTIVITIES THAT CAN CONTRIBUTE TO PARTICIPATORY KARMA

Category ActivityBug Reporting new bug

Commenting on bugsClosing bugs

Feature Request new featureCommenting on feature requestClosing new feature

Improvement Request ImprovementCommenting on ImprovementClosing Improvement

Wiki pages Creating/Editing wiki pages

Code repository Apply a patchAdd a new code fileRemoving a code file

Forum Starting new discussionCommenting discussion

IRC Communicating through IRC

Mailing List Send email to mailing list

A. Concrete Quantities of Karma

As said, all kinds of online activities can contribute to thereputation of an entity. The activities that were consideredfor the participatory karma values in a software developmentenvironment are listed in Table II.

In practice all these activities need to be evaluated and asingle karma value be formed. Let us take a code bug han-dling process as an example. In the process of contributingto the development of a piece of software anyone may finda bug in the software. Then the bug is reported vie a bugtracking system used. Other developers verify, comment onand discuss the bug and eventually someone writes the codeto fix the bug and the bug report gets closed. These all add upto the karma values of the contributor. The feature requests,and the requests for improvements, are handled in the samemanner. Essentially all developer activities from adding orediting open content on the wiki pages or participation todiscussions with other developers via the available channelsto adding code or applying patches to the source code in thecode repository, contribute to the developers participatorypart of the karma value. The developers can also grantquality karma to others in the model by liking their activities.The number of these bookmarks, likes, will then contributeto the quality part of the karma value of the author ofthe wiki page. At regular intervals of time, a best qualitycontributor can be selected based on their activity, or qualityof their activity, or be given a hat. The hat is considered astoken for best quality contribution. The number of hats anycontributor receives contributes to their quality karma also.

B. Karma Model for Teaching

The karma model we suggest is composed of the concretecontributions and the karma attributes given in Section A.Each contribution is given a particular weight relative totheir size or importance to the developer community. Asin our case the model is applied in an educational settingwith pedagogical goals the values are chosen by the coursemoderator so that the highest weights support the keylearning outcomes. The final karma value of each learner isthe sum of weight times of each contribution. The universalkarma model can be written as

Karma =

n∑

k=1

(fk(Contribution) + f(Favorites)+

g(WeeklyQualityTokens)

(1)

Here n corresponds to the total number of contributions. fkis the weight function corresponding to contribution type.Favorites is the number of like bookmarks a content authorgets. Weekly Quality Tokens corresponds to the numberof time the particular participant was selected as the bestquality contributor of the week by the rest of the members ofcommunity. The karma model in Equation 1 is composed oftwo types of karma, participatory karma and quality karma.

1168

The sum of all contributions gives the participatory karma.The quality karma is composed of two parts, favorites, andweekly quality tokens.

For example, a sample karma equation, which coversactivities related to bugs, features, improvements and wikiedits, is given in Equation 2. In the formula each activityis multiplied with its associated weight. Total karma is thesum of all karma values gained from each activity. Theweights were set based on the relative importance of thecontributions to the example project. However, what we usedhere is just a framework that could be adapted to differentproject and course contexts.

Karma = 6 ∗√

nr . of bugs reported+

2 ∗ (nr . of bugs closed + 4 ∗√

nr . of feature reqs.+

4 ∗√

nr . of bug comments + 2 ∗ (nr . of closed new features)+

4 ∗√

nr . of requests + 3 ∗√

nr . of improvements comments+

2 ∗√

nr . of closed improvements + 4 ∗√

nr . of edits+

4 ∗√

nr . of likes + 4 ∗√

nr . of weekly qual . tokens(2)

There is mapping between the first and the second equationThe sum of all the contributions that belongs to bugs,features, improvements and wiki edits is the participatorypart of total karma, this corresponds to fk(contributions)in Eq. 1 and quality karma is calculated from the numberof likes. This corresponds to f(Favorites) in Eq. 1 andlastly the number of weekly quality tokens correspondsto g(WeeklyQualityTokens). The weight function of eachcontribution is chosen based on the priority of contribution,in this example bug reports is given the highest priority.

C. KommGame Environment

We have developed an OSS learning environment basedon the reputation model presented earlier. The learning envi-ronment, called KommGame [17], maintains karma values tosupport collaboration through gaining karma via collabora-tive actions. The gained reputation acts also as a motivationalfactor for the learners as the higher karma values get morevisibility. Healthy, positive competition between learners cansupport learning. The KommGame environment forms aninfrastructure required for collaborative and student centriclearning.

The KommGame infrastructure has been developed tomimic the infrastructure of a real online software devel-opment environment. It has features to add and edit opencontent, a user management system to manage users of thecommunity, a system to track user activities, a communica-tions channel, a bug management system, a source code baseto maintain source code of the project, a reputation systemto calculate the karma of each community member and anuser interface to publish karma values.

From the architectural point of view the learning environ-ment can be divided into the following modules:

• Content management module• Blogging module

• Bug reputation system• Karma Engine• User management module• Version control system

All the modules share a common learner database. TheKarma module interacts with all other modules to collectthe learner contribution information and calculates the userkarma based on learner contribution and makes the karmavalue publicly visible to every other learner.

IV. CASE STUDY: A TUT SOFWARE ENGINEERINGCOURSE

A course on OSS was organized at Tampere Universityof Technology for the second time during the academic year2009-2010. KommGame with an open source developmentcommunity infrastructure was setup for the course and a thereputation model was set to match the educational goals. Themain goal of the course was to give a practical experienceof OSS development in an actual open source infrastructure,i.e. give the learners the possibility to learn collaborativesoftware development, in this case in the context of opencourse, in a realistic, but still educational setting.

A. Course Setup

The duration of the course was 16 weeks and its extentwas 3 to 6 credits depending on learner performance. Everyweek students participated in a two hour classroom session.The first part of the session was dedicated to discussing aspecific open source topic. The second part is to discussstudent contributions to an example open source project.Both parts use the KommGame environment to record stu-dent contributions. Attendance was not mandatory. However,participating in the example project and contributing toOSS topics was an absolute requirement to pass the course.The course had two main coordinators and two TAs, whowere responsible for the KommGame environment and thecommunity, for the course.

A total number of 24 students registered to the course.Initially two students who had the prior knowledge of opensource development and infrastructure were assigned thecommitter role and the rest of the students played the role ofdevelopers, testers, and users. The KommGame environmentwas introduced to the students during the first class session.As the environment is accessible from the Internet, likein real open source projects, students were allowed tocontribute to the project at any time they wanted to do so.

B. Course Activities

Course activities were divided in to three parts. In the firstpart every student had to select one topic from a given set oftopics related to OSS. Then each student contributed withtheir own part of content to the wiki so that informationcould be accessed by everyone and would be available alsofor the upcoming instances of the course. Every week a

1169

number of students presented their topic to the rest of theclass. During the presentation, another group of studentsacted as topic discussants providing peer review on thecontent.

he second part was to participate in the development ofan example open source project called aKro. Initially aKrowas developed with very basic features and made availablein the version control system. In this exercise students wereasked to add new features, fix existing bugs and maintainthe project wiki. Whenever students observed a bug, im-provement, or a new feature request they reported thoseissues on the bug tracking system. Any student interestedin the reported issue could take up the report and submit acorresponding patch file. Once the patch file was submittedcommitters would test the patched version and apply thepatch. During the learning process students used IRC asa communication channel. Every student maintained theirown blog page where they reported their activities in theproject. Every week in the classroom the course coordinatorsinspected the contributions of the past week and rewardedthe student with the best quality contribution.

The karma model used in the course covers the followingactivities:

• Creating or editing Wiki pages.• Reporting bugs, new feature and improvement requests.• Comment on bugs, new feature and improvement re-

quests.• Closing bugs, new feature and improvement requests.• Thumbs up to wiki content page.• Adding the hats for best quality contributor of the week.The third part of the course was to contribute to a real

open source project after getting familiar with the OSSprinciples and practices covered by the first two course parts.As possible open source projects, students were introducedto the Apache Software Foundation programme [1] and theDemola open innovation platform [9]. However, they werefree to choose whichever project they liked.

C. Example Scenarios

Learners can do different activities in the KommGameinfrastructure in order to contribute to project and opencontent. Some example scenarios of activities that users cando with the infrastructure include accessing the environment,contributing open content, viewing the karma report andviewing individuals profile. Details of each are discussedin the following.

1) Accessing the KommGame Environment: The Komm-Game environment is accessible from the Internet at [17] byanyone interested. The user has to provide login credentialsin order to access the environment. Once the user is loggedin the user interface looks like the one shown in Figure 1.Different parts of KommGame are accessible through linksthat also are visible in Figure 1. The View issues link givesthe view to all reported. The Report Issue link is used to

report a new issue as the name suggests. The FLOSSpedialink accesses the open content generated by participants.Through the Project wiki the wiki content created by theparticipants can be accessed. Finally the Karma Ranks linkallows the karma value of all the students to be investigated.

2) Adding Content: The system used to share the opencontent with community is built as a wiki. Every participantcan add open content to the wiki system by providing theauthentication credentials. Figure 2 shows a wiki edit featurewhere the user is adding content to the wiki. Once thecontent edited is saved, any other user can start editing thepage. If any of the participants likes the content of the wikipage, they can bookmark the page as a favorite. When anyof the wiki pages is marked as a favorite then the author ofthe page gains quality karma.

3) Viewing the Karma Report: All participants can viewthe karma values of all the participants in a graph using theKarma reporting system. Figure 3 shows a sample view ofthe karma graph. The names in Figure 3 are blurred out toprotect user privacy. The graph shows the different categoriesof users, which are reported in different colors. Each verticalbar in the graph represents the score of each of the usersin the system. Each vertical bar has two parts with differentcolors; the bottom part indicates the score of the previousweek while the upper part indicates the score of the currentweek. The hat like icon on some of the bars indicates thatthose users were the best contributors for some week in thepast. From the karma report there are links to access the user

Figure 1. System user interface

1170

profile, which provides the details of the users contributionsand is discussed in next section.

4) Viewing Individuals Profile: All participants can havea detailed view of the activities done by a participant byusing the user profile system. Figure 4 shows a sample viewof the user profile.

The left side table shows numerical figures on the partici-pants contribution, on the right side we can see the blog thatis maintained by the participant about his work. This view ispublicly available to anyone. When the course coordinatorlogs in they can see two more buttons Add a hat and Removea hat. The notion of a hat is used as a token for the qualitycontributions here. If the current user is the best qualitycontributor of the week then he can be given a hat throughthe interface. There is a remove button to eliminate humanerrors.

V. DISCUSSION

Collaboration is an important aspect in modern softwaredevelopment. Reputation systems are is use in many onlineenvironments to enforce the social aspects of the environ-ment and give the users the feel of belonging to a group.Focusing on the course case, we set out to teach collaborativesoftware development with an online environment incorpo-rating a reputation system. Our focus on the course was inteaching open source software but aspects of collaborative

Figure 2. Add content to wiki and favorites bookmark

Figure 3. Karma reporting interface

development in general are covered. Neither the environmentnor the learning outcomes are limited to the OSS context.

Out of the 24 registered students 15 participated activelyon the course. The details of student participation are shownin Table III.

During the first part of the course where students were tocreate wiki content on the chosen topics, participants got toknow KommGame environment. Working on the wiki alsoacted as an introduction to working online and the need forcollaboration. In the second part of the course, the studentswere to actually develop a small software project calledaKro. During the project it took some time for the studentsto understand the key concepts: bugs, features, requestsetc. in the online collaboration context. Throughout bothphases the emphasis was on social learning, peer supportand learning by doing. The course coordinators were notthe ones teaching but the learners collaborated together inreaching the learning outcomes.

Initially there was a slow start in the project as studentswere not used to, not only collaborative and OSS develop-ment, but also to a social learning course setting. As theproject progressed there were more contributions from thestudents and the online work was more active. This trendcan be observed from the statistics. There were totally 63issues reported in the bug tracking system, on average eachstudent posted 4 issues. In the first week there were only 3issues reported and the second week 12 issues were reported.This count kept fluctuating with the range from 3 issuesupwards. While the overall number of unique issues keptrather steady, the increased activity can be seen in totalnumbers of issues reported. The activity statistics per weekare shown in Tables IV and V and in Figure 5. Whileobserving all the contributions we found that there were 6students who were more active than rest of the community.

Figure 4. Detailed user profile interface

Table IIIDETAILS ABOUT NUMBER OF STUDENTS PARTICIPATED

Students Total NumberRegistered 24

hline Participated 15hline Active 6

1171

This kind of scenario is also very common in real opensource project where very few members of the project create90% of the code. On an average each student contributed 40wiki edits and what shows the collaborative aspect the beston the 7 bugs reported a total of 97 comments were made.

Initially, it was planned that all the communication duringthe development process happens online, but in some situ-ations there was verbal communication between groups ofstudents. This verbal communication aroused when studentshad to make a critical decision about the project. This kindof physical interaction is also common in real world softwareprojects when handling the most important decisions. As theproject development was progressing, the amount of studentscontribution also kept increasing. All the students played thekey roles: user, developer, and bug fixer and reporter. Mostoften the person who reported them also fixed the bug, withonly a few cases where someone else fixed the reported bug.When the participants were asked for the reasons why, theyanswered that coding is fun.

Every week, after the seminar session the course coordi-nators along with the participants verified the contributionsmade to the project to decide who would be the best qualitycontributor of the week and thus to add a hat in their

Table IVTOTAL NUMBER OF DIFFERENT ACTIVITIES DONE BY STUDENTS

Different Activities Total NumberBugs Reported 7

Bug comments 97

Comments on issues 40

Bugs closed 2

New features title 10

New features closed 4

Improvements 23

Improvements closed 12

Wiki edits 40 (Average)

Likes 9

Hats 7

Table VNUMBER OF DIFFERENT AND TOTAL ISSUES CARRIED ON

Number Of Week Different Issues Total IssuesFirst 3 4

Second 12 25

Third 2 6

Fourth 2 7

Fifth 3 5

Sixth 8 20

Seventh 3 5

Eighth 3 6

Ninth 4 13

Tenth 4 6

Figure 5. Activities completed

profile. The top contributor of the week is given a smallgift to motivate others. This practice of verifying all userscontribution and select the best quality and top contributorsappeared to motive the others to work. It also enforcedcollaboration and gave a sense of a community to the course.Every week a new student was rewarded.

The weekly activity over the week KommGame was run-ning is shown in Figure 6. There are two significant slumpsin weekly student activity. The drop in initial enthusiasmexplains the first slump. Furthermore, it occurs when thestudents needed to make an adjustment to their learningpractices as they had to put in a more continuous work effortto what the students were accustomed to be required. Thesecond is due to a break in the teaching for an examinationperiod. The last peak can be contributed to the coursecoming to an end and thus participants working hard to closethe loose threads.

The student feedback after the course supports the notionthat the participants feel they reached the intended learningoutcomes and found the KommGame to have given them asufficient head start to collaborative development methods.

1172

Figure 6. Activity per week

A. Conclusions

The approach of KommGame for collaborative softwaredevelopment education allows students to practice devel-opment details and characteristics in a realistic yet safesetting. The KommGame enforces collaboration through thereputation aspects and thus gives the participants valuablesoftware project experience. The students are free to learnfrom their own past and present experience as well as theothers. Based on the experiences gathered by the pilot coursein teaching OSS development we consider that using the

KommGame setting for collaborative development educationadds to the learning experience and paves the way forworking as a developer in the modern software industry.

The future plans for KommGame are to research how thiscan be applied in traditional programming courses wherestudents have to collaborate and participate in programmingexercises. Research should also be done to know how to useKommGame as standard system to issue certificate of OSSbeginner to any participant around the world who participateand contribute.

REFERENCES

[1] The Apache Software Foundation. http://www.apache.org/foundation/. last visited on March, 2011.

[2] J. Buchta, M. Petrenko, D. Poshyvanyk, and V. Rajlich.Teaching evolution of open-source projects in software engi-neering courses. In Proceedings of 22nd IEEE InternationalConference on Software Maintenance (ICSM’06), pages 136–144, 2006.

[3] L. J. Burnell, J. W. Priest, and J. B. Durrett. TeachingDistributed Multidisciplinary Software Development. IEEESoftware, 19(5):86–93, 2002.

[4] M. A. Chatti, M. R: Agustiawan, M. Jarke, and M. Specht.Toward a personal learning environment framework. Inter-national Journal of Virtual and Personal Learning Environ-ments, 1(4):71–82, 2010.

[5] M. A. Chatti, M. Jarke, and M. Specht. The 3p learn-ing model. Journal of Educational Technology & Society,13(4):74–85, 2010.

[6] C. C. P. Cruz, M. T. A. Gouvea, C. L. R Motta, and F. M.Santoro. Towards reputation systems applied to communitiesof practice. In Proceedings of 11th International Conferenceon Computer Supported Cooperative Work in Design, pages74–79, 2007.

[7] D. Damian, A. Hadwin, and B. Al-Ani. Instructional de-sign and assessment strategies for teaching global softwaredevelopment: a framework. In Proceedings of the 28thinternational conference on Software engineering (ICSE ’06).ACM, 2006.

[8] J. DeFranco-Tommarello and F. P. Deek. Collaborative soft-ware development: A discussion of problem solving modelsand groupware technologies. In Proceedings of the 35thAnnual Hawaii International Conference on System Sciences.IEEE, 2002.

[9] Demola: Open innovation platform for students and com-panies. http://www.demola.fi/what-demola-new-factory. lastvisited on March, 2011.

[10] Y. Engestrom. Learning by Expanding: An Activity - Theoret-ical Approach to Developmental Research. Helsinki: Orienta-Konsultit. Retrieved from http://lchc.ucsd.edu/MCA/Paper/Engestrom/expanding/toc.htm.

[11] R. Farmer and B. Glass. Building web based reputationsystems, page 72. O’Reilly Media / Yahoo Press, 2010.

1173

[12] J. Favela and F. Pena-Mora. An experience in collaborativesoftware engineering education. IEE Software, 18(2):47–53,2001.

[13] M. D. German. Experience teaching a graduate course inopen source software engineering. In Proceedings of theFirst International Conference on Open Source Systems (OSS2005), pages 326–328, July 11-15 2005.

[14] F. D. Giraldo, C. A. Collazos, S. F. Ochoa, S. Zapata,and G.T. de Clunie. Teaching software engineering from acollaborative perspective: Some latin-american experiences.In Workshop on Database and Expert Systems Applications(DEXA), pages 97–101, 2010.

[15] O. Gotel, C. Scharff, and S. Seng. Preparing computer sciencestudents for global software development. In 36th annualFrontiers in Education Conference. IEEE, 2006.

[16] I. Hadar, S. Sherman, and O. Hazzan. Learning humanaspects of collaborative software development. Journal ofInformation Systems Education, 2008.

[17] OSS Learning environment at Tampere University of Tech-nology. http://osscourse.cs.tut.fi/mantis/login page.php. lastvisited on March, 2011.

[18] J. Lave and E. Wenger. Situated Learning: LegitimatePeripheral Participation. Cambridge University Press, 1991.

[19] B. Lundell, A. Persson, and B. Lings. Learning through prac-tical involvement in the oss ecosystem: Experiences from amasters assignment. Open Source Development, Adoption andInnovation, 234:289294, 2007. IFIP International Federationfor Information Processing, Springer.

[20] D. Megas, J. Serra, and R. Macau. An international masterprogramme in free software in the european higher educationspace. In Proceedings of the First International Conferenceon Open Source Systems, page 349352, July 2005.

[21] Open software engineering. http://opense.net. last visited 20March 2011.

[22] J. Piaget. The Childs Conception of the World. Rowman andAllenheld, New York, 1960.

[23] Qt developers network reputation system. http://developer.qt.nokia.com/ranks, last visited on March 2011.

[24] E. S. Raymond. The Cathedral and the Bazaar. OReillyMedia, 1999.

[25] C. Y. Shim, M. Choi, and J. Y. Kim. Promoting collaborativelearning in software engineering by adapting the pbl strategy.World Academy of Science, Engineering and Technology, 53,2009.

[26] G. Siemens. Connectivism: A learning theory for the digitalage. International Journal of Instructional Technology andDistance Learning, 2(1), 2005. Retrieved from http://www.itdl.org/Journal/Jan 05/article01.htm.

[27] I. Stamelos. Teaching software engineering with free/libreopen source projects. IJOSSP, 1(1):7290, 2009.

[28] A. Sterbini and M. Temperini. Social exchange and collabora-tion in a reputation-based educational system. In Proceedingsof 9th International Conference of Information TechnologyBased Higher Education and Training (ITHET), pages 201–207, April 29 -May 1 2010.

[29] Online community for open source software educaton. http://www.teachingopensource.org, last visited March 2011.

[30] M. Temperini and A. Sterbini. Learning from peers, moti-vating students through reputation systems. In InternationalSymposium on Applications and the Internet, pages 305–308,2008.

[31] J. Tuya and J. Garca-Fanjul. Teaching requirements analysisby means of student collaboration. In the 29th ASEE/IEEEConference in Education, 1999.

[32] L. S. Vygotsky. Mind in Society: The Development of HigherPsychological Processes. Harvard University Press, 1978.

[33] S. Wang. Study on e-learning system reputation service,wireless communications, networking and mobile computing.In WiCOM ’08, pages 1–4, October 12-14 2008.

1174