The work-reflection-learning cycle - Department of Computer and ...

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.
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.
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].
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.
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
110