Megan Squire
email: msquire@elon.edu

Considering the Use of Walled Gardens for FLOSS Project Communication

Keywords: Open source, free software, communication, email, mailing list, IRC, Stack Overflow, Slack, Apache, Wordpress, teams, chat

At its core, free, libre, and open source software (FLOSS) is defined by its adherence to a set of licenses that give various freedoms to the users of the software, for example the ability to use the software, to read or modify its source code, and to distribute the software to others. In addition, many FLOSS projects and developers also champion other values related to "freedom" and "openness", such as transparency, for example in communication and decisionmaking, or community-orientedness, for example in broadening access, collaboration, and participation. This paper explores how one increasingly common software development practice -communicating inside non-archived, thirdparty "walled gardens" -puts these FLOSS values into conflict. If communities choose to use non-archived walled gardens for communication, they may be prioritizing one type of openness (broad participation) over another (transparency). We use 18 FLOSS projects as a sample to describe how walled gardens are currently being used for intra-project communication, as well as to determine whether or not these projects provide archives of these communications. Findings will be useful to the FLOSS community as a whole as it seeks to understand the evolution and impact of its communication choices.

Introduction

A common denominator between all free, libre, and open source software (FLOSS) projects is that they provide users with a software license that allows the user some level of freedom to read, modify, or distribute the software source code. Echoing these freedoms, FLOSS software is also produced in such a way as to foster openness and collaboration. For example, transparency in decision-making and welcoming participation are key values that are common to many FLOSS projects. These values have been called "open from day one" [START_REF] Fogel | Producing Open Source: How to Run a Successful Free Software Project[END_REF], or a "bazaar" style of organization [START_REF] Raymond | The Cathedral & the Bazaar: Musings on linux and open source by an accidental revolutionary[END_REF], and have been attributed to the "success of open source" [START_REF] Weber | The Success of Open Source[END_REF]. More recently the so-called "open source way" [START_REF]The Open Source Way[END_REF] is described as "a way of thinking about how people collaborate within a community to achieve common goals and interests" when applied to non-software contexts.

One software development practice that has traditionally been cited in the literature to preserve this openness is using publicly archived mailing lists for decision-making and important project-related communication [START_REF] Feller | Understanding Open Source Software Development[END_REF]. Mailing list archives preserve a transparent record of decision-making that can serve as an institutional memory and can help get new users up to speed quickly. Mailing lists also offer a technological openness, in other words a non-corporate-controlled, non-proprietary software system, ideally available under a FLOSS license. However, more recently, the FLOSS community has begun to ponder an additional perspective on openness: one that is defined by inclusivity and diversity of participation. [START_REF] Daniel | The Effects of Diversity in Global, Distributed Collectives: A Study of Open Source Project Success[END_REF][START_REF] Kuechler | Gender differences in early free and open source software joining process[END_REF][START_REF] Vasilescu | Gender and tenure diversity in GitHub teams[END_REF] An industry publication recently bemoaned that older communication systems used in FLOSS (specifically IRC) are "complicated and unfriendly" and "the barrier to entry was a formidable challenge for the first time user." [START_REF] Williams | Slack is quietly, unintentionally killing IRC[END_REF] In this paper, we attempt to describe how one increasingly popular software development practice puts these openness values -openness through transparency and licensing, and openness through inclusivity -into conflict. Specifically, communicating in "walled gardens", or non-open and corporate-controlled systems such as Slack or Stack Overflow, and not keeping archives of this communication puts the FLOSS goal of transparency into conflict with the goals of ease-of-use, inclusivity, and diversity of participation.

The remainder of this paper is organized as follows: first, we provide an overview of communication technologies used in FLOSS projects, and then we describe how a collection of 18 FLOSS projects currently relies on walled gardens for communication. For this, we use publicly available descriptions of existing FLOSS projects or repositories that are known to use walled gardens. By becoming aware of the size and scope of the practice of using walled gardens to communicate, the FLOSS community at large can choose how to react, including whether to embrace the practice, conduct additional research, take preventative measures, provide alternatives, or ignore the practice.

Communication Technology Used in FLOSS Projects

In keeping with the nature of FLOSS work as community-owned and communitydriven, each individual software team makes the decisions about which communication technologies to use, and when to adopt or reject a new technology. Each team has its own requirements and makes its own determination of the positive and negative aspects of each communication choice. Here we describe two main types of technology, asynchronous and synchronous technologies, and how different FLOSS communities have used each one. For each category, we describe the alternatives in terms of the various "openness" values described previously: openness via transparency, openness via licensing and non-corporate control, and openness via inclusivity and easeof-use.

Asynchronous Communication

Traditionally, many FLOSS communities have communicated using mailing lists. Some communities, such as the Apache project ecosystem, still require the use of mailing lists to conduct project business [START_REF]Apache Software Foundation (nd) Decision Making[END_REF][START_REF]Mailing Lists[END_REF]. There are several reasons for this preference. First, email is an asynchronous communication medium. Asynchronous communication allows for messages that can be sent and read at different times. (Other examples of asynchronous communication include paper mail, email, bulletin board systems, and Web sites.) Asynchronous communication works especially well for FLOSS teams that may be geographically distributed, since messages can be sent and read at the convenience of both parties. Another feature of email mailing lists that is helpful to FLOSS development is the ease of creating browsable, searchable mailing list archives. Feller and Fitzgerald write, "Archived discussions, which represent 'self-documentation' of projects, are critical in OSS development." [START_REF] Feller | Understanding Open Source Software Development[END_REF] Archives preserve a record of decisions and can help bring new contributors up to speed.

Finally, and significantly for many projects, generic email and mailing lists are standards-based, in that anyone can develop email software, and sending and receiving email requires no particular relationship or agreements with any single corporation. Email protocols and software are not owned or controlled by any one entity, corporate or otherwise. Generic email or mailing list systems can be contrasted with proprietary, but still asynchronous, systems such as the Google Groups web-based Usenet interface [START_REF] Braga | Google, a Search Company, Has Made Its Internet Archive Impossible to Search[END_REF], or Stack Overflow, a web-based Question and Answer site increasingly used by many FLOSS projects to handle many kinds of technical support [START_REF] Squire | Should we move to Stack Overflow? Measuring the utility of social media for developer support[END_REF]. Colloquially, these closed, corporate-controlled systems are called walled gardens.

Synchronous Communication

Some FLOSS teams also elect to use synchronous communication technologies, such as chat or instant messaging, in which the users are communicating back and forth in real time. For example, FLOSS teams may conduct developer meetings using Internet Relay Chat (IRC) [14; 15]. Real-time chat systems, such as IRC (but also recently including new entrants into this space such as Rocketchat, Mattermost, Discord, or Slack), are also used to share ideas informally, to get immediate technical help, and to build camaraderie in the community [START_REF] Fogel | Producing Open Source: How to Run a Successful Free Software Project[END_REF]. Because of the ephemeral nature of chat, communities may not approach it with the same expectation of being a long-term archive as they would expect from an email mailing list. Still, some communities and IRC channels are archived, usually through the use of special archiving bots. One impressive example of chat archiving is the Ubuntu IRC log collection, which is available at http://irclogs.ubuntu.com. These archives cover discussions happening on nearly 300 different Ubuntu-related chat channels, starting in 2004.

As with email and asynchronous discussion systems, synchronous systems differ in whether they are a product of a single corporation, or whether they are a FLOSSlicensed or open protocol. For example, IRC is an application layer Internet protocol, and as such anyone can run a server or develop a client for it. In contrast, Slack (https://slack.com), is a synchronous chat system developed and operated by a corporation, and its rules about costs, archiving policies, data sharing, number of participants, and so on, are determined by the corporation alone. Slack has a single client, and a Terms of Service (ToS) that restrict its use. Slack is not FLOSS licensed. We therefore include corporate-controlled, non-FLOSS licensed synchronous messaging services such as Slack in our definition of walled gardens.

How FLOSS Values Conflict When Communicating in Walled Gardens

In 2015, FLOSS developer Drew Devault wrote a blog post entitled "Please don't use Slack for FOSS projects" which argued that Slack is a walled garden, and any trend toward adopting it should be curtailed in favor of continuing with IRC which he says is "designed to be open". [START_REF] Devault | Please don't use Slack for FOSS projects[END_REF] The comments section of this post illustrates the conflict between the value of open design on one hand, and the value of openness through ease-of-use and inclusivity on the other hand. In those 187 comments, the value of "openness" is invoked for both arguments. Similarly, the Wordpress project, in rationalizing their move to Slack for developer and user chat [START_REF]Make Wordpress[END_REF] gives six reasons for the move, and the first three of those have to do with the user interface: "Open for everyone, Friendly user interface, Easy asynchronous conversation". With their invocation of "open for everyone" they are certainly referring to usability and not licensing, since Slack is not open source [START_REF] Baker | 4 open source alternatives to Slack[END_REF]. Interestingly, they also laud the ability of Slack to function in an "asynchronous" way, specifically contrasting it with IRC and Skype (which they call "real-time"). For this paper, we will continue to refer to Slack as a synchronous technology.

A related values conflict is whether FLOSS projects using walled gardens are being "open" (in the sense of transparent) if they do not provide archives of their communications. Should FLOSS projects need to provide archives of their communications, and do certain communication technologies make archiving easier or harder? In general, the asynchronous communication technologies like web pages and mailing lists are stored as files, and as such, will be easier to archive. FLOSS email mailing lists are usually archived both by the projects themselves, and archives for many projects are also available for search/browsing/downloading via third-party web sites such as MarkMail (http://markmail.org) and Gmane (http://gmane.org). Even though IRC is a synchronous communication medium, since it was invented in 1988, it has had many years to develop logging and archiving features, including a diverse set of archive bots. Text-based IRC logs are publicly available for many large projects including Ubuntu, OpenStack, Puppet, Perl6, many Apache Software Foundation projects, and so on. Projects using third-party synchronous walled gardens like Slack have the technical capability to produce text logs, but as we will discuss in the next section, do not typically do so.

In the next section we begin to describe the increasing use of walled gardens by 18 popular FLOSS projects, including whether or not the communications are archived, and what the community's rationale is for using the walled garden.

Data on Walled Garden Usage in FLOSS Projects

The tables below show examples of FLOSS projects that have announced that they are using walled gardens as a primary communication channel. These tables focus on Slack as a walled garden since prior work already addressed the use of Stack Overflow for developer support [START_REF] Squire | Should we move to Stack Overflow? Measuring the utility of social media for developer support[END_REF], and because -as Section 4 will show -Stack Overflow's "garden walls" are substantially lower and more porous than the walls surrounding Slack.

In the tables, URLs containing references to the evidence are provided in the Appendix as [A1], [A2], and so on. Table 1 contains information for a general collection of FLOSS projects that rely on walled gardens for communication, and Table 2 contains information for only Apache Software Foundation (ASF) projects. We moved ASF projects into their own table so that they could be compared to each other, since they are all subject to the same rules about decision-making on mailing lists [START_REF]Apache Software Foundation (nd) Decision Making[END_REF][START_REF]Mailing Lists[END_REF].

The last column in each table shows whether the community is providing archives of the communication that happens in the walled garden. To determine whether archives were available, we performed the following procedure. First we searched for archives via the public web site for the project, and if those were not available, we searched for archives via Google, using the following queries:

• io With a few exceptions, most of the projects that did have an archive put the link to it in an obvious place, so the archives were easy to find. These tables show that the majority of projects which are using walled gardens are not creating archives of these communications. In the next section we discuss some options for communities that do want to create archives.

Archiving Walled Gardens

If a community does decide to move to walled garden for communication, there are some strategies it can take to combat the potential for a corresponding loss of transparency. Creating archives of the communications -as would have been available with a mailing list or IRC channels -is one obvious and familiar solution. We will first discuss the options for creating archives of Slack, and then we will briefly address Stack Exchange / Stack Overflow archiving.

Archiving Slack

There are a few different options for archiving Slack conversations, each of which have different positive and negative aspects. First, as we noted in Table 1 [START_REF] Slack | So Yeah We Tried Slack… and We Deeply Regretted It[END_REF] or via a third party tool (e.g. Sameroom, available at http://sameroom.io), and once the chat is on IRC, the archives can be created there using an IRC archive bot. Depending on the client, IRC may or may not be able to understand advanced features of Slack, including direct messages, code formatting features, and document attachments. Users who choose to use IRC will not see these aspects of the Slack experience, nor will an IRC bot be able to archive them.

Third, community managers can take the approach of Wordpress and simply point people to the in-Slack archive, for example [A2]. The downsides of that approach are:

• Viewers of the archive must be signed in members of the channel.

• The archives are only browsable on a day-to-day basis (a "pick a date" widget is also available). • By default, the archives are not searchable or downloadable by a nonadministrative user. • Some communities with a lot of messages in the archive have reported seeing errors reading, "Your team has more than 10,000 messages in its archive, so although there are older messages than are shown below, you can't see them. Find out more about upgrading your team." [20]

Archiving Stack Exchange

The options for creating local archives of Stack Overflow and Stack Exchange sites are determined by a Creative Commons BY-SA 3.0 license [START_REF]Attribution-ShareAlike 3.0 Unported[END_REF] that allows reuse of Stack Exchange network data (for example questions, answers, and the like) as long as attribution rules are followed [START_REF]Stack Exchange Terms of Service[END_REF]. The site also periodically provides a CClicensed Data Dump [START_REF]Stack Exchange Data Dump[END_REF] with private identifying user data removed. Despite these generous terms, it does not appear that many FLOSS projects relying on Stack Overflow for developer or user support are creating their own archives of this data, nor are they providing context to Stack Overflow questions or answers from within their own ecosystems. Rather, the communities that are using Slack as a question-and-answer facility are simply pointing users to the relevant Stack Overflow tag or corresponding Stack Exchange subdomain.

Conclusion

This paper presents data on how 18 FLOSS projects (including 10 Apache Software Foundation (ASF) projects) use walled gardens to communicate with and between users and developers. We define walled gardens in terms of their ownership or control by a single corporation, as well as by their lack of FLOSS licensing to users. Examples of walled gardens include synchronous communication services like Slack, and asynchronous communication sites like Stack Overflow. We posit that when walled gardens are chosen for communication, the community has decided to subjugate the FLOSS value of openness via transparent, non-corporate, FLOSS-licensed communication for a different -and equally compelling -definition of openness, namely an openness of easy participation and diverse contribution. One way that these competing values can both "win" is for the project to provide avenues for increased transparency after the walled garden is chosen, specifically by providing easy-to-find, publicly available, downloadable archives of the communication that happens inside the walled garden. This step would effectively open a "gate" into the walled garden and reassert the value of transparency once again.

Unfortunately, our data shows that only a handful of projects have made any attempt toward transparency by opening such a gate. This resistance to creating transparent archives of communication also persists in communities such as ASF that explicitly encourage archives and transparency in project communication.

By questioning the use of walled gardens for communication and evaluating their effects on multiple types of "openness", we hope to begin a dialogue within the FLOSS community about how to preserve and extend its unique values.

Table 1 .

 1 FLOSS projects using walled gardens for all or part of their communication

	Community	Use of Walled Garden	Status of Archives
	Wordpress	Moved from IRC to Slack. "Slack commu-	No consistent Slack
	(all)	nication is used for contributing to the	archive. Occasional
		WordPress project, be it code, design, doc-	links to archives are
		umentation, etc." [A1]	posted (e.g. [A2]),
			but Slack login is
			required. The ar-
			chives are not down-
			loadable or searcha-
			ble. IRC logs used
			to be available, but
			now only one chan-
			nel is logged. [A3]

Table 2 .

 2 Apache Software Foundation projects using walled gardens for all or part of their communication

	Community	Use of Walled Garden	Status of Archives
	Apache Cor-	Users can "Join the discussion on Slack"	No Slack archive.
	dova	[A22], which "is a replacement for IRC, but
		not a replacement for decisions and voting,
		that still needs to be on the list"[A23]
	Apache	"The Slack channel is not endorsed by the	No Slack archive.
	Groovy	Apache Software Foundation, It's run by
		Groovy enthusiasts in the community for
		casual conversations and Q&A. Official
		discussions must happen on the mailing lists
		only" [A24]

  and Table2, there are third-party services, such as Slackarchive.io (http://slackarchive .io), which can create and host Slack archives. Slackarchive.io lists many open source projects on its "who is using" list, including Bitcoin-core, Midonet, Apache Mesos, and Apache Thrift. The archives are searchable and browsable by date, but the archives are not easily downloadable. There are no Terms of Service posted on the Slackarchive.io site, nor is there a robots.txt file. The archives themselves are displayed in a JavaScript-driven responsive web interface, making downloads inconvenient and non-trivial to automate.Another option for creating archives for Slack is to connect it to IRC via the Slack bridge

A5. https://www.drupal.org/node/2490332 A6. https://www.drupal.org/node/2798167 A7. https://4th-october/ A9

Appendix

Below are the URLs referenced in


Simone Da

Silva Amorim
email: simone.amorim@ifba.edu.br

John D Mcgregor
email: johnmc@cs.clemson.edu

Eduardo Santana De Almeida

Christina Von Flach

G Chavez

Understanding the E↵ects of Practices on KDE Ecosystem Health

Keywords: Open source software ecosystems, ethnographic studies, software practices, software ecosystem health

Open source software ecosystems have adjusted and evolved a set of practices over the years to support the delivery of sustainable software. However, few studies have investigated the impacts of such practices on the health of these ecosystems. In this paper, we present the results of an ethnographic-based study conducted during the Latin-American KDE users and contributors meeting (LaKademy 2015) with the goal of collecting practices used within the KDE ecosystem and understanding how they a↵ect ecosystem health. The analysis was based on softgoal interdependency graphs adapted to represent practices and relate them to non-functional requirements and goals. Our results provide a preliminary insight to understand how KDE ecosystem community interacts, which working practices have been adopted and how they a↵ect ecosystem health.

Introduction

The software ecosystem (SECO) strategy has been used with great success for several years [START_REF]Android's Success: by the Numbers[END_REF][START_REF]Global Hadoop Market -industry analysis, size, share, growth, trends and forecast[END_REF]. This strategy has facilitated the emergence of communities surrounding hardware and software computing platforms, such as the Apple iOS community, and certain configurable products, such as the Eclipse Rich Client Platform. Each organization joining a SECO is looking to fill a role in the community that will foster its business objectives. The community members leverage the work of other members to grow bigger products faster than they could have on their own. Within a SECO, one or more platform providers work to attract product developers to use the provider's platform as the foundation for products. The platform organization shares some degree of control over their platform, provides tools that make product development easier on their platform, and provides access to information about the current structure and future changes to the platform. The dominant organization in the ecosystem, usually the platform owner, heavily influences the culture of the ecosystem.

The health of a SECO stands for the growing and continuity of the software ecosystem remaining variable and productive over time [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF]. The assessment of SECO health can be performed with respect to di↵erent aspects, including robustness, productivity, and niche creation [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF]. Some studies present quantitative assessment on SECO health [START_REF] Jansen | Measuring the health of open source software ecosystems: Beyond the scope of project health[END_REF].

Practices can be useful to understand a SECO and assess its health. For instance, the practice "review all code before accepting into the release" may impact several quality indicators and contribute to increasing productivity while avoiding rework. However, to our knowledge, there is no qualitative study that focuses on software practices and their relation to SECO health.

In this paper, we present the results of an ethnographic-based study conducted with the purpose of investigating the practices used by a SECO from three perspectives [START_REF] Campbell | A three-dimensional view of software ecosystems[END_REF] -business, social, and technical -and their impact on SECO health. The selected research method, ethnography, has been used to study software practices in di↵erent contexts [START_REF] Passos | Challenges of applying ethnography to study software practices[END_REF][START_REF] Sharp | An ethnographic study of xp practice[END_REF]. The object of our study was KDE 4 , an open source SECO that gathers a set of platforms and products for Linux distributions. During the Latin-American KDE users and contributors meeting (LaKademy 2015), we collected day-to-day practices and analyzed them to understand their impact on SECO health. Softgoal interdependency graphs (SIG) [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF] extended with practices, support the analysis of KDE practices and their influence on health aspects of SECO such as productivity and robustness.

The remainder of the paper is organized as follows: Section 2 presents background on SECO. Section 3 introduces SIG-P, our customized SIG [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF]. Section 4 presents the context and design of our study. Section 5 presents the collected KDE practices and a preliminary analysis of their relation to KDE health. Section 6 presents findings, contributions and limitations of our work. Section 7 presents related work. Finally, Section 8 provides a brief description of future work and some concluding remarks.

Background

The concept of software ecosystem health was introduced by Iansiti and Levien as the growing and continuity of the SECO remaining variable and productive over time [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF]. They argued that the performance of an organization also depends on its interactions with the whole ecosystem -not only on the relationship with competitors and stakeholders and on the organizational potential. Iansiti and Levien drew an analogy with biological ecosystems, and argued that SECO health should be assessed based on three aspects: robustness, productivity, and niche creation [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF].

Robustness refers to the ability of the ecosystem to survive radical changes and problems resulting from these changes. The ecosystems should face and over-come all inevitable di culties inherent in the evolutionary process. Productivity is related to the way in which the work is accomplished with the least waste of time and e↵ort. The ecosystem should add value through innovation, management of resources and cost control. Lastly, niche creation represents SECO features that encourage and support diversity among the di↵erent species in the ecosystem. The ecosystem should provide the structure for creating new features over time, increasing the diversity among SECO members' products [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF].

Campbell [START_REF] Campbell | A three-dimensional view of software ecosystems[END_REF] introduces three views to classify the features of a SECO: technical, business and social. The Technical View presents the architecture and approaches to implementing software. The Business View captures business strategies at play in the ecosystem. In some cases, organizations will be in direct competition and making decisions on release dates and licensing in response to the actions of others within the ecosystem. The Social View captures relationships among humans: developers, users, managers and other participants.

SECO health should not be evaluated only by considering metrics. Practices also aid in understanding a project and its evolution with greater fidelity. They provide clear goals and forms to assess a good working performance to achieve a successful end [START_REF] Jacobson | Enough of processes -lets do practices[END_REF]. For example, the practice "Provide continuous integration tools to check code every day and report errors" will impact several quality indicators as well as contribute to increasing productivity while avoiding rework.

The NFR Framework with Practices

The NFR framework [START_REF] Chung | Representing and using nonfunctional requirements: A process-oriented approach[END_REF][START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF] provides a systematic approach for defining and representing non-functional requirements (NFR) for software products. A set of goals represent NFR, design decisions and claims to support or not other goals. Goals are decomposed into subgoals and related with AND/OR relationships [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF].

The term softgoal introduces the concept of satisficing [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF]. Softgoals may contribute to some degree (positively (+, ++) or negatively (-, --), fully or partially), in satisfying other softgoals. A Softgoal Interdependency Graph (SIG) models NFR and their interdependencies to achieve a softgoal (or desired quality). Design decisions are represented by operationalization softgoals. SIG diagrams provide a visual representation for SIG [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF].

SIG with Practices (SIG-P)

SIG with Practices (SIG-P), our customized SIG, models SECO practices and their influence on SECO non-functional requirements. In SIG-P, each practice is modeled as a satisficing technique [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF] and the degree of its influence on SECO health is documented.

Aspects of SECO health such as robustness, productivity, and niche creation [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF] are modeled as softgoals. Each softgoal can be decomposed and refined into mandatory and optional subgoals/NFR that influence directly the achievement of such aspects of SECO health. Practices are connected by interdependency links to NFR to indicate that they contribute to reach softgoals. Social, business and technical views [START_REF] Campbell | A three-dimensional view of software ecosystems[END_REF] are presented in SIG-P diagrams. SIG-P diagrams can be used to enhance general understanding about a SECO and its health. They provide a graphical representation for practices, their interdependencies and impacts on NFR and SECO aspects. Moreover, evaluators can build SIG-P models to reason and provide qualitative assessment on SECO health and use SIG-P diagrams to support discussions about correlations and trade o↵s among softgoals. Figure 1 presents an example of a SIG-P diagram. Details about this example are presented and discussed in Section 6.

SIG-P Construction

The construction of a SIG-P graph for an specific SECO view [START_REF] Campbell | A three-dimensional view of software ecosystems[END_REF] starts with one or more ecosystem health aspects [START_REF] Iansiti | Keystones and dominators: Framing operating and technology strategy in a business ecosystem[END_REF] and a set of practices used by some target SECO. A catalogue of documented NFR, such as the one provided in [START_REF] Chung | Non-Functional Requirements in Software Engineering[END_REF] is strongly recommended.

We defined three steps to guide the bottom-up construction of a SIG-P for each SECO view. Given a set of practices of a target SECO, a catalogue of NFR and SECO softgoals: (1) For each practice, identify a subset of NFR and consider its influence on each NFR; [START_REF]Global Hadoop Market -industry analysis, size, share, growth, trends and forecast[END_REF] For each identified NFR, analyze its influence on softgoals, considering ambiguities, trade o↵s and priorities; and (3) For each identified NFR, evaluate the impact (positive or negative) of NFR on softgoals.

These steps can be refined with many iterations considering the reasoning about NFR and their di↵erent alternatives. The SIG-P diagram from Figure 1 illustrates a SIG-P for a business view.

Methodology

The KDE ecosystem 5 is an international community that provides a Free Open Source desktop environment for many Linux distributions. The KDE ecosystem has several initiatives to promote their projects around world. In Brazil, a branch of the global organization gathers a team of KDE supporters. The Brazilian group promotes LaKademy (Latin American Akademy), an annual event at which KDE users and contributors meet in person to exchange ideas about projects and discuss the future of KDE. At this event, attendees participate in a set of activities such as lectures, hackathon sessions, and meetings on specific topics.

Hackathons are events that produce working software in a limited period of time. They consist of strenuous and uninterrupted intervals of coding, and are very useful as social and educational events [14]. Komssi et al. stated that hackathons' participants can also learn new practices, technologies, and attitudes, which can be used in everyday work [14]. During KDE events, hackathons provide informal ways to meet new people and learn new technologies.

Research Method

In this study, research techniques commonly used in ethnographic studies were adopted to support the researcher in understanding the practices and communication strategies KDE uses to work collaboratively. Most of the work in the context of open source SECOs, including KDE, is performed by distributed teams and contributors. Therefore, LaKademy provided an appropriate setting for conducting an ethnographically-inspired [START_REF] Robinson | Ethnographically-informed empirical studies of software practice[END_REF][START_REF] Sharp | The role of ethnographic studies in empirical software engineering[END_REF], short term study about KDE. The researcher could observe and participate in LaKademy through in-person meetings and activities.

To address practical challenges faced when conducting ethnographic studies [START_REF] Passos | Challenges of applying ethnography to study software practices[END_REF], we joined the KDE community to gain better access to the setting of the practices and the use of a common vocabulary. We also conducted our investigation without unnecessary formality, explaining our research, who we were and what we were doing, and trying not to interfere with the activities of LaKademy. Verbal consent was captured on audio recordings at the beginning of sessions. Furthermore, we were rigorous in data collection and analysis to avoid bias.

The first days of Lakademy hackathons are used to disseminate KDE practices and knowledge about the ecosystem. Then developers follow a plan to work hard and deliver planned features. Therefore even knowing that developers are not working in their natural setting, we assume that many practices can be transfered to everyday work of participants.

Data Collection and Analysis Procedures

On-site immersion and data collection took place at LaKademy 20156 event held in Salvador, from 3 rd to 6 th June, 2015. The event had 15 participants including students, professionals and KDE collaborators. During 4 days, we conducted semi-structured interviews, listened to lectures, analyzed KDE documents, and observed interactions of community members, mainly during hackathon sessions. Observations were documented in the form of field notes and audio records. Interviews. Interviews were semi-structured, with 24 open-ended questions intended to understand the daily practices used in KDE ecosystem. Interviews were audio-recorded and later transcribed. We had interview sessions with 4 KDE members that have contributed actively to KDE for 6 years or more -three of them were members of KDE e.V. [START_REF]20 Years of KDE: Past, Present and Future[END_REF], a group that represents the KDE Community with respect to legal and financial issues. One of the interviewed KDE members is part of the KDE Board responsible for business management. We assumed that these people were heavily engaged and up to date regarding most of KDE decisions and practices. They also provided relevant information about the KDE community, contribution areas, financial issues and future plans. The questionnaire can be found at http://homes.dcc.ufba.br/⇠ssamorim/lakademy/.

Hackathons. During LaKademy 2015, the researcher joined two hackathon sessions for removing bugs from two KDE applications: Cantor, a mathematical application, and the Plasma Network Manager. These sessions provided a good opportunity to observe developers with di↵erent levels of experience performing tasks with their own style and ask questions about reasons behind their actions. Some practices, not identified during interviews, were collected during hackathon sessions.

Document Analysis. The researcher also gathered references to online KDE documents. The community maintains a rich website that describes various aspects of KDE ecosystem. We had access to international and Brazilian websites and their documents. Thus, we could explore in detail the dynamics of interactions of the entire KDE ecosystem.

Results and Analysis

Practices in KDE

We collected 68 practices used in KDE SECO. Although a practice could be associated to more than one SECO view (social, business, or technical), we linked T2 Review all code before accepting into the release.

T15 Provide a manifest which project must follow to be considered part of the ecosystem.

T10 Provide a freeze period to stabilize the translation of a version before the launch of that version.

T16 Require that all infrastructure must be under the control of the ecosystem and be based on technologies created by the ecosystem.

T13 Provide continuous integration tools to check code every day and report errors.

T25 Keep backward compatibility for a long time (around 6 years).

T23 Develop code to be extensible. The use of plug-ins and compilation is separated between the core and applications.

T19 Use scripts to do an initial code review and catch errors.

it to a single view for which the practice seemed to be most influential. The collection of 68 practices was validated by two interviewees. Five practices (B14, T3, T21, T27, and T35) were not validated. We also asked the two interviewees to choose five important practices for each view.

Table 1 presents 10 Social Practices, related to working together in the community, selected by two interviewees. Accordingly, Table 2 presents 10 Business Practices, related to aspects of management, strategic planning, and innovation, and organized activities such as marketing, making decisions, and so on. Finally, Table 3 presents 10 Technical Practices (out of 40 practices), related to product development (core and applications), technologies used, code rules, and others. Other practices are available at http://homes.dcc.ufba.br/⇠ssamorim/lakademy/.

Analysis

We resorted to SIG-P diagrams to understand and analyze the e↵ects of identified practices on KDE health. SIG-P diagrams were built, one for each SECO view, by following steps described previously (Section 3).

SIG-P diagram for KDE business view (Figure 1, introduced in Section 3) supports the analysis of KDE business practices. For instance, practice B5 (Provide a nonprofit corporation to manage legal and financial issues) may influence Sustainability that, in turn, provides a positive influence on Niche Creation.

Discussion

Findings

This study allowed us to uncover implicit features of SECO practices and reveal the context in which they were immersed: (a) Many practices are not documented or standardized; (b) There is a great amount of tacit knowledge sharing during hackathon sessions -this highlights the importance of meeting people face-to-face to strengthen the community; and (c) Practices do have influence on KDE ecosystem health, which can be exploited later to support decisiontaking processes.

Contributions

SECO participants can use the knowledge base of practices and related e↵ects in situations such as: (a) SECO adoption, whenever an organization wants to adopt some ecosystem platform, the NFR with practices can be used to evaluate risks; (b) Getting involved, whenever an individual or team wants to contribute with an open source ecosystem, documented practices and their e↵ects on SECO health can improve the learning curve; and (c) Partnership establishment, in scenarios of feasibility analysis, the NFR with practices can provide useful information to judge the feasibility of partnerships.

Researchers can use our results as input to new evaluation models and quality models for SECOs, and inspiration for performing additional qualitative studies on SECO health. So far additional studies and data are necessary to analyze which practices are more influential or the degree of their influence on SECO health. A deeper understanding on SECO practices will help us to further investigate factors that may contribute to balancing the trade-o↵s necessary for SECO health.

Limitations

The contributions of this study should be balanced against some limitations relating to the timing of the study, observer bias, and observed subject bias. Classical ethnographic studies are performed over a long period of time [START_REF] Hammersley | Ethnography: Principles in Practice[END_REF]. However, LaKademy provides a rare opportunity to meet people face-to-face in an ecosystem that carries out many online activities.

Additionally, there are limitations regarding practices not captured, variability of SIG-P configurations, and validation of the results. SIG-P models are supposed to support understanding and analysis of SECO practices with respect to their influence on NFR and di↵erent health aspects (robustness, productivity, and niche creation) of KDE. In this paper, we only show one combination for SIG-P, but many other combinations are possible including negative impacts. Moreover, we worked to avoid bias taking a rigorous approach to data collection and analysis. Nevertheless, we should perform more combination of practices and NFR and validate the results to produce a more comprehensive analysis.

Related Work

To our knowledge, there is no qualitative study in the context of SECO health that focuses on software practices. In this section, we outline related work that addresses ethnography and practices.

Sharp et al. [START_REF] Sharp | An ethnographic study of xp practice[END_REF] presented an ethnographic study to identify XP practices, conducted in a small company that developed web-based intelligent advertisements. Their findings included 5 characterizing themes within XP practice. The identified practices indicated that, in the XP culture, individuals and teams are respected, take responsibilities, and act to maintain the quality of working life. This work helped us in the identification of XP practices used by KDE.

Evangelista [START_REF] Evangelista | Traidores do Movimento: política, cultura, ideologia e trabalho no Software Livre[END_REF] in his PhD thesis investigated the Free Software Movement (FSM), with the overall goal of studying the relation between free software and topics such as culture, power, labor and ideology. To understand the FSM in the Brazilian context, he conducted an ethnographic study during the 9 th International Free Software Forum (FISL) 8 . His study reported several practices used in open source ecosystems. Furthermore, it inspired us to apply ethnography in our work, and provided guidance on observing and understanding practices used by KDE.

Conclusions and Future Work

SECOs have achieved success and attracted the attention of researchers. However, little is known about SECO practices and reasons for their success. In this paper, we presented an ethnographic-based study conducted during LaKademy 2015 to collect practices of the KDE ecosystem and understand how they a↵ect ecosystem health. These practices were linked to non-functional requirements to provide a preliminary support to SECO health assessment.

This work provides a set of practices and a SIG-P catalogue of the analyses of the impact of practices on SECO health. These results are important steps for our ongoing research proposal of an assessment method for SECO health based on practices [START_REF] Amorim | Towards an evaluation method for software ecosystem practices[END_REF]. Our results can also support researchers in understanding operational aspects of open source SECOs.

Fig. 1 .

 1 Fig. 1. SIG-P for Business View

Fig. 2 .

 2 Fig. 2. SIG-P for Social View

Figure 2

 2 Figure 2 presents a SIG-P diagram for KDE social view that is used to reason about KDE social practices. For instance, Practices S7 (Conduct a general annual face to face meeting to discuss community issues) and S8 (Perform elections to assign responsibility levels for new members) a↵ect Controllability 7 that, in turn, provides a positive influence on Robustness and Productivity Figure 3 presents a SIG-P diagram for KDE technical view. For instance, Practice T16 (Require that all infrastructure must be under the control of the ecosystem and be based on the technologies created by the ecosystem) may influence Reliability that, in turn, provides a positive influence on Robustness and Productivity. At http://homes.dcc.ufba.br/⇠ssamorim/lakademy/ other SIG-P diagrams are available.

Fig. 3 .

 3 Fig. 3. SIG-P for Technical View

Table 1 .

 1 Social Practices

	Id Most Important Social Practices	Id Other Social Practices
	S7 Conduct a general annual face to face meeting	S12 Promote happy hours and dinners to facili-
	to discuss community issues.	tate social integration during events.
	S1 Create confidence in a member based on his	S2 Require that at least two persons nominate
	work history. Based on this, provide di↵erent	a member to be promoted up the levels of
	levels of responsibilities.	responsibilities.
	S4 Promote networking in the work market.	S3 Conduct annual meetings among translators
		by projects.
	S8 Perform elections to assign responsibility lev-	S5 Promote social relationships with members in
	els for new members.	other countries.
	S11 Use tools to support communication in the	S6 Create opportunities to practice another hu-
	group such as: mailing lists, forums, IRCs,	man language such as English.
	wikis, and blogs.

Table 2 .

 2 Business Practices

	Id Most Important Business Practices	Id Other Business Practices
	B5 Provide a nonprofit corporation to manage le-	B6 Divide activities into working groups respon-
	gal and financial issues.	sible for areas such as marketing, infrastruc-
		ture, design, community to keep the group
		healthy.
	B8 Attract companies that will invest money to	B1 Provide flexibility in translation schedule and
	support the ecosystem.	negotiate deadlines.
	B11 Define a schedule of releases that will a↵ect	B2 Reach an agreement in the community on
	the work of the entire community.	how to answer questions that are not ad-
		dressed in tutorials or guidelines.
	B16 Assign a lead maintainer for each project for	B4 Provide lectures to teach how to translate and
	making technical decisions.	how to become a contributor.
	B3 Make decisions based on discussions in the	B7 Make technical decisions independently
	mailing list.	within each project.

Table 3 .

 3 Technical Practices

	Id Most Important Technical Practices	Id Other Technical Practices

T1 Each person chooses the work they desire to perform among available tasks in the ecosystem, e.g., file to translate, code to develop, applications to test, and so on.

T11 Provide tools for code optimization, static analysis of code, code review, and test automation.

https://www.kde.org/

http://www.kde.org/

https://br.kde.org/lakademy-2015

Controllability can be defined as a quality of ecosystems interested in keeping stable and pursuing sustainable development[START_REF] Mens | Ecos: ecological studies of open source software ecosystems[END_REF].

Acknowledgments. We are thankful to Lakademy 2015 organizers and participants. John McGregor is partially funded by the NSF grant #ACI-1343033.


Amirhosein " Emerson

" Azarbakht
email: azarbaka@oregonstate.edu

Carlos Jensen
email: carlos.jensen@oregonstate.edu

Longitudinal Analysis of the Run-up to a Decision to Break-Up (Fork) in a Community

In this paper, we use a developer-oriented statistical approach to understand what causes people in complex software development networks to decide to fork (break away), and what changes a community goes through in the run-up to a decision to break-up. Developing complex software systems is complex. Software developers interact. They may have the same or different goals, communication styles, or values. Interactions can be healthy or troubled. Troubled interactions cause troubled communities, that face failure. Some of these failures manifest themselves as a community split (known as forking). These failures affects many people; developers and users. Can we save troubled projects? We statistically model the longitudinal socio-grams of software developers and present early indicators and warning signs that can be used to predict an imminent break-up decision.

Introduction

Social networks are a ubiquitous part of our social lives, and the creation of online social communities has been a natural extension of this phenomena. Social media plays an important role in software engineering, as software developers use them to communicate, learn, collaborate and coordinate with others [START_REF] Storey | The (R) Evolution of social media in software engineering[END_REF]. Free and Open Source Software (FOSS) development efforts are prime examples of how community can be leveraged in software development, where groups are formed around shared interest, and depend on continued interest and involvement to stay alive [START_REF] Nyman | Understanding code forking in open source software[END_REF].

Community splits in free and open source software development are referred to as forks, and are relatively common [START_REF] Robles | A comprehensive study of software forks: Dates, reasons and outcomes[END_REF]. Robles et al. [START_REF] Robles | A comprehensive study of software forks: Dates, reasons and outcomes[END_REF] define forking as "when a part of a development community (or a third party not related to the project) starts a completely independent line of development based on the source code basis of the project."

Although the bulk of collaboration and communication in FOSS communities occurs online and is publicly accessible for researchers, there are still many open questions about the social dynamics in FOSS communities. Projects may go through a metamorphosis when faced with an influx of new developers or the involvement of an outside organization. Conflicts between developers' divergent visions about the future of the project may lead to forking of the project and dilution of the community. Forking, either as an acrimonious split when there is a conflict, or as a friendly divide when new features are experimentally added, affect the community [START_REF] Bezrukova | Violent Splits Or Healthy Divides? Coping With Injustice Through Faultlines[END_REF].

Previous research on forking ranges from the study by Robles et al. [START_REF] Robles | A comprehensive study of software forks: Dates, reasons and outcomes[END_REF] that identified 220 significant FOSS projects that have forked over the past three decades, and compiled a comprehensive list of the dates and reasons for forking to the study by Baishakhi et al. [START_REF] Baishakhi | REPERTOIRE: a cross-system porting analysis tool for forked software projects[END_REF] on post-forking porting of new features or bug fixes from peer projects. It encompasses works of Nyman on developers' opinions about forking [START_REF] Nyman | Hackers on Forking[END_REF], developers motivations for performing forks [START_REF] Mikkonen | To Fork or Not to Fork: Fork Motivations in Source-Forge Projects[END_REF], the necessity of code forking as tool for sustainability [START_REF] Nyman | Forking: the invisible hand of sustainability in open source software[END_REF], and Syeed's work on sociotechnical dependencies in the BSD projects family [START_REF] Syeed | Socio-Technical Dependencies in Forked OSS Projects: Evidence from the BSD Family[END_REF].

Most existing research on forking, however, is post-hoc. It looks at the forking events in retrospect and tries to find the outcome of the fork; what happened after the fork happened. The run-up to the forking events are seldom studied. This leaves several questions unanswered: Was it a long-term trend? Was the community polarized, before forking happened? Was there a shift of influence? Did the center of gravity of the community change? What was the tipping point? Was it predictable? Is it ever predictable? We are missing that context.

Additionally, studies of FOSS communities tend to suffer from an important limitation. They treat community as a static structure rather than a dynamic process. Longitudinal studies on open source forking are rare. To better understand and measure the evolution, social dynamics of forked FOSS projects, and integral components to understanding their evolution and direction, we need new and better tools. Before making such new tools, we need to gain a better understanding of the context. With this knowledge and these tools, we could help projects reflect on their actions, and help community leaders make informed decisions about possible changes or interventions. It will also help potential sponsors make informed decisions when investing in a project, and throughout their involvement to ensure a sustainable engagement.

We use an actor-oriented longitudinal statistical model [START_REF] Snijders | Introduction to stochastic actor-based models for network dynamics[END_REF] to study the evolution and social dynamics of FOSS communities, and to investigate the driving forces in formation and dissolution of communities. This paper is a part of a larger study aiming to identify better measures for influence, shifts of influence, measures associated with unhealthy group dynamics, for example a simmering conflict, in addition to early indicators of major events in the lifespan of a community. One set of dynamics we are especially interested in, are those that lead FOSS projects to fork.

Related Work

The free and open source software development communities have been studied extensively. Researchers have studied the social structure and dynamics of team communications [START_REF] Bird | Latent social structure in open source projects[END_REF][16] [START_REF] Howison | Social dynamics of free and open source team communications[END_REF][18] [START_REF] Nakakoji | Evolution patterns of open-source software systems and communities[END_REF], identifying knowledge brokers and associated activities [START_REF] Sowe | Identifying knowledge brokers that yield software engineering knowledge in OSS projects[END_REF], project sustainability [23][26], forking [START_REF] Nyman | Understanding code forking in open source software[END_REF][3][4] [START_REF] Azarbakht | Temporal Visualization of Collaborative Software Development in FOSS Forks[END_REF], requirement satisfaction [START_REF] Ernst | Code forking in open-source software: a requirements perspective[END_REF], their topology [START_REF] Bird | Latent social structure in open source projects[END_REF], their demographic diversity [START_REF] Kunegis | Diversity dynamics in online networks[END_REF], gender differences in the process of joining them [START_REF] Kuechler | Gender Differences in Early Free and Open Source Software Joining Process[END_REF], and the role of age and the core team in their communities [START_REF] Azarbakht | Drawing the Big Picture: Temporal Visualization of Dynamic Collaboration Graphs of OSS Software Forks[END_REF][2] [START_REF] Azarbakht | Longitudinal Analysis of Collaboration Graphs of Forked Open Source Software Development Projects Using An Actor-oriented Social Network Analysis[END_REF][12] [START_REF] Torres | Analysis of the Core Team Role in Open Source Communities[END_REF]. Most of these studies have tended to look at community as a static structure rather than a dynamic process [START_REF] Crowston | Free/Libre open-source software development: What we know and what we do not know[END_REF]. This makes it hard to determine cause and effect, or the exact impact of social changes.

Post-forking porting of new features or bug fixes from peer projects happens among forked projects [START_REF] Baishakhi | REPERTOIRE: a cross-system porting analysis tool for forked software projects[END_REF]. A case study of the BSD family (i.e., FreeBSD, OpenBSD, and NetBSD, which evolved from the same code base) found that 10-15% of lines in BSD release patches consist of ported edits, and on average 26-58% of active developers take part in porting per release. Additionally, They found that over 50% of ported changes propagate to other projects within three releases [START_REF] Baishakhi | REPERTOIRE: a cross-system porting analysis tool for forked software projects[END_REF]. This shows the amount of redundant work developers need to do to synchronize and keep up with development in parallel projects.

Visual exploration of the collaboration networks in FOSS communities was the focus of a study that aimed to observe how key events in the mobile-device industry affected the WebKit collaboration network over its lifetime. [START_REF] Teixeira | Collaboration in the open-source arena: the webkit case[END_REF] They found that coopetition (both competition and collaboration) exists in the open source community; moreover, they observed that the "firms that played a more central role in the WebKit project such as Google, Apple and Samsung were by 2013 the leaders of the mobile-devices industry. Whereas more peripheral firms such as RIM and Nokia lost market-share" [START_REF] Teixeira | Collaboration in the open-source arena: the webkit case[END_REF].

The study of communities has grown in popularity in part thanks to advances in social network analysis. From the earliest works by Zachary [36] to the more recent works of Leskovec et al. [START_REF] Leskovec | Graphs over time: densification laws, shrinking diameters and possible explanations[END_REF] [START_REF] Leskovec | Statistical properties of community structure in large social and information networks[END_REF], there is a growing body of quantitative research on online communities. The earliest works on communities was done with a focus on information diffusion in a community [36]. The study by Zachary investigated the fission of a community; the process of communities splitting into two or more parts. They found that fission could be predicted by applying the Ford-Fulkerson min-cut algorithm [START_REF] Ford | A simple algorithm for finding maximal network flows and an application to the Hitchcock problem[END_REF] on the group's communication graph; "the unequal flow of sentiments across the ties" and discriminatory sharing of information lead to subcommunities with more internal stability than the community as a whole. [36] 3 Research Goals Social interactions reflect the changes the community goes through, and so, it can be used to describe the context surrounding a forking event. Social interactions in FOSS can happen, for example, in the form of mailing list email correspondence, bug report issue follow-ups, and source code contributions and co-authoring. We consider some forking decisions [START_REF] Robles | A comprehensive study of software forks: Dates, reasons and outcomes[END_REF] to be socially related, such that, they should have left traces in the developers' interactions data. Such traces may be identified using longitudinal modeling of the interactions, without digging into the contents of the communications. These three reasons are (1) Personal differences among developer team, (2) The need for more communitydriven development, and (3) Technical differences for addition of functionality. In this study, we analyzed, quantified and visualized how a community is structured, how it evolves, and the degree to which community involvement changes over time. Our over-arching research objective was to identify these traces/social patterns associated with different types of undesirable forking R.G. 1: Do forks leave traces in the collaboration artifacts of open source projects in the period leading up to the fork? To study the properties of possible social patterns, we need to verify their existence. More specifically, we need to check whether the possible social patterns are manifested in the collaboration artifacts of open source projects, e.g., mailing list data, issue tracking systems data, source code data. This is accomplished by statistical modeling of developer interactions as explained in more detail in section 4.

R.G. 2: What are the traces that can explain longitudinal changes in sociograms in run-up to a forking event? What quantitative measure(s) can be used as an early warning sign of an inflection point (fork)? Are there metrics that can be used to monitor the odds of change, (e.g. forking-related patterns) ahead of time? This will be accomplished by statistical modeling of developer interactions as explained in more detail in section 4.

Methodology

Detecting change patterns, requires gathering relevant data, cleaning it, and analyzing it. In the following subsections, we describe the proposed process in detail. Figure 1 shows the overview of our methodology.

Data Collection

The data collected were developer mailing lists, where developers' interact by sending and receiving emails, and source-code repository contribution logs, where developers interact by modifying the code. The sociograms were formed based on interactions among developers in these settings. For the purpose of our larger study, not included in this paper, we gathered data for 13 projects, in three categories of forking, plus a control group. We have included the data for a project that forked in 2010. The name is left out for anonymity, to prevent defaming a project, and to prevent individuals from becoming target of blame, in case our findings may be misused. Mailing list data was cleaned such that the sender and receiver email ID case-sensitivity differences would be taken into account, to prevent duplicity. The Source Code repository version control logs were used to capture the source code activity levels of the developers who had contributed more than a few commits. The set of the developers who had both mailing list activity and source code repository activity formed the basis of the socio-grams we used in our analysis. The time period for which data was collected is one year leading to when the decision to break-up (fork) happened. This should capture the social context of the run-up to the forking event.

Results

Reresented

Social connections and non-connections can be represented as graphs, in which the nodes represent actors (developers) and the edges represent the interaction(s) between actors or lack thereof. Such graphs can be a snapshot of a network -a static sociogram -or a changing network, also called a dynamic sociogram. In this phase, we process interactions data to form a communication sociogram of the community. Two types of analysis can be done on sociograms: Either a cross-sectional study, in which only one snapshot of the network is looked at and analyzed; or a longitudinal study, in which several consecutive snapshots of the network are looked at and studied. We are interested in patterns in the run-up to forks, therefore, unlike most existing research on forking, we did a longitudinal study. We formed 10 equispaced consecutive time-window snapshots of the socio-grams for the community, using the mailing list interaction data and the source code repository commit activity data. These socio-grams were used to find a well-fitting statistical model that would explain how they changed from time-window t 1 through time-window t 10 .

The Statistical Model

Longitudinal evolution of a network data is the result of many small atomic changes occurring between the consecutively observed networks. In our case, software developers are the actors in the networks, and they can form a connection with another developer, break off an existing connection, or maintain their status quo. These are the four possibilities of atomic change within our evolving networks: (1) forming a new tie; (2) breaking off an existing tie; (3) maintaining a non-connection; and (4) maintaining a connection. We assume a continuous-time network evolution, even though our observations are made at two or more discrete time points.

The state-of-the-art in studying longitudinal social networks, is the idea of actor-oriented models [START_REF] Snijders | Introduction to stochastic actor-based models for network dynamics[END_REF], based on a model of developers changing their outgoing ties as a consequence of a stochastic optimization of an objective function. This framework assumes that the observed networks at discrete times, are outcomes of a continuous-time Markov process. In the case of open source developers, the actor-oriented model, can be informally described as OpenSourceDeveloper-oriented model, in which, it is assumed that developers are in charge of their communication and collaboration choices. They choose to have interactions with certain other developers and/or they choose to stop having interactions with another developer. In short, they have autonomy in choosing their connections.

Let the data for our statistical developer-oriented model be M repeated observations on a network with g developers. The M observed networks (at least two) are represented as directed graphs with adjacency matrices X(t m ) = (X ij (t m )) for m = 1, ..., M , where i and j range from a to g. The variable X ij shows whether at time t there exists a tie from i to j (value 1) or not (value 0). Be definition, ∀i, X ii = 0 (i.e. the diagonal of the adjacency matrices).

In order to model the network evolution from X(t 1 ) to X(t 2 ), and so on, it is natural to treat the network dynamics as the result of a series of small atomic changes, and not bound to the observation moment, but rather as a more of less continuous process. In this way, the current network structure is a determinant of the likelihood of the changes that might happen next [START_REF] Coleman | Introduction to Mathematical Sociology[END_REF].

For each change, the model focuses on the developer whose tie is changing. We assume that developer i has control over the set of outgoing tie variables (X i1 , ..., X ig ) (i.e. the i th row of the adjacency matrix). The network changes one tie at a time. We call such an atomic change a ministep. The moment at which developer i changes one of his ties, and the kind of change that he makes, can depend on attributes represented by observed covariates, and the network structure. The moment is stochastically determined by the rate function, and the particular change to make, is determined by the objective function and the gratification function. We cannot calculate this complex model exactly. Rather than calculating exactly, we estimate it using a Monte Carlo Markov Chain method. The estimated model is used to test hypotheses about the forked FOSS communities. These above three functions and their definitions taken from [START_REF] Snijders | Models for longitudinal network data[END_REF] are explained in detail the following subsections.

Rate Function

The rate function λ i (x) for developer i is the rate at which developer i's outgoing connections changes occur. It models how frequently the developers make ministeps. The rate function is formally defined [START_REF] Snijders | Models for longitudinal network data[END_REF] by

λ i (x) = lim dt→0 1 dt P X ij (t + dt) = X ij (t)
f or some j ∈ {i, ..., g}|X(t) = x) .

(1) The simplest specification of the rate of change is that all developers have the same rate of change of their ties.

Objective Function

The objective function f i (s) for developer i is the value attached to the network configuration x. The idea is that, given the opportunity to make a change in his outgoing tie variables (X i1 , ..., X ig ), developer i selects the change that gives the greatest increase in the objective function. We assume that if there is difference between developers in their objective functions, these differences can be represented based on the model covariates [START_REF] Snijders | Models for longitudinal network data[END_REF]. For more details, please refer to [START_REF] Snijders | Models for longitudinal network data[END_REF]. The following weighted sum represents the objective function (2):

f i (β, x) = L k=1 β k s ik (x) (2)
Parameters β = (β 1 , ..., β L ) is to be estimated. Functions s ik (x) can be the following [29]:

Structural Effects

For the structural effects, the following were used in the objective function.

1. The reciprocity effect, which reflects the tendency toward reciprocation of connections. A high value for its model parameter will indicate a high tendency of developers for reciprocated interactions. 2. The closure effects (e.g. in friendship networks, it means, friends of friends tend to become friends) In our case, Transitive triplets effect, which models the tendency toward network closure. It reflects the preference of developers to be connected to developers with similar outgoing ties. 3. Three-cycles, may be interpreted as the tendency toward local hierarchy. It is similar to reciprocity defined for three developers, and is the opposite of hierarchy. 4. Activity, which reflects the tendency of developers with high in-degree/outdegrees to send out more outgoing connections because of their current high in-degree/out-degree.

5. Covariate effects: Developers' covariates may influence the formation or termination of ties. For example: (a) Covariate V-related activity, which reflects the developer i's out-degree multiplied by his covariate V value. (b) Covariate V-related dissimilarity, which reflects the sum of differences in covariate V values' between developer i and all developers to whom developer i is connected. We use the following developer attributes as covariates:

-(Covariate V1) Developer's level of activity (i.e. mailing list posts per month) -(Covariate V1) Developer's level of contribution (i.e. code commits per month) as shown in Table 2. -(Covariate V4) Developer's seniority as a development community member (i.e. how many total contributions they have had in the lifetime of the project) 6. out-out degree assortativity, which reflects which reflects the tendency of developers with high out-degree to be connected to other developers with high out-degrees

Markov Chain Transition Rate Matrix

The components of the developers-oriented model, described above, define a continuous-time Markov chain on the space χ of all directed graphs on this set of g developers. This Markov chain is used to estimate the model parameters stochastically, instead of calculating them exactly, which is not possible for us. This Markov chain has a transition rate matrix. The transition rate matrix (also called intensity matrix), for this model is given by expression (3):

q ij (x) = lim dt→0 1 dt P X(t + dt) = X(i → j)|X(t) = x) = λ i (x)p ij (x) (3)
Expression [START_REF] Azarbakht | Drawing the Big Picture: Analyzing FLOSS Collaboration with Temporal Social Network Analysis[END_REF] shows the rate at which developer i makes ministeps, multiplied by the probability that he changes the arc variable X ij , if he makes a ministep. Our Markov chain can be simulated by following the steps explained in [START_REF] Snijders | Models for longitudinal network data[END_REF].

Markov Chain Monte Carlo (MCMC) Estimation

The described statistical model for longitudinal analysis of open source software development communities is a complex model and cannot be exactly calculated, but it can be stochastically estimated. We can simulate the longitudinal evolution, and estimate the model based on the simulations. Then we can choose an estimated model that has a good fit to the network data. For details of the simulation and estimation procedures please refer to [START_REF] Snijders | Models for longitudinal network data[END_REF]. The desirable outcome for the estimation is the vector parameter β for which the expected and the observed vectors are the same.

Results

The results of parameter estimation are listed in Table 1. The parameter estimates that are statistically significant are marked with an asterisk (*) in Table 1. Recall that the weighted sum in expression (2) represents our objective function, and the effects listed in Table 1 are the parameter estimates of β k 's in expression [START_REF] Azarbakht | Temporal Visualization of Dynamic Collaboration Graphs of OSS Software Forks[END_REF].

The rate parameters represent the rate of change for the period between t 1 to t 2 for developers (i.e. how likely developers were to change ties in that time period). There's a clear trend in the rates 1-9, with a peak of 11.65 for the t 4 to t 5 time period. This suggests a significantly higher "preference" by developers for (a) forming new ties and interacting with previously non-connected developers and (b) terminating a previously connected tie. This peak value dies down as to less than 1, for the the t 8 to t 9 time period at 0.79 which can be used as an early warning sign of an imminent change decision.

Conclusion

In this study, we used a developer-oriented approach to statistically model the changes a FOSS community goes through in the run-up to a fork. The model represented tie formation, breakage, and maintenance between developers. We use 10 snapshots of the graph as observed data to estimate the influence of several effects on formation of the observed networks. We used a stochastic estimation method to estimate several model parameters of the model and used a Wald-type t-test to estimate the significance of these parameters on this longitudinal change.

The results show that the out-out degree assortativity and the outdegree (density) effects are statistically significant, which can be interpreted that developers maintained a "preference" for interacting with developers who had similar outdegree levels. For example, core developers with high levels of mailing list activity responding to messages, were more likely to be connected to other similarly behaving high-outdegree developers. Also, that top answerer/repliers on the mailing list were more likely to contact other top developers, and the community shows a preference for inter-stratum ties.

The developers' source code repository contribution level (devScAct ego) was also statistically significant, which implies developers with higher levels of source code contributions increase their outdegree more rapidly. The developers' source code repository contribution level (devScAct alter) is also statistically significant, which implies developers with higher levels of source code contributions increase their indegree more rapidly.

Perhaps, an interesting observation is the existence of significance for high activity/contribution to the source code repository, however, in contrast, there's a lack of significance for high activity on the mailing list. In summary, high levels of contribution to the source code brings you connections more rapidly, while high levels of contributions to the mailing list is not suggestive of this. This can be interpreted as a sign of meritocracy based on code, rather than talk, which captures a healthy dynamic in this project, that was forked because of addition of functionality, and was classified as a healthy fork.

Threats to Validity

The study findings may not be generalized. First, one reason is that the projects is this research study were selected from a pool of candidate projects, based on a filtering criteria that included availability of their data. Given access, a larger number of projects as the sample size could result in a more robust investigation.

Second, we used data from online communications. The assumption that all the communication can be captured by mining repositories is intuitively imperfect, but inevitable. Third, social interactions data is noisy, and our statistical approach might be affected because of this.

Third, the statistical model we use to model the longitudinal evolution of collaboration networks is estimated stochastically, rather than being calculated exactly. The stochastic process might not always arrive at the same results. To counter this issue, we run the algorithm several times to double-check for such irregularities.

Table 2: The list of developers source code contributions in the 10 months runup to the forking event, sorted by total number of commits.

Fig. 1 :

 1 Fig. 1: The methodology in a glance

Table 1 :

 1 Parameter estimates

	Effect	par.	(s.e.)
	Rate 1	1.419 (0.402)
	Rate 2	2.633 (0.919)
	Rate 3	3.231 (1.222)
	Rate 4	11.656 (7.158)
	Rate 5	5.238 (1.871)
	Rate 6	5.431 (1.901)
	Rate 7	1.863 (0.520)
	Rate 8	0.791 (0.258)
	Rate 9	0.671 (0.206)
	outdegree (density)*	-5.389 ( 0.300)
	reciprocity	-6.448 (31.754)
	transitive triplets	-0.582 ( 0.875)
	3-cycles	-2.680 ( 8.084)
	out-out degree (1/2) assortativity*	1.123 ( 0.291)
	devScAct alter*	-0.021 ( 0.009)
	devScAct ego*	0.011 ( 0.003)
	devScAct ego x devScAct alter	-0.000 ( 0.000)
	devMlAct alter	0.141 ( 0.010)
	devMlAct ego	-0.037 ( 0.051)
	devMlAct ego x devMlAct alter	0.002 ( 0.003)
	int. devMlAct ego x devScAct ego* 0.003 ( 0.002)