In distributed open-source software projects, participation of developers is largely by a voluntary basis. Programmers are not only free to join in or to leave the project, but they are also free to choose who they interact with, and how much they contribute to the project. In that sense, open-source project developers form a dynamic social network. This paper presents a measure to represent the interactions of distributed open-source software developers and utilizes data clustering techniques to mine their email archives to derive a representation of the associated social network. This method is applied on case studies of three social networks from two open-source projects, Linux and KDE. The dynamics of the three networks are then analyzed and simulated using agent-based modeling techniques. Our study shows that the three open-source developer networks evolved over time with some predictable patterns.
Software development process is not only the development work of developers, the
interactions between them is also very important. Theses interactions which form a
social network is critical for cooperation, issue resolution, and information sharing
[
Open-source software consists of programs whose licenses give its users the
freedom to run the program, to study and modify the source code, and to redistribute
copies of the program [
One important difference between closed-source software organization and opensource software organization is the stability of the developer network. In closedsource projects, the developers are relative stable with respect to the activities they perform, other developers they interact with, and their respective roles; while in opensource projects, participation is largely voluntarily, programmers are not only free to join in or leave the project, but they are also free to choose who they interact with, and how much they contribute to the participating project. Accordingly, the opensource project developer network is highly dynamic and evolves continually over time.
Due to this loose management property, the information about open-source project
organization, alliance formation, and communication network is not very well
documented. However, open-source software projects contain email archives, which
constitute an extensive on-line record of user feedbacks, issue resolutions, and
problem-solving behaviors [
In this study, we use communications in mailing lists to construct and analyze the social network. First, we introduce some terminologies and metrics to represent mailing lists and the interactions between developers.
A message is the smallest unit of information posted by one person at a time. A message can be either an initiating message that starts a new topic or a replied message that responds to other messages (either a new message or a replied message).
A thread is defined as a collection of messages that discuss the same topic. A thread contains one initiating message and zero or more replied messages.
A poster is a person posting a message on the list, who is either an initiator or a replier. An initiator is one who posts an initiating message on the mailing list. A replier is one who posts a replied message on the mailing list.
A mailing list is a forum for project managers, developers, bug-reporters, and users to exchange ideas, report problems, and find solutions. Any posted messages will be delivered to all the subscribers. Although messages are delivered to all the subscribers, most of the topics are not of interest to regular subscribers. Instead, a message thread might only be interesting to those subscribers who participate in the discussion in this thread.
Therefore, communications between two posters who posts the replied message and who receives the replied message (more accurately, the target audience of the replied message) form a channel. A channel could be either a one-way or a two-way channel. A one-way channel exists between two posters P1 and P2, in which P1 replies to the message posted by P2. A two-way channel exists between two posters P1 and P2, in which both P1 and P2 reply to the messages posted by each other.
A one-way channel (say P1→P2) represents the service relationship between P1 and P2, i.e., P1 answers or comments on P2’s message. A two-way channel (say P1↔P2), represents the collaboration/coordination relationship between P1 and P2, i.e, P1 and P2 discuss some common interesting topics.
The organization of the communication network can be represented by two measures, bandwidth and interaction degree. The bandwidth of a channel is the measure of the communication frequency between two members: The bandwidth of a one-way channel P1→P2 is the number of messages posted by P1 that is a reply to the message from P2; The bandwidth of a two-way channel P1↔ P2 is the number of messages posted by P2 to reply a message from P1 plus the number of messages posted by P1 to reply a message from P2.
The interaction degree is the number of channels between one particular member
and all other members in the network. Generally speaking, a poster with a larger
interaction degree tends to play a more central role in the community, because s/he
interacts with more members [
This study contains five steps. Each of these steps is identified and further elaborated below.
To represent the degree of interactions between developers, we adopt a
terminology, interaction frequency (IF) [
The measurement of interaction frequency is a context-based concept, which means different measures may result in different interaction frequency. In distributed open-source development, candidate measures for interaction frequency are the frequency of email correspondence, the frequency of co-editing, the frequency of task sharing, and so on. In this study, email correspondence between developer i and developer j is used as the measure of interaction frequency IFi, j.
Interaction frequency gives the representation of the degree of interaction between two developers. What we are interested is a large project that contains many developers. Therefore, we define interaction matrix (IM). For a project that contains n developers, the degree of interactions between these n developers is represented as an n×n interaction matrix (IM), in which item at position (i, j) is the interaction frequency between developer i and developer j.
Clustering is a data mining technique to group items into clusters according to their
similarities, differences, or distances [
In a distributed open-source development environment, developers take different
roles. In our preliminary study [
To study the dynamics of the networks, we need to study the evolution of the organization of the social network, which includes the evolution of average bandwidth, the evolution of the average interaction degree, and the updating of the central members. Two metrics are used to measure the updating of the central members, annual updating rate and age distribution, which will be further explained later.
Agent-based simulation is a special type of discrete simulation, in which the
individual entities (agents) are represented with an internal state and a set of rules
which determine how the agent’s state is updated from one time-step to the next [
In this research, three email archives of two open-source projects, Linux and KDE, are mined and used to study the open-source developer network.
The Linux-kernel mailing list (linux-kernel@vger.kernel.org) is maintained by
vger.kernel.org to provide email list services for the Linux kernel developers [
In contrast to Linux, KDE has four development mailing lists [
Therefore, Linux-kernel, KDE-core, and KDE-development mailing lists are chosen for studying the corresponding developer networks. In the remainder of this paper, they are referred to as Linux, KDE-core, and KDE-development respectively.
A total of over 611k, 14k, and 37k messages over seven years (2000-2006) of communication were mined from the email archive of Linux, KDE-core, and KDEdevelopment. Table 1 shows the total number of messages and total number of threads posted to the three mailing lists in these different years. As we can see, the number of messages and the number of threads of Linux have an increasing trend, while the number of messages and the number of threads of KDE-core and KDEdevelopment give a decreasing trend. We can also find that Linux mailing list carries more messages than the KDE lists. For example, Linux mailing list had about 100 times of messages over KDE-core and KDE-development lists in year 2006. Therefore, the Linux and KDE mailing lists represent different scales and different evolutionary trends of developer social networks.
Table 2 shows the number of posters and the number of initiators in the three mailing lists during the time period of our investigations. A poster can post one or many messages and an initiator can post one or many initiating messages. The number of posters represents the number of developers in the social network. We can see that the size of the three networks evolves differently: Linux and KDE-core change a little bit while KDE-development decrease dramatically.
Next, we need to determine which metric in the mailing list can be used to represent the interaction frequency (IF) between two developers. Because in the clustering process, two members, P1 and P2, are considered equally important (active) regarding the channel bandwidth between P1 and P2, a two-way communication channel is superior to one-way channel. Therefore, we use the bandwidth of two-way communication channel to represent interaction frequency, to cluster the developers, and to construct the social network.
As stated in Section 3, in this paper, we study the evolution of central-100 network. Figure 1 shows part of the Linux central-100 developer network of 2006, in which different thickness of the link represents different bandwidth. The largest bandwidth has value 318 and exists between Andrew and Adrian, while the smallest bandwidth has value 73 and exists between Eric and Oleg.
Figure 1 shows that a few members, such as Andrew and Andi, have larger channel
bandwidth and higher interaction degrees, while most others have smaller channel
bandwidth and lower interaction degrees. This observation agrees with what Bird el
al. found - that a few members account for the bulk activities of the network [
The age of a member in the central-100 network represents the relative experience of the developer on this effort as well as the stability/evolution of the social network. It can be seen from the figure that different ages exist in the three networks, which means that the network developers are updating dynamically: every year, some developers leave the central-100 network and some members join the central-100 network.
The evolution of the dynamically changing open-source developer network can be measured using three metrics: the change in bandwidth, the change in interaction degree, and the change in membership of the central network.
We studied the evolution of the average channel bandwidth and the average interaction degree of the central-100 network, the results of which are shown in Figure 5 and Figure 6, respectively. The average interaction degree and the average bandwidth have other meanings in the social network: the former can represent the network structure and the latter can be used to represent the amount of activities in the network. As we can see in Figure 5, the activity of the Linux network have been increasing from 2000 to 2006, while the activity of KDE-core and KDE-development networks first decreased and then remained relative stable from 2000 to 2006. Figure 6 shows that the average interaction degree of three networks decreases from 2000 to 2006. Therefore, both the activity and the structure of the network evolve from year to year.
Figure 7 illustrates the annual updating rate of the cluster-100 network. The annual updating rate is the percentage of developers in central-100 network that are changed compared to the previous year. For example, it shows that compared with 2000, about 50% of the Linux central-100 network developers are updated in 2001. Or in other words, it shows that in 2001, 50 developers in Linux central-100 network are new compared with the same network of 2000. Compared with the evolution of average bandwidth and average interaction degree shown in Figures 6 and 7, the annual updating rate of central-100 developers is relatively stable. Therefore, the annual updating rate of central-100 developers might be a stable parameter to represent the property of the network.
As described before, channel bandwidth and interaction degrees changes from year to year for each project. They are not feasible to represent the property of the network. In contrast, updating rate of central-100 developers is relative stable for all networks. Therefore, it represents a unique feature of the network and is used to model and predict the behavior of the network.
In order to predict the evolution of open-source developer network, we modeled
and simulated the entire developer networks. In the proposed simulation model, each
developer is represented as an agent. The agent’s activity is represented with a
number in the range of [
First, we assume that the activity score of an agent for a given year, i is most impacted by the activity score in year i-1. This assumption is represented as ASi ∝ ASi+1 .
A power decay function (base 2) is used to weight the most recent years’ activity
more than any of its predecessor years. This recency approach is adopted from our
previous study on predicting open-source bugs [
In Equation 1, x is the simulation step (year) and is equal to or greater than 1. In the proposed model, the activity score of each agent updates every year, and accordingly, the central-100 members are updated every year. The formula to calculate the activity score of a particular agent is shown below.
⎪⎧ i−1 R i = 1 (2)
ASi = ⎨⎪⎩(1 −α ) ∑x=1 f (x) ASi−x +αR i > 1
Where ASi is the activity score at year i (i≥1); R is a random number that is
uniformly distributed in range [
The simulation setup is shown in Table 3. The number of agents is chosen as the total number of posters from 2000 to 2006 for each network. The number of cycles is the number of steps (years) the data is collected. In the observation, we have 7 years (2000 to 2006) data; therefore, the number of cycles is set to 7 for all three models. The number of pre-cycles is the number of cycles the model is run before the data is collected. Since the Linux project started in 1992, the number of pre-cycle is set as 8 (1992 to 1999); the KDE project started in 1996, the number of pre-cycle is set as 4 (1996 to 1999).
Before the formal simulation, we run a series of pre-experiments with a range of turbulence factor α for Linux, KDE-core, and KDE-development. The turbulence factor is finally determined to use those that generate the best fit to the observed the annual updating rate, which is 0.50, 0.51, and 0.75 for Linux, KDE-core, and KDEdevelopment respectively, as shown in Figure 7. Accordingly, the turbulence factor for the formal simulation is 0.08, 0.23, and 0.37 for Linux, KDE-core, and KDEdevelopment respectively.
It can be seen that KDE-core has a relative small turbulence factor than KDEdevelopment, and Linux has a much smaller turbulence factor than both the KDEs. According to Equation 2, it is therefore reasonable to infer that the developers in the Linux project form a more stable group than those in KDE projects. Here, the stability is referring to the activity performed by each agent: if the agent’s current activity is more dependent on his activity history and predicable, it is more stable; if his current activity is less dependent on his activity history and is unpredictable, it is unstable.
For the given model setup shown in Table 3, each network is formally simulated 100 times to study the changing of central members. The average annual updating rate of the central-100 active agents is shown in the boxplot of Figure 8, in which the mean of average annual updating rate of the 100 simulations is 0.50, 0.51, and 0.75, which match the observations shown in Figure 7. In the figure, the bold line within the box indicates the median. The box spans the central 50 percent of the data. The lines attached to the box denote the standard range. The circles indicate the data points that are out of the standard range.
To understand whether the proposed model can predict similar age distributions, the average value of the number of central-100 active agents with different ages is obtained in these 100 times of simulations. Figure 9 compares the age distribution of central-100 developers observed from the mailing list with the age distribution of the central-100 active agents obtained from the simulation in 2006. From the figure, it can be seen that KDE-development has a better match of age distribution than Linux and KDE-core.
To quantitatively study the accuracy of the simulation, we calculate the average age of central-100 members from both the measurement and the simulation. The results are shown in Table 4. The difference is calculated using the formula Difference = abs(simulation − measurement) / measurement . We can see that the Linux model and the KDE-development model have higher accuracy in predicting the average age of central members.
In the proposed three agent-based simulation models, Linux has the smallest turbulence factor, which means that the activity of agent in the Linux is more stable than agents in KDE models. The stability of agents also represents the stability of the network. Accordingly, we can say that the Linux social network is more stable than KDE’s. This is also reflected in both the measurement and the simulation of the average age of the central-100 members shown in Table 4.
In this paper, we presented the results of studying the evolution of open-source developer networks using data mining and simulation techniques. Case studies were performed on two open-source projects, Linux and KDE. Three developer networks were constructed and analyzed. The simulation of agent-based models successfully predicted the average age of the central-100 developers of three networks.
This work was based in part, upon research supported by the National Science Foundation (CNS-0619069, EPS-0701890 and OISE 0650939), Acxiom Corporation (# 281539) and NASA EPSCoR Arkansas Space Grant Consortium (# UALR 16804). Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the funding agencies.