Power Through Brokering: Open Source Community Participation in Software Engineering Student Projects Birgit R. Krogstie Norwegian University of Science and Technology Sem Sælands vei 5-7, 7034 Trondheim, Norway
[email protected] students have to demonstrate independence in coping with such situations.
ABSTRACT Many software engineering projects use open source software tools or components. The project team’s active participation in the open source community may be necessary for the team to use the technology. Based on an in-depth field study of industry software engineering project students interacting with an open source community, we find that participation in the community may affect the team’s work and learning by strengthening the power of the broker between the team and the community. We outline pitfalls and benefits of having student teams acquire development-related knowledge from open source communities. The findings are relevant to the organization and supervision of software engineering student projects interacting with open source communities.
Requirements to learn and apply specific technologies may force SE teams to interact with user and/or developer communities through different degrees of community participation. For instance, involvement with open source software (OSS) communities may be needed. In what follows, we will talk about open source software communities for simplicity – tacitly assuming that similar considerations apply to free, libre and open source software (FLOSS) communities. OSS communities are a relatively new arena for information acquisition and knowledge building in SE student projects. Supervisors might be in doubt about what is going on and what advice to give in such cases, feeling that their possibility to impact on the project process is diminished. On part of the students, having to participate in a different community in accordance with the practices of that community may result in increased knowledge as well as self confidence. Involvement with an OSS community in the pursuit of knowledge may thus benefit the SE student team. However, with an increased numbers of stakeholders to relate to, the complexity of project work [5] increases, and coordination becomes more challenging. Also, the introduction of unfamiliar, third party OSS components introduces difficulties in terms of providing a system design early in the SD lifecycle [6]. This makes planning and estimation harder. Generally, there is very limited experience in student teams in respect of project management. Programmingrelated tasks, as will be argued, tend to be given priority, and programmers given strong influence on the project process. We believe that project managers as well as supervisors of SE student teams may benefit from insights on how OSS participation can affect the projects, in order to be prepared to take adequate measures.
Categories and Subject Descriptors K.3.2. [Computing Milieux]: Computer and Information Science Education
General Terms: Human Factors Keywords:
FLOSS, open source, software engineering, software engineering education, computer science education, communities of practice
1. INTRODUCTION Student SE industry projects, also known as customer-driven projects, are designed to provide SE students with realistic experience from software development work. The projects require that students relate to various stakeholders and engage in crosscommunity interaction [1]. Desired learning outcomes span both social and technical skills. The latter includes being flexible to customers’ technology requirements, which may be outside the team’s current experience and preference [2]. Through the pedagogical organization of SE project courses, student teams are provided with scaffolding for their learning process [3, 4], which might include guidance on the use of particular technology. Sometimes in the case of industry projects, neither course staff nor the customer is familiar with technology required in the project. The
With this as our point of departure, in this paper we explore why and how the interaction between a group of students, involved in an SE industry project, and an OSS developer community evolves over time. We further address how such interaction might influence the project process, particularly in respect of the power structures in the team. The paper is based on an in-depth exploratory study of the work and learning of a student SE team during the spring term of 2007. We demonstrate how the interaction of the team with an OSS developer community can be paramount to the success of a SE project. In our case, we found that the OSS community readily responded to the students’ requests for assistance on the use of the OSS, and that issues of contribution from the team to the OSS community quickly arose. Also, we found that the team member responsible for
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICSE’08, May 10-18, 2008, Leipzig, Germany. Copyright 2008 ACM 978-1-60558-079-1/08/05…$5.00.
791
Sometimes, due to convenience or availability, information needed for the team’s work is collected from outside the communities of the team, the university, and the customer organization. The information may be found in a more or less pedagogically organized form, and its gathering may be of a more or less interactive nature. Useful information sources include textbooks and tutorials, handbooks, FAQs, case descriptions / examples, and templates. Often, such resources are freely available on the Internet and can be found by the aid of a search engine. More interactive sources of information include communication channels belonging to a virtual community, e.g. associated with the use and/or development of a particular technology. Email lists, forums, wikis and blogs are frequently used to support virtual communities [11]. Also, synchronous communication may be supported through instant messaging and chat rooms. Gutwin et al. found that developers in OSS communities, who generally are distributed in their work, maintain awareness of each other primarily through text-based communication (mailing lists and chat systems) [12].
communicating with the OSS community through his brokering role maintained a position of power in the SE team. Based on our findings, we provide an account of (i) mechanisms enabling a SE team to successfully interact with an open source community and (ii) possible pitfalls and benefits of the engagement in terms of project success. First, we provide a theoretical background for the issues focused in our study. Next, we present our case, research method and findings. We further discuss the findings in the context of the above outlined research objectives, before concluding the paper.
2. THEORY This section starts by providing a theoretical grounding for understanding power structures in SE teams, viewing teams as communities of practice. We then address how collaboration across communities can be achieved, before briefly outlining relevant research on how participation in OSS communities is typically structured and how OSS projects may serve as a resource in SE education.
In order to cross the border to a (virtual) community, a certain understanding of the rules of interaction and the community as a social system is required [13, 14]. Lave and Wenger described how the mechanism of legitimate peripheral participation (LPP) allows newcomers to gradually become members of a community of practice [10]. Not only is LPP seen a way of entering the community; it is also seen as the basic way of learning the practices of the community. Wenger explained how two main mechanisms support the interaction between two communities: brokering and boundary objects [8]. A broker is an individual who is a member of both communities and is able to contribute to one community based on the understanding of the practices of the other community. Boundary objects, originally described by [15], are artifacts, abstract or concrete, that retain an identity across the communities they connect and play a role in the meaning-making of each community. A boundary object thus works as a means for two communities to coordinate their practices, even if the communities understand the boundary object in different ways and use it differently.
A student SE team can be viewed as a task-based learning community [7], a form of community of practice [8] oriented towards learning and the time-limited effort of solving a particular task. The building of knowledge in the team is likely to be combined with the application, through trial-and-failure, of various solutions to the development task in question. Learning within the team may be based on expertise within the team, as seen in peer programming [9]. A student SE team may learn through interaction with course staff, e.g. a supervisor, and with the external customer, if the project is an industry project. In addition, there will typically be a need to acquire information from other sources, e.g. textbooks or resources on the Internet. Power structures in student SE teams can be seen as having several dimensions, for instance between the customer’s and the university’s goals, between experienced and inexperienced programmers, between various roles within the team, as well as between the team’s needs and individuals’ needs. A team typically regards it as the most important goal of their project to deliver working software in line with the customer’s requirements. Even when the project report weighs heavily in the formal assessment and grading of the project, documentation is typically conceived as something which is required by the university, but which is not too important for the customer – which might be a realistic observation [1] – and is not the real challenge of the project. With students’ orientation towards the ‘real’ development task follows that programming is regarded as the core of the practice of the community constituted by the SE team. Accordingly, the skilled and talented programmers get authority as core members of the team. The ongoing programming tasks tend to be both a major constraint and a driving force in the projects. As a result, whatever programmers decide to spend time on tends to be regarded as adequate use of time. Other team members, including the project manager, might not be able to judge whether it actually is. Team members good at activities regarded as secondary to programming will be closer to the periphery of the team community [10]. From the author’s professional experience as SE project course staff over several years, it is common in the teams that the role of project manager is seen as important, but less central to the project than the programmer role, mainly because good programmers are a scarce resource.
Often, it will not be necessary for members of a SE team to become full-fledged members of a community to get necessary information from that community. In respect of communities related to a particular technology, there might be an opening for outsiders to participate as users, but not as developers. In the case of OSS development (OSSD), there is typically an openness that allows for participation in development for those who are able and willing to contribute. OSSD takes on many different shapes, but some general characteristics pertain to many developer communities [16]. The participation structure tends to be layered, with a core of active developers, intermediate layers of codevelopers, active users and, constituting the outer layer, passive users [17, 18]. Roughly, the model postulates that active users report defects, co-developers repair defects, and new and updated functionality is provided by core developers. Passive users may contribute by answering questions from other users. Contributions to the development of the OSS code may be seen as based a form of gift economy where the giver achieves status from giving away. At the same time, these mechanisms assure a certain quality of the code [13]. The threshold for being admitted as a developer in an OSS community may vary between projects, large OSS projects based on the sponsorship of major corporations being far more restrictive than small OSS projects in terms of accepting development contributions.
792
where major variation in individual work effort is documented by the team). The grade is based on a combination of the software product, the documentation and the project process. The teams are provided with some templates and guidelines for their work, e.g. related to project planning, status reporting and contents of the project report.
Due to the openness of OSS communities, students may use them as an environment for learning which is interactive, ‘real’ and outside the university. OSS development has been acknowledged both as a means and as an objective of learning in SE education. Whereas the number of studies reporting lessons learned from students’ participation in OSS development is still limited, experience and lessons learned from student projects have been reported (e.g. [19, 20]). Toth [20] lists the following benefits of using and extending OSS tools in student SE projects: a baseline of such tools automatically gives a ‘critical mass’ to the projects, the tools can freely be extended, using OSS is engaging for students, students may evolve their own tools (‘eating their own dog food’), and students increase their value in the job market. Spinellis [21] points to the following benefits of working with OSS in general: increased industry contacts, professional maturation, improved skills in written communication, experience with system administration, and exposure to management approaches. These are benefits equally relevant to SE and CS students as to SE professionals. Jaccheri and Østerlie [22] demonstrated that students may learn from an action research approach to participation in OSS development, resulting both in familiarity with action research and improved capabilities in programming and design. Ellis et al. [19] mention possible disadvantages of using OS projects as a basis for SE education: lack of documentation, inconsistent coding standards, and inconsistent quality.
There are no general requirements that any particular process model, analysis/design methodology, development tool or collaboration technology be used in the projects. Students are expected to relate to the customer’s requirements and draw on their skills and resources from previous and parallel courses at the university. The teams use tools available at the university, provided by the customer, or otherwise available. When needed and feasible within the time frame of the project, the teams are expected to get into new technology as part of their project work. The student team followed in the case study presented in this paper consisted of five male students: Ethan, George, Sam, Owen, and Morgan (names have been altered), all in their twenties. Their development task was to make an auctioning system for an IT consultancy company, here called Anniva. The company wanted to use the system for in-house purposes and as a substitute for an existing system used by employees to sell items (such as PCs and bicycles) to colleagues on a private basis. As a secondary objective for the project, the company wanted the team to make use of a particular open source Java development framework, here denoted PLENTI, in making the auctioning system, to see how the framework could be utilized. The team succeeded in developing the auctioning system, receiving the grade B on their project. (B is regarded as a good grade; of the nine project teams in the 2007 semester of the course, there were 2 As, 4 Bs and 3 Cs.) Crucial to the team’s development work, as will be seen, was their interaction with the PLENTI developer community.
Lessons learned and guidelines emerging from current studies on student projects engaging in OSS communities generally address the pedagogical organization of SE project courses in which students’ primary development task is itself OSS development. There is however a lack of research on (i) ways in which the OSS community might be an important source of knowledge relevant to the students’ development task without being its main arena, and (ii) pedagogical issues arising from such a setting. This is where this paper aims to contribute.
4. RESEARCH METHOD
3. OUR CASE
The student team of our study was observed during the spring semester 2007, i.e. over a period of four months. Given the real-life context, focus on a contemporary phenomenon, lack of control over events and our intent to explore “how” and “why” aspects of the setting, a case study was appropriate [23]. Part-time participant observation was conducted with adherence to principles of interpretive field research [24]. For the research project at large, data (mainly documents and interviews) was collected across all teams in the course. Data for the study reported in this paper originate from an in-depth study of one particular project team and includes recordings, field notes and pictures from 15 hours of meetings between the team and customer/supervisor and 60 hours of teaminternal work sessions and meetings (mainly in the computer lab), copies of pages from the team’s wiki, some logged msn conversations, various project documents from the team’s workspace, the preliminary and final version of the project report, all email correspondence going through the team’s email list, recorded interviews with the team, the supervisor and the customer, and the threads in the PLENTI user forum (listserv) resulting from the team’s requests to the forum.
The particular SE project investigated in this work is part of an undergraduate level course at a Norwegian technical university. The students take the course in the final semester of their Bachelor program, i.e. their 6th semester. The students work in mostly selfformed teams of 3-5 students, developing software for an external customer. Students make a prioritized wish list from a number of available project descriptions mainly provided by industry, and teams are assigned tasks by course staff according to students’ preferences and skills. The workload of the course is half of the semester, but students tend to spend more time on the project, giving it higher priority than parallel courses. In addition to the software product, the students must hand in a project report (both a preliminary and a final version) to the customer and course staff. Also, the teams give oral presentations of their projects halfway through the semester and at the end of the semester. There are no lectures in the course except an introductory lecture in which available projects are presented. Each team receives supervision on their project process from a member of course staff, usually a teaching assistant. The customer is responsible for providing supervision on technical issues when necessary, as well as providing resources otherwise unavailable to the students (e.g. particular hardware, software, and physical or virtual workspace). Based on the course staff’s evaluation and customer feedback through an evaluation form, each team is given one grade (except in rare cases
Generally, the researcher was given free access to work sessions and meetings (participation and recording) as well as to the team’s server workspace, wiki and email list. The researcher attended all meetings with the customer, with the exception of a couple of meetings which were audio recorded for the researcher by a team
793
member. Field notes were made during and immediately after the sessions, to the extent possible. The team’s supervisor was interviewed during and after the project, and the team’s customer was interviewed after the project. The team was interviewed once during the middle of the project and once after completion of the project.
5. ANALYSIS AND FINDINGS In presenting the findings of our study in terms of the team’s interaction with the PLENTI community, we have made a chronological structuring of the material, distinguishing what we see as four partly overlapping phases. The first phase is a (dis)orientation phase in which the team strives to understand what PLENTI is and how to obtain adequate knowledge about the framework. In the second phase, PLENTI is regarded by the team as an obstacle, but starts taking on the role of a tool (albeit not quite mastered by the team). In the third phase, the team is communicating with PLENTI users and developers through the listserv of the community, actively making use of the framework as a tool in the project development task. In the fourth phase signs of a feeling of identity related to the PLENTI community participation can be found in the team, and the team is contributing to the PLENTI development.
Most of the meeting recordings and interviews have been fully transcribed. Recordings from work sessions have been partly examined and summarized based on their perceived relevance in the analysis process. Quotations have been translated into English by the researcher at need. Analysis of the data started out with some theoretical concepts being perceived as central (cf. the Principle of Abstraction and Generalization, [24]). Coding was performed on the basis of these concepts, by the aid of a computerized qualitative analysis tool (Atlas.ti). New codes were added as themes developed during interpretation and writing. For instance, PLENTI was used as a code to mark and organize data related to the team’s use of the framework and interaction with the community. Further, the data have been chronologically structured within selected themes.
In the subsequent discussion (Section 6), we will argue that the transition to the third phase was essential to the project, and address how this transition came about in our case. In the present section, we characterize each phase in more detail, giving some illustrative excerpts from the data where appropriate.
The researcher was the coordinator of the project course, grading the projects, but not supervising any group. In the process of observing the Anniva team, great care was taken to avoid mixing up the roles of researcher and course staff and to be aware of the possible effects of ‘the teacher being present’ (cf. the Principle of Interaction Between the Researcher and the Subjects, [24]). As part of the initial agreement between the researcher and the team, it was decided that another member of course staff set the grade on their project. Further, it was agreed that the researcher was not to supervise them, but restrain interaction to being social without causing too much disturbance. The reason for not supervising was not mainly that supervision would influence the case. The influence of the researcher is an inevitable consequence of participant observation, even if the degree of influence can, and should, be limited. The team was not, however, to be given advantages as compared to the other teams in the course, or at least the sum of advantages and disadvantages of being research subjects should be perceived as close to zero by the team and by the other teams. These considerations impacted on the possibility to have the researcher’s interpretation validated with the research subjects during the study (cf. the Principle of Multiple Interpretations, [24]). As all teams in the course were however interviewed about their project work and viewpoints on the course in the middle of the semester, and on that occasion it was possible to have some prompted viewpoints from the Anniva team. Also, the day after the completion of the project, a three hour interview was conducted with the team to have their feedback on the researcher’s preliminary interpretation of the project.
5.1.1 First phase (January-February): What is PLENTI? In the original project description as well as in the initial customer meeting, it was specified by the customer that PLENTI should be used as a development framework. The reason was that one of the two customer representatives had attended a seminar with an enthusiastic PLENTI developer and thus caught interest in the framework. During the first customer meeting, the team was offered the alternative of using another framework, but not PHP, which was the only alternative with which they were familiar. This left PLENTI as the de facto option. Adding to the arguments to use PLENTI, the customer expressed interest in having it tried out to see how it worked for this type of application development. None of the students in the team had any advance knowledge about PLENTI. Further, no one had any experience with the programming of web applications with servlets. The web pages of the PLENTI community were the only resource about the framework known to the team. The team decided that every team member was to learn PLENTI and participate in the programming tasks. Two team members, Sam and Owen, were assigned the task of starting the knowledge acquisition about PLENTI. Ethan and George, accepted as the lead programmers in the team, took on the task of developing a prototype to demonstrate to the customer as a basis for refining the functional requirements. Ethan worked on the web user interface whereas George focused on the underlying business logic, none of them making use of PLENTI for their tasks. Both programmers participated in team-internal discussions on the role and use of PLENTI, though. The fifth team member, Morgan, took the role as project manager, which made him mainly responsible for overall project planning, generating and handing in bi-weekly status reports and activity plans to the supervisor, scheduling meetings, and making sure that work on the project report progressed in accordance with the deadlines.
In reflective discussions within the team towards the end of the project and in the interview conducted after the project, the team expressed that they had perceived the researcher as non-interfering and agreeable, and that they had not received project supervision from her. To validate findings reported in this paper, a draft version has been reviewed by two of the team members, Owen and Ethan. Ethan expressed that he liked the paper. Owen provided more detailed viewpoints which have been incorporated in the Analysis and Findings and Discussion sections.
794
5.1.2 Second phase (February-May): PLENTI as an obstacle gradually becoming a tool
5.1.3 Third phase (April-May) Gradual PLENTI community participation
It soon became evident to the team that getting into the workings of the framework was not an easy task. Sam and Owen spent many hours in the PC lab reading through descriptions and examples, Sam doing some exploratory coding and Owen reflecting overview level information on the framework in the Software Development Plan which had to be handed in early in February.
In the customer meeting on March 28. Ethan reports “having been a bit on the IRC” communicating with the PLENTI community, reporting that there was “this guy” that he communicated with.
The web documentation of the framework turned out to rely on the reader’s prior knowledge of the development of web applications, which the team lacked. The examples provided in the material were not relevant enough for the team to be able to easily draw on them. The team explained their challenges with PLENTI to the supervisor and the customer in meetings with them.
’Why do you do it that way?’ And we just: ‘What? That’s how we do it in JSP.’ ’Don’t do it that way!’ No good, no good, so…”
Exhibit 3: Excerpt from March 28, meeting between the team and the customer. Ethan talks, quoting his IRC communication with Bernhard:
Expressing the above, explaining how Bernhard had reacted negatively to their approach, Ethan still appeared satisfied with the IRQ dialogue. He had in fact reached a PLENTI developer with his request, and the dialogue resulted in relevant directions for the team.
Exhibit 1: Excerpt from February 16, meeting between the team and the customer: Ethan: ”We had a bit of trouble with, with.. that is, we have a small problem with the PLENTI documentation. It is a bit.. They have a lot of examples, but there is sort of nothing that is.. the most basic stuff. They assume that you know quite a lot.” Owen:”The examples and documentation found there are mainly presentations, mostly of how PLENTI is better than earlier and similar tools. We have some problems with, sort of.. the totally basic stuff, they aren’t explained anywhere, so it becomes a lot of trying and failing.”
After the Easter holiday, following up on the success with IRC, Ethan turned to the PLENTI users forum, a listserv service linked to the PLENTI web pages. The subsequent interaction between Ethan and the community in this forum amounted to eight threads, most of which with several postings, during the course of the project. A condensed thread from the forum is shown in Exhibit 4. Other requests from Ethan were addressed by Bernhard partly in parallel, in different threads.
Ethan and George continued focusing on their preferred parts of the prototyping work, and in the larger part of this phase, the team had little progress with their understanding of PLENTI.
Exhibit 4: Excerpt from April 13.-18., PLENTI users forum on the Internet: April 13.: Ethan: ”We’re trying to make a credentials manager for authenticating against LDAP. We’ve written some code but we’re unsure about what to do next, or if the code is correct. Any ideas? .. Code: ”
Gradually some knowledge of the workings of PLENTI developed, however, as the programmers started using the framework in their prototyping. The team was however aware that they did not yet utilize the powerful mechanisms that would be the main reason for using the framework. Attempts to do the latter were postponed, awaiting the completion and demonstrating of the prototypes. Also, work on design and architecture models of the auctioning system was postponed, again with reference to the lack of understanding of how PLENTI should be used. In the eyes of Ethan, it would be more or less meaningless to draw a design model: “It would just be a big box named PLENTI with a number of arrows coming out of it”.
April 14.: BG “Hi Ethan, using the upcoming PLENTI 1.6, it’s very easy to plug in your own credentials manager ” April 16. Ethan: “Hi, Bernhard, In addition to , what files do we need? ” April 18.: BG: “Just should suffice ” April 18.: Ethan: “Thank you Bernhard! That worked perfectly. We have now functioning LDAP authentication in our webapp. Has integrating LDAP authentication directly in PLENTI been considered? Sincerely, Ethan Lake”
In the midterm version of the project report, handed in on March 7, as well as in the related oral presentation, PLENTI was still presented by the team as something they needed to learn properly. The auctioning system prototype demonstrated was mostly a mockup and hardly made use of any of the functionality in the framework.
April 18.: BG: “Wonderful! Several people have asked for it in the past, it would be a very welcome contribution to the project.” Whereas the communication shown in Exhibit 4 took place in the PLENTI users forum (as opposed to the developer forum, which also could be found on the web site), changes to PLENTI itself were discussed in the last two postings. The initial posting was the first request from Ethan on the forum. Bernhard, the chief developer of PLENTI, was, with one exception, the one who answered Ethan’s (and a number of other users’) requests on the listserv. He gave quick response, often on the same day (or night). These observations together may be taken as an indication that the OSS community is a very small one, with small distance between user and developer as well as between user issues and development issues.
In the customer meeting on March 28, it was clear to the customer as well as to the team that the progress of the project was not satisfactory. Exhibit 2: Excerpt from March 28, meeting between the team and the customer: Ethan: ”Ok, we have made several prototypes, so that.. we have learnt PLENTI by programming. But we haven’t made any completely robust solutions yet.” Owen: ”And then we have used a lot of time to learn, study PLENTI, then, because the documentation is quite bad, I think.”
At one point, Ethan was asked by Bernhard to send large pieces of code by private email instead of pasting the code directly into the forum. Ethan sent code by email as requested. On a couple of
795
functionality (i.e., if they wanted to do it); at least a week’s work. The team took this to mean a lot more work for them as inexperienced programmers, and the idea was abandoned. Third, there was the LDAP functionality referred to in Exhibit 4, suggested by Ethan and applauded by Bernhard. Even after the completion of the project, the team continued discussing the possibility of contributing such a module. That development job was however never carried out.
occasions, Bernhard asked for more information or clarification to understand Ethan’s questions, on which Ethan immediately followed up. Generally, communication between the two appeared effective, to-the-point, polite and friendly. The interaction with the PLENTI community was conveyed to the team through the team’s mailing list. Ethan made sure that his requests and Bernhard’s answers were in this way shared with the rest of the team. The new knowledge was used by the programmers - Ethan, George and Sam - to develop and modify their code. In discussions within the student team, new issues were identified that required more consultation with Bernhard. Ethan took on the job of formulating and submitting postings, which he sometimes did in the PC lab and sometimes in his home at night. Ethan’s role in this was never questioned by the team.
The team’s account as given in the common reflection note shows how PLENTI is given a very central role in the team’s understanding of their project process. We note that the framework still plays a role as an excuse and explanation for insufficient project management. Exhibit 5: Excerpt from the common reflection note in the final project report
In terms of the division of project work, Owen produced use cases and other parts of the documentation, coordinating with the others as needed. Morgan continued performing project management, more by following up on what the others were in fact doing than by pushing the process. Sam largely assisted with programming tasks. Ethan and George were in effect driving the process, everyone realizing that their success with the coding was essential to the team.
What did not work so well in the project when it comes to project management? It has been problematic to plan the use of time in a realistic way. Our lack of experience with PLENTI and web application development resulted in frequent ad-hoc estimates. This was particularly difficult in the beginning of the project. During the development process we naturally gained more insight into PLENTI and web application development, which made it easier to make realistic estimates.
Morgan and Owen took on the main responsibility of making the final report, leaving the design and programming-related contents to the programmers. Until the last weeks of the project, and with the exception of a data model which was created early in the project and had been heavily modified after the customer meeting on March 28. the creation of models and diagrams to be used in the project report was largely ignored by Ethan and George, who were mostly concerned about coding and debugging. Ethan and George were regarded as the ones having control of the totality of the system under development. George was highly estimated for his programming skills. The rest of the team, in his absence, referred to how they needed him to get going on particular tasks for the project to succeed.
In respect of achieving good project management: What would you do differently if you later on participate in a similar project? If we had worked more intensively in the beginning of the project with our understanding of PLENTI, and the more advanced functions that we ended up using, project management and scheduling would probably have been a bit easier. The formerly mentioned period of inactivity was redeemed by a good customer meeting, and this might have been held earlier. Also we could have used the PLENTI email list earlier, as we got good user support from the PLENTI developers there. In the final oral presentation on May 25, the team spent much time describing the role of PLENTI in their project: how PLENTI had caused trouble, how the solution was based on PLENTI, and how interaction with the PLENTI developers had been essential. A certain pride with the process was observable in the team.
Ethan made the architecture model asked for on several occasions by customer and supervisor. Suggestions to Ethan from Owen and Sam in the direction of a layered design model were turned down by Ethan, who continued to regard PLENTI as somehow noncompliant with a layered architecture and came up with a model following his own notation.
In the individual reflection note, written by each team member as a supplement to the common reflection note, Ethan does not make a point of his role in respect of PLENTI when explaining his role and tasks in the project. He mentions his main responsibility for coding related to the user interface (CSS and HTML), for making diagrams, and for reviewing and addressing language issues in the report. In the note, responding to the question about whether he would have liked to have a different role in a similar project on a later occasion, he states that: “I am very happy about what I have been working with in the project”.
The following comment to a draft version of this paper was made by Owen: “In the absence of a thorough elaboration phase in which one builds a well defined software architecture and decide on the design of the system, a lot of the development and design of the product was up to those actually writing the larger part of the code”.
5.1.4 Fourth phase (April-May): Contribution to PLENTI The point at which Ethan started discussing with Bernhard about possible contributions to PLENTI might be seen as the start of the phase in which the team were seen as, or saw themselves as, contributors to the PLENTI community.
6. DISCUSSION From the chronological presentation of findings, we note that the transition from the second to the third phase of interaction with the PLENTI community was essential to the project. It was in the third phase they got access to the knowledge they needed to be able to utilize the framework. The fourth phase, contributing to the development of PLENTI, was not strictly necessary for the project team to succeed with their development task.
Three main events constituted the contribution part of the team’s interaction with PLENTI. First, there was a nightly build of PLENTI in which the changes directly resulted from requests from the Anniva team and a bug subsequently discovered by Bernhard. Second, the team wanted to integrate the system with a MySQL database, for which there was no support in the framework. In this case, Bernhard indicated how long it would take to implement the
796
new knowledge in the context of the team’s work. Nothing would have prevented the other team members from communicating with Bernhard if they wanted to. However, the division of labour letting Ethan take on the role as broker and gatekeeper seems to be generally agreed-upon in the team, perhaps because they acknowledged his abilities to attend to the interests of the team.
Getting from the second to the third phase can be seen mostly as a result of the team’s realization that progress was too slow and that something must be done. The means for the transition to take place, was the interaction with the OSS community, the only place where the necessary knowledge could be found. In what follows, we will focus on an important mechanism enabling this interaction: the brokering performed by one team member.
Second, Ethan is fairly active in taking and keeping the role as broker, thus in a sense defending it as his domain. For instance, in meetings, when unresolved, PLENTI-related issues arise, he is quick at suggesting that he pose a request to the community.
In our case, Ethan took on the role of broker between the team and the OSS community. In the community, he presented the team’s challenges in a way which was meaningful to the OSS developers. Back in the SE student team, Ethan explained what Bernhard’s feedback meant to their work and translated it into Java code in collaboration with the other programmers.
Third, Ethan’s communication with the PLENTI community is done through postings partly sent outside the hours of collocated work in the SE team. The questions asked and the interpretations made in the OSS community are therefore withheld from, or at least distanced from the collaborative activity of the team. No one in the team ever expressed any dissatisfaction over this. This might point to the team’s general appreciation of members’ flexibility of work (time and place), but may also indicate satisfaction with the way Ethan reflected their discussions and represented their interests in the OSS community.
In the brokering process, there were artifacts that can be seen as boundary objects [15] enabling meaning-making across communities. The auctioning system, from the outset unknown to Bernhard, gradually became more useful in mediating interaction as specific modules were discussed and changed. Pieces of code were described but also submitted in ‘raw’ format, explored, and perhaps modified and returned. Further, the PLENTI framework itself mediated the interaction: From the start, PLENTI was well known to Bernhard but not sufficiently mastered by Ethan and the team. As the interaction proceeded, the team’s knowledge improved to the point that it became meaningful to discuss changes to PLENTI itself. The roles of the boundary objects in each of the communities were of course different: For the SE team, PLENTI was a means to develop a working auctioning system. To Bernhard, having someone doing development by the use of PLENTI was a means to improve PLENTI itself.
6.1.2 The programmer increasing his power The role as broker towards a developer community must be held by an individual having enough knowledge about development to be able to effectively communicate over issues important to the community. In practice, this means a programmer. As argued in section 2, programming skills give authority in the SE teams. The programmer brokering towards a developer community gets more programming skills and thus more power. The following points from our case serve to illustrate how being a programmer is highly central to the broker:
We leave the elaboration on boundary objects at this point, noting that they should be seen as integral to the brokering and enriching our understanding of the process. Having argued that Ethan was in fact a broker, we turn the discussion to how the brokering empowers the broker, with possible effects on the SE project.
First, in the OSS community, the language of interaction is largely source code as well as considerations on aspects of source code, on the level of single lines of code and on the level of modules and versions of the entire system. Ethan makes his requests understandable to Bernhard by giving excerpts from their source code, and receives answers directly addressing aspects of the code or even containing modifications of the code itself. In addition to being able to ‘speak code’, there is a need to follow the implicit rules of communication in the forum. It is an open question whether programmers generally have a better starting point for communicating in virtual developer forums, but it is not unlikely that many programmers are experienced in gathering information from this type of site. In all his contributions to the PLENTI users’ forum, Ethan demonstrates a high degree of literacy in terms of this communication channel. His contributions appear friendly, polite, concise and goal-directed, and always appropriate to the context.
6.1 The power of the broker We suggest that the broker between a SE team and an OSS community gains increased power in the team in three ways: 1) through his position as gatekeeper of knowledge needed by the team, 2) through strengthening his existing authority as a programmer, and 3) through increased credibility in both communities through the feedback provided in the OSS community In what follows, we pursue these arguments referring to our case.
6.1.1 The power of the gatekeeper As the broker translates knowledge from one community to the other, he simultaneously controls which information flows between the communities. It is the broker’s interpretation which will reach each community, even if he faithfully aims to represent the community’s interests and not his own vested ones. When the receiving community depends on the information to succeed with their core activities, controlling the information is a great source of power and an opportunity to control the agenda. Some characteristics of our case point to the gatekeeping role of the broker.
Second, being a broker, you need to represent your community. Representing a SE team in the context of a developer community means being accountable for the software produced by the team. It is difficult to see how team members other than Ethan and George, who had the hands-on experience with the current version of the code and its unresolved bugs as well as the overview of the current version of the system, could have communicated with PLENTI developers over development issues. In face-to-face meetings with project stakeholders, e.g. the customer, Ethan frequently took on the task of articulating the status of work and the current issues and priorities of the team. This worked only partially, as Ethan’s role and conduct was not quite accepted by the customer. In the OSS
First, it is only Ethan in the team that interacts with the PLENTI community. Thus, no one else actually passes the only gate towards the PLENTI community, namely the listserv, apart from reading the resulting threads there and taking part in the interpretation of the
797
community. On the other hand, the project report suffered from a lack of attention from the programmers. The poor quality of the report was a main reason for the project receiving a B and not an A, according to course staff in the grading meeting.
community, however, Ethan always convincingly represented the team and their work. Third, illustrating the previous point, no one in the team but Ethan actually took any initiative towards the PLENTI community. It was not until the lead programmers decided that something must be done about the lack of PLENTI skills and usage in the project, that effective interaction happened. In our case, it took a programmer not only to undertake the role as broker, but also to understand that someone needed to take that role.
It is only a guess that the team in our case would have been no more concerned about the project report if they did not have to interact with an OSS community. The focus on programming (at the cost e.g. of developing models and documentation) might be seen as a consequence of a lack of experience and maturity in terms of project management, or as a legal choice of prioritizing what was to the team the essence of the project. In respect of the team postponing the work with design and architecture modeling, it is worth noting that the PLENTI framework can be seen as an example of a third party software component, unfamiliar to the team and poorly documented, which implies a realistic SE challenge of determining when to attempt to develop an overall design and when to start using the component [6].
6.1.3 The credibility gained through OSS participation Being acknowledged as a participant in a developer community is likely to add to the self consciousness of the participant. When a contribution is met by a response in a forum, the community membership of the contributor is acknowledged. When a contribution is openly praised in the forum, the skills of the participant are implicitly valued, and his credibility in the forum is maintained or strengthened. If the participant is relatively inexperienced and do not already participate actively on several related arenas, the newly earned credibility is likely to be a source of pride and increased self confidence. Also, the credibility won can be demonstrated to others outside the community, adding to credibility and strengthening authority there as well. From our case, we draw some illustrative points:
Communicating in the OSS forum appeared to be a gratifying experience for the broker. The team was vulnerable to his absence, but that problem never occurred. Also, our observations indicate that the broker shared his knowledge from the OSS forum with the rest of the team in an open and effective way. It is difficult to say if he spent too much of the project time in the forum, or if the team spent too much time on programming tasks based on the results of the interaction. The fact that the interaction took place only in the last part of the project, indicates a limited use of project time. Also, the team’s interaction with the OSS community having to do with changes to PLENTI constituted only a small part of the interaction. Finally, these discussions were closely related to pertinent development tasks in the project.
In Exhibit 4, the last response from Bernhard to Ethan includes the following: “Wonderful! Several people have asked for it in the past, it would be a very welcome contribution to the project.” The contribution of Ethan and the team is thus publicly acknowledged as something relevant and welcome. The positive response was referred to by Ethan on later occasions, e.g. in customer meetings. In team-internal conversation, Ethan on some occasions talked of Bernhard almost as if he was a buddy, using his first name. Ethan also pointed out to the team how quick Bernard was at providing them with response, and often outside of normal work hours.
The fact that Ethan did not mention in the individual reflection note his role in the communication with the PLENTI community, might indicate that he did not consider it as something requiring a substantial part of his time or being very important to the project, but there may be other reasons why he did not mention his brokering role. As for the power of the broker, Owen (on reading a draft of this paper) expresses uncertainty about how much power Ethan gained through his gatekeeping role. Owen had not until now reflected much on the importance of the interaction with the PLENTI community. It may be the case that Owen and Ethan take their successful OSS community interaction for granted, underestimating the communication skills actually required.
Ethan’s pride in the engagement of the team with the PLENTI developer community was very visible whenever the project was accounted for in meetings with supervisor or customer in the last part of the project. On one hand, referring to ongoing successful interaction with the PLENTI community served as a way of ensuring project stakeholders that the project was in fact progressing. On the other hand, it may be seen as a way of assuring the stakeholders that the team were competent, doing development work of a standard acceptable to the framework developer community.
6.2 OSS community participation aided by a broker: Benefits and pitfalls for SE projects
Finally, balancing our previous focus on the significance of OSS participation to the team, we should note that communicating with the PLENTI community was one out of several activities important to the project. The power structures in the team may be seen to have mirrored the complementary skills and interests of the two lead programmers, which ensured a certain balance in power between the two. Nevertheless, given our findings, our interpretation is that the team, and the broker in particular, were both challenged and inspired by the fact that they were participants in, and contributors to the PLENTI OSS community and considered it an essential part of their project experience.
Turning focus to what we see as benefits and pitfalls of having student SE teams acquire knowledge from OSS communities, we give a final account of the impact of OSS community involvement on the Anniva team, looking at their project more broadly.
Leaving the story of the auctioning system project, we now turn to what we see as more general benefits and pitfalls – in terms of a good project result - for student SE teams in need of interacting with OSS communities as part of their development work.
Finally, whereas the fourth phase of OSS interaction, contributing to the framework, might not have been strictly necessary for the team’s development task, it might have benefited the development task indirectly: Ethan’s positive attitude towards contributing to the PLENTI development might have inspired Bernhard to give better, faster or more elaborate response.
The team succeeded with their development task, producing a working system by active use of advice received from the OSS
798
believe to be generally relevant to student projects interacting with OSS communities as a resource in their development work, we would like to stress that the particular challenges of OSS participation in one project may be very different from those in another. Considerations over project management and supervision must always be made in the light of the particular characteristics of the specific project. In this respect, the project supervisor will always benefit from having experience with the approaches and domains relevant to the project. In the type of project of our current focus, some background within OSS development or research is likely to be an advantage to the supervisor.
6.2.1 Benefits for SE student projects interacting with OSS communities In line with arguments from others’ research, we hold that OSS community participation is a realistic aspect of modern SE work. The management of such interaction should be regarded as highly relevant industry SE experience. If the team interacts with an OSS community, part of the experience is shared by the whole team. The broker in particular may learn a lot about how to achieve successful communication and acquire relevant knowledge in an OSS community. A broker whose authority and importance in the team is acknowledged by the team is likely to take pride in his position as a knowledge provider and thus be strongly motivated to contribute to the project result. If the broker further experiences that he earns credibility on the OSS arena, being recognized as a proper participant there, he might want to make his contribution more substantial and visible, which may again benefit his team.
In a situation in which many of the projects in a course include OSS community participation, the overall organization of the course may be designed to reflect this particular focus. For instance, lectures may be given on how OSS communities work. Each project’s interaction with the OSS community may be more explicitly used as a learning resource, e.g. by being examined and discussed within and across teams. Further, the OSS community interaction of a team should be considered as a learning result (or documented part of the project process) and assessed and credited by course staff, e.g. in the grading of the projects.
6.2.2 Pitfalls for SE student projects interacting with OSS communities Student SE teams may hesitate to embark on interaction over technically challenging issues in a type of community unknown to them, the students being in doubt about their own skills and credibility. This may cause problematic project delays. Also, attempts to interact with an OSS community may turn out to be nonsuccessful if the team does not manage to convince the community that they represent ‘real’ users and development issues and thus qualify as potential contributors.
6.4 Limitations to the study Drawing on a single case, our findings may be seen as closely related to its particular characteristics. Still, we believe findings from our study on the role of the broker have general relevance to SE student projects interacting with OSS communities. An important characteristic of the OSS community of our case is its small size, which may be seen as a condition for the rapid entry of the student team into OSS development contribution. Arguments about the empowerment of the broker however apply even if OSS community participation is restricted to the user role.
To a team inexperienced in project management, interaction in an OSS community may pose great challenges because it involves an extra external stakeholder and may be perceived as even more out of control than other programming related activity. OSS community participation can be used as an excuse to spend time on the wrong tasks from a project management point of view. Having an alternative arena for gratifying response and acknowledged participation might lead a programmer to focus too narrowly on certain programming tasks related to that arena.
Finally, our research explored a student team. Our findings may have some relevance to teams of SE professionals, but differences between these categories of SE teams should be considered. These include the level of competence in project management in the team, and the formalized learning goals of a project course which are not found in industry and which impact on how we wish to guide the SE student teams through project supervision.
Brokering may be performed in an inadequate way: A broker unable or unwilling to share relevant knowledge with the team, or mainly representing other interests than those of the team in the OSS community, stands in the way of a good project result and everyone’s learning. Further, there is a risk associated with having only one broker – both in case of inadequate brokering and in the case of sudden absence of the one broker.
7. CONCLUSION In this study, we set out to gain insights on mechanisms enabling a SE student team to successfully interact with an open source community and on possible pitfalls and benefits of the engagement in terms of project success. We have done so by pointing to the role of the broker and how this role implies increased authority and influence in the team for several reasons and with several possible consequences, positive and negative.
6.3 Implications for the pedagogy of SE project courses An implication of the work presented in this paper is that course staff responsible for SE project courses should pay particular heed to SE student projects requiring interaction with OSS communities for development-related knowledge acquisition. These projects hold a potential for industry-relevant experience but at the same time hold some challenges. Course staff should be aware of benefits and pitfalls inherent to this type of project. Further, awareness of the mechanism of brokering and the potentially influential role of the broker(s) in the projects may aid a supervisor in determining what advice to provide on project management and process issues.
We hope that our contribution will inspire SE course staff and others involved with SE student projects to build on our work with reference to their own experience. Continued focus on work and learning in SE student projects involving OSS community participation should result in empirically based research contributions for us all to share, with the aim of improving current pedagogical practices. Further work may look at the implications of the type and sizes of the OSS communities for student teams’ involvement there. Also, the relevance of OSS participation in student SE projects to similar
Part of the charm of industry projects is that they are very diverse. Having used our in-depth single case study to derive issues we
799
Concept of Media Stickiness," Computer Supported Cooperative Work, vol. 12, pp. 411-436, 2003.
situations in real-life industry projects – and vice versa - are topics worth pursuing. [12]
C. Gutwin, R. Penner, and K. Schneider, "Knowledge sharing in software engineering: Group awareness in distributed software development " presented at CSCW'04, Chicago, Illinois, USA., 2004.
[13]
M. Bergquist and J. Ljungberg, "The power of gifts: organizing social relationships in open source communities," Information Systems Journal, vol. 11, pp. 305-320, 2001.
[14]
E. Wenger, "Communities of practice and social learning systems," Organization, vol. 7, pp. 225-246, 2000.
[15]
[3] B. Bygstad, B. Krogstie, and T.-M. Grønli, "Scaffolding Project Based Learning with the Rational Unified Process. Experience from 5 years of Student Projects in Software Engineering," presented at NOKOBIT, Molde, 2006.
S. L. Star and J. R. Griesemer, "Institutional Ecology, 'Translations' and Boundary Objects: Amateurs and Professionals in Berkley's Museum of Vertebrate Zoology, 1907-39," Social Studies of Science, vol. 19, pp. 387-420, 1989.
[16]
[4] D. Wood, J. Bruner, and G. Ross, "The role of tutoring in problem solving " Journal of Child Psychology and Psychiatry, vol. 17, pp. 89-100, 1976.
W. Sacchi, J. Feller, B. Fitzgerald, S. Hissam, and K. Lakhani, "Understanding Free/Open Source Software Development Processes," Software Process Improvement and Practice, vol. 11, pp. 95-105, 2006.
[17]
[5] P. H. Carstensen and K. Schmidt, "Computer Supported Cooperative Work: New Challenges to Systems Design," in Handbook of Human Factors/Ergonomics, K. Itoh, Ed. Tokyo: Asakura Publishing, 2002 (1999).
K. Crowston and J. Howison, "The social structure of free and open source software development," First Monday, vol. 10, 2005.
[18]
[6] J. Li, R. Conradi, C. Bunse, M. Torchiano, O. P. N. Slyngstad, and M. Morisio, "Development with Off-The-Shelf Components: 10 Facts," IEEE Software, 2007.
A. Mockus, R. T. Fielding, and J. D. Herbsleb, "Two Case Studies of Open Source Software Development: Apache and Mozilla," ACM Transactions on Software Engineering and Methodology, vol. 11, pp. 309-346, 2002.
[19]
M. Riel and L. Polin, "Online Learning Communities. Common Ground and Critical Differences in Designing Technical Environments," in Designing for Virtual Communities in the Service of Learning, S. A. K. Barab, Rob; Gray, James H., Ed. Cambridge: Cambridge University Press, 2004, pp. 16-50.
H. J. C. Ellis, R. A. Morelli, T. R. deLanerolle, and G. W. Hislop, "Holistic Software Engineering Education Based on a Humanitarian Open Source Project," presented at CSEE&T, Dublin, Ireland 2007.
[20]
K. Toth, "Experiences with Open Source Software Engineering Tools," IEEE Software, 2006.
[21]
[8]
E. Wenger, Communities of Practice. Learning, Meaning, and Identity: Cambridge University Press, 1998.
D. Spinellis, "Open Source andProfessional Advancement," IEEE Software, 2006.
[22]
[9]
C. McDowell and L. Werner, "The Impact of Pair Programming on Student Performance, Perception and Persistence," presented at ICSE'03, Portland, Oregon, USA, 2003.
L. Jaccheri and T. Østerlie, "Open Source Software: A Source of Possibilities for Software Engineering Education and Empirical Software Engineering," presented at First International Workshop on Emerging Trends in FLOSS Research and Development (FLOSS'07), 2007.
[10]
J. Lave and E. Wenger, Situated Learning. Legitimate peripheral participation. Cambridge: University of Cambridge Press., 1991.
[23]
R. K. Yin, Case Study Research. Design and Methods. Third Edition., vol. 5: SAGE Publications, 2003.
[24]
H. K. Klein and M. M. Myers, "A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems," MIS Quarterly, vol. 23, pp. 67-94, 1999.
8. ACKNOWLEDGMENTS The author wishes to thank Glenn Munkvold, John Krogstie, Owen and Ethan for feedback on draft versions of this paper. Monica Divitini and Thomas Østerlie provided valuable advice.
9. REFERENCES [1] B. Krogstie and B. Bygstad, "Cross-Community Collaboration and Learning in Customer-Driven Software Engineering Student Projects," presented at CSEE&T, Dublin, 2006. [2] L. v. d. Duim, A. Jesper, and M. Sinnema, "Good practices for Educational Software Engineering Projects," presented at ICSE'07, Minneapolis, USA, 2007.
[7]
[11]
M. Huysman, C. Steinfeld, C.-Y. Jang, K. David, M. Huis in 't Veld, J. Poot, and I. Mulder, "Virtual Teams and the Appropriation of Communication Technology: Exploring the
800
