Hybrid Open Source Software projects are virtual organizations that express characteristics of both static and dynamic behavior. They are choreographed through complex organizational structures that mix centralized governance with distributed community drivenness. While many communities use standard software tools to support their development processes, each community has its own ways of working and invisible power structures that in uence how contributions are submitted, how they are veri ed and how decisions about the long-term direction of the software product are made. Navigating this environment is especially challenging for new developers who need to prove their abilities to gain rights to make contributions. This paper provides a viewpoint on the factors that in uence a new developer's perception of the hybrid OSS developer community landscape. We apply an established developmental theory to build an initial model for the developer's context and discuss the model's validation, providing its practical and theoretical implications for building and managing on-line developer communities.
Open Source Software (OSS) products are built collaboratively by developers that jointly form a developer community. These communities are geographically distributed, and they use virtual work environments, software tools and on-line collaboration platforms, along with mutually agreed policies and practices for developing their software product as a common good [Kil14]. Developer communities can comprise of independent individuals or representatives of companies, or in the case of "hybrid" communities: both [GBICMR13]. In hybrid communities, development decisions are in uenced by versatile goals of individuals and often competing commercial interests [TRGB15]. Therefore, ensuring that stakeholders have equal opportunities to contribute is key for sustaining the reciprocity of the collaboration and the motivation of the community's members.
Even though individuals exist within the same context in developer communities, they may perceive their environment in di erent ways. This is especially true for new developers, who are yet to learn about the culture, customs and realities of the community they want to join. So far, research has been performed on how developer communities should be organized to accommodate participation [DGO11, WO08], what factors help entry and on-boarding of its members [FGMB14, FSBM14], and which traits healthy and welcoming communities should display [Jan14, WJ07]. However, connections in between the community context and the developer's experience have largely been unexplored, due to e.g. the lack of a common vocabulary in describing the community phenomena [AdOJ17]. In this paper, we address this gap by linking current literature on developer community context and management to the viewpoint of an individual developer by using an established theory of environmental factors in human development [Bro77]. By studying the \Where, Who, and What" of the Hybrid Open Source developer community context, we aim to lay ground for new understanding on how hybrid developer communities can be built and managed to be welcoming for new developers.
This article is structured as follows. Section 2 rst reviews how the hybrid OSS community context can be understood based on recent literature. Section 3 provides an overview of the Ecological Systems Model of Bronfenbrenner [Bro77], and describes its application to the hybrid OSS developer community context. Section 4 discusses and concludes the work.
One of the rst models to describe online developer communities was the onion model of Nakakoji et al. [NYN+02]. The model focused on the developers with the most in uence on the source code, establishing the terms "project leaders" and "core developers", who base their actions on implicit knowledge about the roles of the group and trust their peers in "just doing what needs to be done" [MFH02]. In Nakakoji's model, role of "co-developers" was di erentiated to active developers and peripheral developers who delivered source code updates, yet were not in an active role in decision-making. Within this group, distributed communication of the developers increased requirements for work coordination, quality assurance and transparent, merit-based accreditation [MFH02]. The exterior layer of the model became formed by passive software users, community bystanders and bug reporters who had no direct contact with the source code [NYN+02]. While inviting new contributors and sustaining them contributes to the sustainability of a project [Jan14], it has long been preferable that new members enter the community through the outer layers and proceed towards the core based on their gained merit [YK03, NYN+02].
Today, OSS developer communities can be enveloped in an ecosystem of third party bene ciaries, who build their businesses on the OSS software produced by the community. These stakeholders can interact through shared socio-technical systems [FBACF17], taking approaches towards the developer community that can vary from symbiotic to opportunistic behaviors [DM05]. The commercial actors do not necessarily need to climb up the meritocracy ladder, yet they can e.g. deploy developers to the project or be granted special privileges in its decision-making based on partnership models [SWvK15]. As the stakeholders can be erce competitors on a shared market [TRGB15], they can be forced to form strategic alliances to advance their mutual goals such as stability or interoperability of the software [FBACF17]. These invisible power structures are hard to perceive, yet they can in uence priorities of development and decrease a new developer's say in the project. Here, a well documented governance model, along with transparent and consistent management practices can help to increase equality among contributors [BJ12].
As the hybrid environment with mixed goals and motivations grows in size, a commercial or foundation-based central organization ("community sponsor") can be established to ensure the community's sustainability by orchestrating its work. To support its operation, the central orchestrator can deploy paid contributors to the project [WO08] and sponsor and manage the community's development tools, allowing it to control the development process to a degree. The orchestrator can also acquire funding, recruit new developers and arrange marketing- and community-building activities, which play an indistinguishable role in growing the community and ensuring its health [MH13]. A community ecosystem needs to endure changes and sustain its productivity in changing settings [MH13]: health can be seen as a mix of the community's internal performance, its vigor and its resilience to external disruptions [WJ07]. To support these aims, it is vital to understand how new developers need to be supported to become productive members and increase their participation in the community's activities.
A key element in the hybrid OSS community phenomenon is its governance: the way an organization is managed, including its powers, responsibilities and decision making practises [DK09]. Governance principles include how rights to participate are managed and how responsibilities are allocated amongst the community's members [Jan14]. This includes the assignment of roles and decisionmaking rights, as well as the measures and policies that enable continuous assessment of the developer organization's performance and well-being. When the community operates in a transparent way, its members can feel they can understand the community's state and have an opportunity to in uence development activities and processes. Restricting autonomy of the open developer community may endanger the developers' motivation. This is especially true in hybrid projects where the governance structure can a ect the motivation of outside volunteers' participation [Sha06] and thus, also the uptake of the software.
A software developer's experience is tied closely to the project's development tools and infrastructure, the developers' feelings about their work and the sense of value that they see for their contributions [FSBM14, KM06]. In a healthy community, members should be able to achieve su cient returns for their work, to satisfy their needs and be encouraged to make new contributions [WJ07].
Here, individual work tasks and their relevant knowledge become an essential Discipline
De nition of context Source Management Circumstances, conditions, situation or environ- Welter [Wel11]. science ments that are external to a speci c phenomenon
and that enable or constrain it.
Organization Situational opportunities and constraints that af- Johns [Joh06]. behavior fect the occurrence and meaning of organizational behavior as well as functional relationships between variables.
Contextaware puting
Location of use, the collection of nearby people Schilit [SAW94]. com- and objects as well as the changes to those objects
over time.
Software Rich and complex network of elements across dif- Antunes et al. development ferent dimensions such as personal, project, orga- [ACG10], De nization, domain, product, teams, etc. Araujo et al. [DSB+04].
Linguistics
Meaning surrounding intra-textual clues that may Chin [Chi94].
be based on or be outside of the text itself.
Hybrid OSS Combination of open community-driven devel- Sharma [SSR02]. development opment and company internal development procommunities cesses.
OSS commu- A thematic division of developers into core and Nakakoji et nities periphery based on frequency of contribution and al. [NYN+02], nature of their contributions. Mockus et al. 2002 [MFH02], part of the context [KM06]. In the online developer community realm, this context expands to a wide variety of freely available information and online tools such as the versioning system, work ow coordination and quality management tools, which together with discussion forums, chats and mailing lists make distributed coordination and collaborative decision-making possible. Interactions amongst the community's members take place in both formal meetings and informal, spontaneous online commentaries. In the hybrid environment, a part of the discussions and the project's decision-making take place outside the reach of the open community. This can limit the sense of own possibility to in uence developments and hamper meaningful social interactions, which are known to be major barriers for the entry of newcomers to OSS projects [SSGR15].
In OSS communities, newcomers are required to prove their ability and motivation to make meaningful contributions to the project before they can acquire rights to make changes to the software source code and participate in decision-making about the software product's future [SSR02]. To achieve this, new developers need to grasp not only the touch points for participation, meaning of the software's licensing and governance processes, yet they also need to understand the social dynamics and inherent conventions of the community. Inherently, the organization of the development process, access to decision-making and tasks, along with transparency of knowledge and processes form an important leverage for managing contributions[WO08]. Successful entry to a community is greatly dependent on the community's ability to provide this information and mentor new contributors to achieve an active role, which in part relies on a smooth learning process for new developers and their swift integration to the socio-cultural values, work processes and prevailing practices of the community[FSBM14]. Hence, designing and managing the entry process of new developers requires understanding of the nature of the community context and its re ection on the new developer's experience.
The hybrid OSS ecosystem is a complex context, which we chose to explore through the lens of the Bioecological model of Bronfenbrenner (1979) that explains personal learning as "a function of forces that originate from the versatile settings amongst which the individual is a part of" [Bro79]. The model organizes environmental factors as layers similar to that of the Onion Model, positing the individual human being with his or her personal characteristics in the epicenter. Bronfenbrenner's view emphasizes a person's learning as an experiental process to which a person's most proximate interactions have the most in uence. The approach can be used to divide the hybrid OSS ecosystem context to four layers: its micro-, meso-, exo- and macrosystem.
The microsystem level illustrates phenomena of practical everyday life: a person's most immediate surroundings and human contacts. More distant phenomena such as infrequent contacts, local culture and its institutions are positioned to the exosystem level. The layer in between, mesosystem, represents interactions between the micro- and exosystems, emphasizing the synergistic nature of the phenomena. As the exterior layer of the model, Bronfenbrenner describes the concept of a macrosystem, which deals with the values, events and expectations of the surrounding culture and society at large.
Bronfenbrenner denotes that all the layers have symbiotic relationships with each other and as for the ever-evolving nature of reality, are subject to changes in time (chronosystem). We used this thinking to depict the hybrid OSS ecosystem context in Figure 1. The next chapter, along with Table 2 elaborates the elements in our proposal in detail.
We used examples from literature presented in Section 2 to deploy the di erent layers of the Bioecological model. In our application (Figure 1), the individual software developer is placed as the focal point: as both a perceiver of the hybrid ecosystem context { and the subject of action and related personal development.
Each individual has her personality, competencies and preferences that re ect to the ways in which the person sees the community's opportunities for interaction. The experience can be divided into cognitive, conative and a ective aspects which guide her reactions to her surroundings [FGMB14]. Around the individual exists a microsystem of direct in uences such as the developer's contributions to the project, personal responsibilities, along with her interactions with peers and shared knowledge repositories such as the source code, online documentation and discussions.
Interactions with the microsystem phenomena take place in face to face settings, or as typical in online communities: through synchronous or asynchronous personal interactions with the help of socio-technical tools and platforms. The microsystem's factors enable, allow and invite engagement, as well as inhibit participation and complicate proximate processes of the individual with her immediate environment [BM06]. The exosystem layer gathers phenomena that are Stakeholders Requirements engineers, code authors, committers, re- [NYN+02] viewers and maintainers. Own team members, mentors [FSBM14]
Individual
Microsystem Own competencies, goals, motivations and feelings. [FGMB14] Own knowledge, tasks, contributions, responsibilities, [KM06] own status/rank as a community member. [SSR02] [Jan14] Software source code. Personal development tools and [Kil14] common platforms: requirements management systems, code review/testing and continuous integration tools, shared knowledge repositories.
Mesosystem: (the connecting layer) Organization Code submission-, review-, testing-, integration- and [WO08] of production release processes. Collaborative relationships amongst [NYN+02] community members.
Exosystem Architecture of the software product. Rules and con- [SSR02] ventions. Licensing and IPR strategy. Organization and [WO08] governance of the community and its orchestrator. [DK09] Stakeholders Di erent project teams and sub-communities. Project [NYN+02] lead and high-level decision-making organizations, soft- [FBACF17] ware users. Goals of partner organizations and keystone players. related to the community's internal culture and governance model, which indirectly in uence the individual's environment and the way in which she engages with her microsystem. These two are connected by the mesosystem: the community's processes, including the di erent manual and automated stages of the software development process, along with its decision-making- and accreditation mechanisms. These de ne the community in terms of its structures, processes and events that occur outside the developing individual's immediate surroundings. The macrosystem comprises of the external environment that surrounds the OSS project and exists independently from it. However, it in uences the exosystem and subsequently: the individual's behavior. While the Free and Open Source Software (FLOSS) ideology is emblematic to the environment, other prevailing phenomena include the technological landscape, prevailing business models, stakeholder alliances, industry- and market trends.
The Open Source development context is traditionally viewed through the notions of the Onion model and the core-periphery distribution of community members. We extend this de nition by proposing a new application of an established theory on external factors in human development by Bronfenbrenner [Bro79] into the hybrid OSS ecosystem environment. We do this to build initial understanding on how the software ecosystem context can be perceived by a new developer that wishes to enter the community. Several factors may limit validity of our proposal. Firstly, Bronfenbrenner's Bioecological model of human development was originally created for analyzing the early stages of human development, including childhood and adolescence. Therefore, generalizing it for global, distributed software development can be questioned. However, it can be assumed that as a software developer enters an OSS project, she encounters a profound cultural adaptation process which requires learning both the shared language of the community, its ways of working, and its prevailing socio-cultural value systems.
Our proposal is based on literature introduced in Section 1, along with personal expertise of the authors. As three practitioners have given generous feedback at di erent stages of its development, we claim that our application provides a su ciently reliable representation of the software ecosystem context. However, we acknowledge several places for improvement based on this feedback. More attention to the microsystem level could be placed by observing or interviewing new developers who still need help in comprehending their environment. Also, further inquiries of active community members who mentor new contributors to the project could shed light on the di erent exosystem phenomena. Finally, the mesosystem layer could be amended by studying the role of corporate processes as a factor of the ecosystem, which, however is applicable only to the special case of commercially orchestrated communities.
With- or without these improvements, our application can be used for further studies - as shown by the rich explorations of the Bronfenbrenner's model in social sciences (documented in e.g. [BM06]). Learnings from this line of research can provide con dence for building new experimental research designs that address interrelationships, change and continuity in the hybrid OSS ecosystem context. While most activities in OSS development leave a digital trace, researchers should be able to validate their results through rigorous practice. Future studies could ask bold questions to nd e.g. connections in between management and practice: "Do strict and explicit conventions lead to less testing of newcomers' code contributions?", "Does a hierarchical governance model decrease the need for coordination?" or "Does transparency of long-term planning lead to prolonged commitment to the project?" As a more distant goal, the veri ed model could help discovering metrics which operationalize health of communities in terms of their intake and retainment of contributors. This could provide new practical understanding on which factors should be placed in the limelight of community management while designing entry paths for new developers and facilitating their personal validation as new, productive members of a community. [ACG10] [SSR02] [TRGB15] [WJ07]