Abstract

Open source design (OSD) is an emerging cluster design mode based on Internet, and it takes full advantage of knowledge, technology, and resources among designers to promote product development. In this mode, designers’ behaviors of collaboration have important influence on product development process. In this paper, firstly collaboration flow including two types of collaboration relations between designers in open source design is depicted. Secondly, two-phase collaborative behavior model including partner selection and response is built by means of utility functions. At last, simulation experiment including 4 scenarios is designed based on open source project of mobile phone and conducted by multiagent simulation, and contrastive analysis is carried out to study collaboration behaviors’ impact on open source design process. The results show that the two-phase collaborative behavior model elaborately describes structure evolution of Open Source Community (OSC) as well as designers’ collaboration behaviors and that different ways of partner selection behaviors have significant impact on the evolution of OSD process as well as OSC structure. Furthermore, the results suggest that designers should better consider more the factor of matching degree between designers but less collaboration record.

1. Introduction

Open source design (OSD), also known as mass collaborative product development, is an emerging design mode in recent years. In OSD, a mass number of volunteer designers with complementary knowledge develop product autonomously and complete product creation, design, test, and even popularization together by means of open network platform [1]. OSD is developed rapidly with advantage of high innovation, low cost, and high customer satisfaction. Thus, it has become an important complementary mode of traditional collaborative product development (CPD) gradually. Different from the top-down organization mode of traditional CPD, OSD is in bottom-up and self-organized structure. Moreover, OSD can make full use of the mass emergence of design originality as well as sharing of technology, resource, and knowledge between designers. With the popularization of Internet and the promotion of “Internet +” mode, there are many successful application cases in open source software (OSS) [2], such as Linux, Apache, and Mozilla, which have been proved good robustness and adaptability. Besides, OSD is also applied in industrial product design [3], such as Open Source Hardware, Prosthetics Project, and Lego Mindstorms [4], in which individuals or enterprises release product originality or CAD models to Open Source Community (OSC), and a wide range of community members collaborate to develop the conceptual products.

With the emergence of OSD, abundant research has been conducted, such as OSD operation mechanism [5], motivation of designers [6, 7], and influence factors [8, 9]. Compared to traditional software, OSS development has the advantage of high quality, low cost, high personnel participation, low product defect rate, and fast response to customer problems [5]. Besides, OSD mode also brings the advantage of reductions on time and cost in hardware design [10]. As the main element of OSD, the designer plays a key role in OSD process, whose design behaviors drive the direction of product evolution and outcome directly. Among these behaviors, collaboration behavior between designers is the typical one during OSD process. Bonaccorsi et al. [11] discussed that the collaboration mechanism between designers played an important role in open source software design process. Crowston et al. [12] illustrated the importance of collaborative mechanisms according to an E-mail survey of open source software designers. To describe the collaboration process between designers and fully tap its potential in OSD process, designers’ collaborative behaviors are studied in this paper and a two-phase collaborative behavior model including both partner selection and collaboration response is proposed.

2. Literature Review

The collaboration between designers comprehensively represents characteristics of OSD such as self-organization, bottom-up design, and innovation sharing directly drives the evolution of open source product. However, there is little research on OSD collaboration. The previous research on collaboration mainly focuses on partner selection, which includes single-node partner selection and multinode partner selection. Single-node selection denotes a single agent’s selection behavior to choose partners from many candidates, which focuses on studies of evaluation index and multiattribute evaluation methods, such as design partner selection, supplier selection, and business partner selection. Regarding the issue of design partner selection, Baldo et al. [13] proposed a framework of performance indicators to aid the user to select appropriate partners. Chen et al. [14] established the index system for product research and development partner selection by applying Analytic Hierarchy Process (AHP) approach, by which the optimal partner was selected from different candidates. It is a necessary condition to choose design partner in green production, and Liu et al. [15] proposed a two-stage dynamic hybrid MADM (Multiattribute Decision-Making) approach based on fuzzy DEMATEL (Decision-Making and Trial Evaluation Laboratory), fuzzy KMA (Karnik–Mendel Algorithm), and fuzzy VIKOR (VlseKriterjumska Optimizacija I Kompromisno Resenje) for partner selection. In the research of supplier selection, Bunduchi et al. [16] explored the role that trust played during the selection of suppliers in new product development (NPD), finding goodwill trust as the key variable explaining the reliance on collaboration by case study. Buyukozkan et al. [17] proposed a fuzzy multiobjective decision framework to optimize the selection of e-logistics partner, applied the fuzzy AHP method to set the weight of the optimization index, and used the fuzzy TOPSIS method to rank partner candidates. In the research on enterprise partner selection, Huang et al. [18] divided factors affecting the partner selection process into two categories, hard and soft factors, and designed a two-stage manufacturing partner selection framework accordingly to assist the decision-making process in selecting efficient and compatible partners. Radziszewska‐Zielina [19] proposed 14 parameters for assessing partnering relations in construction enterprises and applied ELECTRE III algorithm to select the best construction enterprise on the basis of the analysis of partnering relations. Dai et al. [20] designed an evaluation index system of enterprise partners from 3 aspects, such as compatibility, reputation, and complementarity, and built a model to choose partners with Theil index of nonequilibrium and fuzzy comprehensive evaluation method. Huang et al. [21] proposed a new method of using the grey system theory to account for uncertainties in a project’s start time, completion time, transportation time, and cost, to study partner selection problem for virtual manufacturing enterprises facing an uncertain environment.

Multinode selection refers to the problem on how to select partner combination for designers in different nodes who ask for collaboration simultaneously to achieve common goals. In addition to evaluation index study, the research on multinode selection mainly focuses on the overall system optimization, such as partner selection of design chain, supply chain, and manufacturing business alliance. Regarding enterprise partner selection of design chain, Chiang [22] developed an integrated decision-making methodology to assist enterprises as they created an optimal design chain partner combination. Chen et al. [23] divided the new product development process into three stages, proposed a design partner selection model to minimize the overall design chain cost, taking into account communication cost, time-to-market and quality, and selected the partners of all stages with dynamic programming algorithm. Wang and Lin [24] considered design chain partnership formation as a multicriteria decision-making problem, built a fuzzy hybrid decision-aid model to tackle both qualitative and quantitative factors as well as the decision flexibility, and applied a genetic algorithm approach to select the set of partners that satisfied the constraints of target development time and cost at the same time. Feng and Fan [25] put forward a partner selection method of knowledge creation team in consideration of the collaboration relationship and collaborative effect between partners and developed a GRASP heuristic algorithm to get the optimal partner collection. Lin et al. [26] classified partner’s selection of knowledge innovation alliances as MCDA (Multicriteria Decision Analysis) decision-making problems, designed partner selection indicator system, and proposed an MCDA decision-making method-VIKOR to solve it. In view of supply chain partner selection problems, Yeh and Chuang [27] took into account 4 objectives such as cost, time, product quality and green appraisal score, developed an optimum mathematical planning model for green partner selection, and adopted two multiobjective genetic algorithms to find the set of Pareto-optimal solutions. Regarding partner selection problems of manufacturing alliance, Xiao [28] took the running cost, the reaction time, and the running risk into consideration and proposed an adaptive quantum swarm evolution algorithm with time-varying acceleration coefficients to solve the problem of the optimal partner selection. Wang et al. [29] elaborately analyzed 6 collaboration modes between distributed partners with the corresponding evaluation metrics for collaboration time and cost and applied a genetic algorithm solution for collaboration cost optimization-oriented partner selection. Dao et al. [30] constructed the integration model of partner selection and collaborative transportation scheduling in virtual enterprise and designed a novel genetic algorithm combining a unique dynamic chromosome representation and genetic operations to find an optimal solution to the integrated problem. Cheng et al. [31] applied adaptive genetic algorithm to solve the problems, such as equilibrium allocation of production tasks and partner selection of virtual enterprises, and got optimal combination of virtual enterprise, so as to reduce idle equipment and other resources, and resource conflicts. Niu et al. [32] regarded partner selection, which is attributed to a multiattribute optimization problem, as a key issue tightly coupled to the success of a virtual enterprise coalition, considered 5 attributes (cost, time, quality, reputation, and risk) to evaluate the candidate partners, and proposed an enhanced ant colony optimizer (ACO) to address the issue. Crispim and Sousa [33, 34] regarded partner selection of virtual enterprise as the multiattribute decision-making problem and applied multiobjective taboo search heuristic algorithm and TOPSIS algorithm to optimize the allocation of partners, in consideration of the history of enterprise cooperation.

The aforementioned research comprehensively involves collaboration problems of single-node and multinode partner selection, including studies of evaluation index, selection model, and solution algorithm, providing important reference for partner selection of OSD collaboration. However, there is significant difference between existing research and the new issue of OSD collaboration. Firstly, the current single-node partner selection is mainly based on evaluation index system and multiattribute evaluation methods, while OSD mode is a kind of stranger-based social network, resulting in little information on partner candidates as well as dynamic decision-making environment and making it difficult to establish stable and comprehensive evaluation index system for partner selection. Moreover, different from enterprise partner selection, behaviors of OSD individuals, who are from different fields with various interests and preferences, are probably not entirely rational, resulting in much uncertainty of OSD collaboration. Therefore, an individual utility function, in consideration of evaluation indicators and individual preferences, is proposed in this paper to describe collaborative behaviors of OSD designer. Secondly, as OSD collaboration is frequently performed in real-time OSD process, it is unlikely to get global optimal solutions by programming modeling whenever it occurs and impossible to handle the issues by centralized management. it is an effective way to get satisfactory solutions by distributed decision in OSD process. Consequently, it is necessary to evaluate the impact of various collaborative behaviors on OSD process by simulation from perspectives of system evolution. Based on above analysis, a multiagent modeling and simulation method is proposed to study designers’ collaborative behaviors during OSD process in this paper. The reasons for applying multiagent modeling and simulation method are described as follows.

(1) As an emerging mode of new product research and development, OSD, with characteristics of nonlinearity, innovativeness, etc. [35], cannot be described comprehensively by theories like linear systems and chaotic systems. In consideration of OSD’s typical characteristics, it is applicable to solve this problem by Complex Adaptive System (CAS) theory based on multiagent modeling and simulation [36], which is proposed to deal with problems of system’s openness and dynamics, as well as constant changes of environment variables [37]. Besides, multiagent simulation method is proved to be good at solving issues such as innovation diffusion, organizational strategy, and knowledge/information flow [38].

(2) Different from traditional product design, OSC operation is bottom-up and self-organized, providing designers adequate autonomy in OSD process. Correspondingly, ABM (Agent-Based Modeling) applies to the research on various behaviors in social network of incomplete information, limited rationality and individual heterogeneity [38]. For example, Panchal [39] proposed a model based on an agent-based modeling approach that allowed the modeling of the behavior of different entities within OSC and the study of the effect of their interactions.

Based on literature analysis and case study, the collaboration flow in OSD process is extracted in this paper. Moreover, a two-phase collaborative behavior model including partner selection and request response is built, and comparison scenarios of different partner selection based on multiagent simulation method are designed to analyze the influence of the partner selection behaviors on product evolution of OSD process as well as structure evolution of OSC.

3. Collaboration Flow in OSD Process

In OSD process, open source product project is divided into several independent yet interdependent module tasks according to product’s requirement for functions and technology, and these tasks are selected and completed autonomously by a large number of individual designers of OSC [38]. While executing module tasks, individual designer often cannot complete them due to the lack of knowledge, skills, or other uncontrolled factors and hence has to solve such problems by collaboration. Correspondingly, collaboration request is packaged into collaboration task and sent to partner candidates in OSC for collaboration.

Collaboration is a kind of typical behaviors that drive product evolution of OSD, comprehensively represents interactions between designers, and directly influences OSD outcomes. According to the collaboration process in OSD cases [40], the collaboration is divided into two ways: online collaboration and offline collaboration. Online collaboration refers to the collaboration that the designer and the partner together complete collaboration task simultaneously, while offline collaboration refers to the collaboration that the partner completes collaboration task alone and the designer who ask for collaboration does not participate [41]. The collaboration flow in OSD process is as shown in Figure 1.

(1) Task Exception. Designer ( denotes designer’s ID, ) suspends the current task ( denotes task’s ID, ) when encountering exception for lack of knowledge, skills, and so on, which holds back task execution.

(2) Collaboration Task. Based on the analysis of task () exception, has to ask for collaboration to solve the problem and hence packages the collaboration request into collaboration task ( denotes collaboration task’s ID), which describes the requirement for knowledge, skills, and so on, to solve the exception.

(3) Release Collaboration Request/Task. releases collaboration request in the form of collaboration task to public to find some partner(s) in OSC for collaboration. In this phase, there are two ways that are online collaboration and offline collaboration to complete . In online collaboration, selects designer (j denotes designer’s ID) as collaboration partner, sends collaboration request to him, and completes together; in offline collaboration, sends collaboration request to OSC and selects designer whom OSC recommends as collaboration partner, and completes alone.

(4) Online Collaboration. In consideration of personal preferences such as collaboration records with candidates and objective attributes such as candidate’s skill level and knowledge level, firstly selects as collaboration partner from candidates and sends to for collaboration; secondly, decides whether to respond to the request. If yes, and complete collaboration task together; if not, changes the collaboration way and releases to OSC for offline collaboration. The process of online collaboration between and is shown as the left Gantt chart of Figure 1.

(5) Offline Collaboration. Firstly, based on personal preferences (e.g., collaboration records) and other requirements of , OSC recommends a number of community members as partner candidates to and recommends to the candidates; secondly, the candidates who receive decide whether to respond to the collaboration request of . If yes, partner completes separately; otherwise, does not participate in the collaboration. There are probably multiple candidates responding to , hence getting more than one outcome version for . At last, needs to select one that best satisfies the collaboration request from the versions. The process of offline collaboration between and is shown as the right Gantt chart of Figure 1.

(6) Collaboration Completion. After the completion of collaboration task , the collaboration process comes to an end, and and continue to contribute to product evolution of OSD.

In this section, collaboration flow in OSD process is illustrated. As shown in Figure 1, whether the designer chooses online or offline collaboration, it involves two decision-making processes: partner selection and collaboration response. In offline collaboration, partner selection is accomplished by OSC recommendation. During collaboration process, different decision may result in different quality of collaboration outcome, thus affecting the overall evolution of OSD process. Therefore, a two-phase collaborative behavior model of OSD collaboration including utility functions of partner selection and collaboration response is built in this paper, to make quantitative study on collaboration process.

4. The Two-Phase Collaborative Behavior Model of OSD Collaboration

In OSD process, a collaboration flow includes two phases: partner selection and response to collaboration request/task. Firstly, in consideration of subjective and objective factors such as collaboration records, knowledge, and skills, the designer who asks for collaboration selects the appropriate partner from candidates in OSC and sends collaboration request/task to the partner. Secondly, the partner decides whether to respond to the request, considering some factors such as the recognition to the designer and the expectation to collaboration outcome. If the partner responds to the collaboration request, the collaboration will be performed; otherwise, the collaboration fails. Therefore, the whole collaboration process includes both two phases of selection and response. However, the current research on collaboration is focused on the selection phase, usually ignoring response phase. Consequently, a two-phase collaborative behavior model of OSD collaboration process is built, including utility functions of partner selection and collaboration response, which are described as follows.

4.1. Utility Function of Partner Selection

In partner selection phase, the utility function, by which designer selects the best partner from partner candidate collection , is proposed to describe the designer’s partner selection behavior, taking into account designer’s subjective preference and information of objective attributes available in OSC [42]. Meanwhile, the process of OSD collaboration is performed in the form of collaboration task   (c=NT+1, NT +2,…) that represents the collaboration request from designer (i=1,2,…, NA). NT, NA, and represent the number of module tasks, designers, and partner candidates, respectively.

(1) The Function of Designer’s Subjective Preference. According to related research on preference [43], designer’s preference is an important indicator for partner selection and quantified by collaboration record between designers. In OSC, collaboration record is represented by the number of collaboration times between designers. The function of designer’s subjective preference is designed as follows:

: Total number of collaboration times between and ;

: The familiarity degree between and of nth collaboration, ;

: The satisfaction degree between and of nth collaboration, ;

: The function of memory attenuation, which represents the memory of satisfaction degree in nth collaboration, shown as exponential decay curve with the passage of time;

: Control coefficient;

: The weight of familiarity degree between and of nth collaboration, .

Therefore, the function of designer’s subjective preference is modified as follows:

(2) The Function of Objective Attributes for Partner Selection. In addition to subjective preference, the designer also takes into account objective attributes for partner selection such as the information of designer’s skill level and experience level which are obtained from OSC [44]. Based on different perspectives of partner selection, two functions of objective attributes are proposed respectively. In first function, the matching degree between designers is calculated for designer who tends to select the partner with similar abilities; in second function, comprehensive ability is calculated for designer who tends to select the partner with high abilities.

Correspondingly, some assumptions are proposed as follows: (h=1,2,…, ) denotes the set of skill types of , in which represents the number of skill types, h indicates hth skill item and (h) is a 0-1 variable (1 indicates that masters this skill item and 0 means not); represents the value of the designer in this skill item; represents experience level of .

(1) The Matching Degree between Designers. According to this way, designer tends to select partners with similar characteristics and believes there are high tacit understanding and work efficiency between them in collaboration process. The matching degree between and is calculated as follows:

/: The two parameters, respectively, represent the skill matching degree and the experience matching degree between and ;

/: The two parameters denotes weights, .

The function of the skill matching degree is as follows:

=((1), (2),…, (h),…): represents skill demand vector of collaboration task , and (h) represents the skill item, which is 0-1 variable (1 indicates that the skill is required for , and 0 indicates not);

=((1), (2),…, (h),…): represents skill attribute vector of , and (h) represents the skill item, which is 0-1 variable (1 indicates that masters the skill, and 0 indicates not);

: The number of skill items, ;

: The two parameters indicate skill values of and in item , respectively;

: Total number of skill items required for ;

The function of the experience matching degree is as follows:

: The parameters, respectively, represent experience levels of and .

Therefore, the matching degree of objective attributes between and is modified as follows:

(2) The Function of the Comprehensive Ability. According to this way, designer tends to select partners with high levels and believes the collaboration is completed with high quality and short time. The comprehensive ability is calculated as follows:

: The relative value of ’s skills compared to ’s;

: The relative value of ’s experience compared to ’s.

The function of is calculated as follows:

The function of is calculated as follows:

Therefore, the function calculating the relative comprehensive ability of compared to is modified as follows:

(3) The Function of Partner Selection . In combination with subjective preference and objective attributes, the designer can select appropriate partner to complete the collaboration. According to aforementioned methods of partner selection in consideration of objective attributes, there are two ways of functions for partner selection as follows:(1)The Function of Partner Selection Including Preference and Matching Degree. Based on the subjective preference and matching degree of objective attributes between designers, the function of partner selection is designed as follows:: The two coefficients denote the weight of preference and matching degree, =1.The utility function on how to select optimal partner is as follows:(2)The Function of Partner Selection Including Preference and Comprehensive Ability. Based on the subjective preference and comprehensive ability of objective attributes of designer , the function of partner selection is designed as follows:: The two coefficients denote the weights of preference and comprehensive ability, =1.The utility function on how to select optimal partner is as follows:

4.2. Utility Function of Collaboration Response

After selection phase, sends collaboration request/task to , waiting for response of . Correspondingly, decides whether to accept , allowing for various factors, such as his working status (busy/free), the recognition to , and the expectation to collaboration outcome of . If receives more than one collaboration requests simultaneously, he at most accepts no more than one request at the same time and hence needs to select the best one from candidate requests. In this section, a utility function of collaboration response is proposed as follows:

: The utility of in regard to collaboration request/task by ;

: The lower limit of the utility value, which is set to 0 in this paper;

: The utility represents ’s recognition degree to , which is calculated by formula (11) or (13);

μ: The coefficient denotes the weight of recognition degree, , which is set to 0.5 in this paper;

s: The state factor of , which is 0-1 variable, ;

injk: The expectation to collaboration outcome of , ;

: The reward by completing ;

: The cumulative reward of .

In offline collaboration, is performed by the partner alone, can determine when to execute without state constraints, and hence is set to 1. In online collaboration, is performed by and together simultaneously, the collaboration cannot be executed if the working state of is busy, and hence working state directly restricts response result. Therefore, parameter is proposed in formula (15) to represent the working state of , which is a 0-1 variable (0 denotes busy, and 1 is free).

5. Case Study

5.1. Simulation Experiment Design

In authors’ previous research, a multiagent simulation system of open source design process oriented to designer’s behaviors is developed, in which the designer is defined as the agent with autonomy, collaboration, sociality, and various design behaviors by VC++ 6.0 [41, 45]. Based on the previous research, the designer’s collaboration behaviors including collaborative behaviors are embedded into the simulation system, by which simulation experiment is designed to study designer’s two-phase collaborative behaviors in OSD process.

5.1.1. The Evolution of Module Task

In OSD process, the product project is divided into multiple module tasks [8], each of which is selected and developed by multiple agents autonomously. Correspondingly, the designer agents of OSC who perform the tasks in OSD process are from different business with features such as high uncertainty and mobility and various levels of knowledge and skills. As a result, there are probably various outcome versions with different quality and evolution time while the agents perform the same task [9]. To describe task’s evolution process performed by different agents, the evolution speed of task performed by at time is calculated as follows:

is the initial evolution speed of , generated by random function in simulation, ;

Θ is speed factor of Tk’s evolution performed by , which is calculated according to the matching degree of knowledge and skills between and , θ∈(0,1).

Product evolution is an important output of open source software design and an important index for measuring design performance [12]. In combination with formula (16) and related research [39], the evolution degree T_(t) of task which is performed by at time is proposed as follows:

T_: T_, T_=1 indicating is completed by ;

is the time when is published to OSC, also known as the trigger time;

is the initial evolution of , which is set based on task’s difficulty, complexity, and relevance to other tasks, [8, 9, 46].

5.1.2. Simulation Experiment Setting

The simulation experiment is designed based an open source project design of mobile phone [47]. In this open source project, mobile phone consists of several components, such as front cover, back cover, main board, keyboard, battery, screen, handset, microphone, antenna, wi-fi, and camera, which are relatively independent and interconnected. For example, the function design of front cover, back cover, and the screen is relatively independent, but they are related in assembly process because of the compatibility requirement. Accordingly, in the simulation experiment the project of OSD is composed of 20 module tasks and the product development flow as well as task relationship is as shown in Figure 2. In Figure 2, Task denotes module task, which is denoted by (i=0,1,2,…,19); during OSD process, if collaboration occurs, the collaboration request is packaged into collaboration task which is denoted by (i>19); module tasks and collaboration tasks can be selected and performed by multiple agents autonomously; Info represents the relationship between tasks related by links. In combination with the experiment and multiagent simulation system, the impact of collaborative behaviors including partner selection and response on structure evolution of OSC as well as product evolution in OSD process is analyzed.

Furthermore, based on the two-phase collaborative behavior model, 4 comparison experiments (Scenario 1 (S1), Scenario 2 (S2), Scenario 3 (S3), and Scenario 4 (S4)) are designed corresponding to different factors of subjective preference (collaboration records) and objective attributes (matching degree or comprehensive ability), respectively, as shown in Table 1.

According to the experiment settings, each scenario is simulated 50 times, getting 200 data samples recording the information on collaboration behaviors of agents and product evolution in OSD process, and following comparison analysis is conducted based on the data.

5.2. Analysis of Structure Evolution of OSC and Individual Collaborative Behaviors

The evolution process of collaboration between designers in OSC and individual collaboration behaviors are analyzed based on a set of sample selected from 200 samples randomly. In the simulation, OSD process ends after 213 simulation steps. As shown in Figure 3, the line chart represents the cumulative number of designers of OSC who collaborate during OSD process at each simulation step. The vertical axis denotes the number of collaboration participants of OSC, and the horizontal axis denotes simulation time. Meanwhile, the 4 social network diagrams, in which the node denotes the designer and the link denotes collaboration relation between designers, respectively, show the collaboration relations between designers of OSC at simulation steps 50, 100, 150, and 200. By comparison, with the evolution of OSD process, designers collaborate with each other more and more frequently, relations between designers are much closer, and OSC evolves continuously.

Moreover, individual collaboration process including partner selection and collaboration response is analyzed based on a set of designer agent’s (A60) data abstracted from the simulation sample. The Gantt charts as shown in Figures 4 and 5 represent designer’s two-phase collaborative behaviors respectively in OSD process. In Figures 4 and 5, the vertical axis denotes agent ID, the horizontal axis denotes simulation time, the blue block denotes online collaboration process, and gray block denotes offline collaboration process. In Figure 4, the Gantt chart represents the behaviors of partner selection while A60 participates in collaboration in OSD process. During the whole process, A60 selects partners and sends collaboration requests/tasks (T44 and T249) for online collaboration 2 times, getting response and completing collaboration tasks. Besides, A60 selects partners and sends collaboration requests/tasks (T85, T117 and T203) for offline collaboration 3 times. Correspondingly, there are 9, 14, and 20 agents, respectively, responding and completing collaboration tasks.

In Figure 5, the Gantt chart represents the behaviors of collaboration response while A60 participates in collaboration in OSD process, and the line chart indicates the order of responses by A60. During the whole process, A60 responds to and completes 25 collaboration requests/tasks, 7 for online collaboration (T121, T145, T278, T298, T331, T359, and T458), and 18 for offline collaboration (T53, T156, T160, T134, T182, T16 9, T184, T191, T128, T226, T223, T228, T356, T343, T342, T380, T366, and T401). Besides, the vertical axis represents agents who send collaboration requests/tasks as shown in corresponding blocks of Gantt chart.

The analysis testifies that the two-phase collaborative behavior model is applicable to elaborately describe the structure evolution of OSC and individual collaboration behaviors in OSD process. Firstly, the evolution process of OSC collaboration as well as the structure of collaboration relations between designers in OSC is revealed from macro perspective based on the model. Secondly, the model describes individual’s collaboration behaviors including partner selection and collaboration response, as well as two collaboration ways from micro perspective. Therefore, the two-phase collaborative behavior model provides a novel point on collaboration research of OSD process.

5.3. Comparison Analysis of Collaborative Behaviors

In this section, based on the two-phase collaborative behavior model, 4 scenarios (S1, S2, S3, and S4) are simulated to study the influence of collaboration behaviors on OSD process. In simulation analysis, the data of product evolution time are extracted from the 200 simulation samples to study if the changes in subjective preferences and objective attributes in partner selection impact the evolution time of OSD. S1, S2, S3, and S4 represent 4 ways of partner selection which are different in subjective preferences and objective attributes. According to simulation data of 4 scenarios, the two-way ANOVA (analysis of variance) is applied to solve this problem. The factors of each scenario are as shown in Table 2.

Hypothesis. (1) The hypothesis of subjective preference (collaboration record) is as follows:

: (subjective preference has no significant impact on evolution time of OSD).

: (subjective preference has significant impact on evolution time of OSD).

(2) The hypothesis of objective attribute is as follows:

: (objective attribute has no significant impact on evolution time of OSD).

: (objective attribute has significant impact on evolution time of OSD).

The two-way ANOVA is carried out with SPSS based on the data of OSD evolution time of 4 scenarios, as shown in Table 3. The results show that both subjective preference and objective attribute have significant impact on evolution time of OSD. Furthermore, the evolution time in consideration of collaboration record is obviously longer than that not considered; the evolution time in consideration of comprehensive ability is obviously longer than the time in consideration of matching degree. This testifies that designer’s collaboration behavior has important impact on OSD process. Moreover, in partner selection of actual OSD collaboration, the analysis suggests that it is necessary to pay more attention to the matching degree between designers but less to collaboration record so as to shorten the evolution time of OSD.

Meanwhile, 4 groups of data regarding to collaboration relations between designers, corresponding to S1, S2, S3, and S4, respectively, are extracted to study the impact of collaboration behaviors on community evolution of OSC by social network analysis (SNA) [48], as shown in Figures 6 and 7.

As shown in Figure 6, compared to social network diagrams of S3 and S4 considering collaboration records in partner selection, the distribution of collaboration relations in diagrams of S1 and S2, in which collaboration record is not considered in partner selection, is more widespread. This is because there are more candidates in partner selection without consideration of collaboration records. Besides, compared to social network diagrams of S1 and S3 considering matching degree between designers in partner selection, the distribution of collaboration relations in diagrams of S2 and S4, in which comprehensive ability of partner candidate is considered, is more intensive. This is because designers who select partners considering the factor of comprehensive ability usually send collaboration requests to the same partners with high ability, showing the intensive distribution of social network diagrams.

As shown in Figure 7, comparing the collaboration relationship of social network diagrams considering collaboration records (S3 and S4) and that without consideration (S1 and S2), the average degree of S1 is lower than that of S3 and the number of cliques is opposite. Meanwhile, the comparison is the same with S2 and S4. The average degree reflects collaboration frequency of OSC; the higher the average degree, the more frequent the collaboration. The number of cliques reflects collaboration distribution of OSC; the greater the number of cliques, the more widespread the collaboration distribution. Besides, comparing the collaboration relationship of social network diagrams considering matching degree between designers (S1 and S3) and that considering comprehensive ability (S2 and S4), both the average degree and clique number of S1 are lower than that of S2, and the comparison is the same with S3 and S4.

Based on aforementioned social network analysis as shown in Figures 6 and 7, the range of partner candidates is more dispersed when the designer selects partners without considering collaboration record in OSD process; conversely, collaboration relations are concentrated on the designers with collaboration records, resulting in work imbalance of OSC, which in turn delays the evolution process of OSD. Moreover, the range of partner candidates is much wider when the designer selects partners considering the matching degree between designers. On the contrary, collaboration relations are concentrated on the designers with high comprehensive ability, resulting in much waiting time for collaboration, which in turn delays the evolution process of OSD. Therefore, the comparison results show that the factor matching degree between designers should be considered while collaboration records ignored in partner selection. In this way, the interaction range of designers in OSC is more distributed, which advances the product development process.

6. Conclusions

As an emerging mode of collaborative product development, OSD is driven by numerous self-organized volunteer designers. It is a key issue on how to make full use of such great potential human resources of OSC to contribute to product evolution of OSD. During OSD process, collaboration between designers frequently occurs and directly influences the quality of OSD outcomes as well as evolution time. In this paper, a two-phase collaborative behavior model including partner selection and collaboration response is proposed to study the impact of designers’ collaborative behaviors on the evolution process of OSD as well as OSC structure. In the two-phase model, two utility functions are designed for selection and response of collaboration respectively to quantify the collaboration process. The simulation results testify that the model and shows that the two-phase collaborative behavior model can describe the evolution process of OSC structure by collaboration from macro perspective and designers’ collaboration process including partner selection and collaboration response from micro perspective. Besides, different ways of partner selection behaviors have significant impact on the evolution of OSD process as well as OSC structure. Furthermore, the results suggest that designers should better consider more the factor of matching degree between designers but less collaboration record. Compared to the current references, the improvements of this paper are as follows:

(1) Collaboration process of OSD is studied based on the two-phase collaborative behavior model in which collaboration behavior is divided into partner selection and collaboration response, and the analysis by multiagent simulation can provide auxiliary decision on collaboration mechanism design in OSD process to make full use of human resources of OSC.

(2) The two-phase collaborative behavior model explains the evolution of OSC structure from macro perspective and designers’ collaboration behaviors from micro perspective, which provides a novel point on the research of bottom-up and self-organized structure of OSC as well as individual autonomous contribution to OSD.

(3) In the two-phase collaborative behavior model, both subjective and objective factors are taken into account in partner selection, which proves to have significant impact on OSD process. This can provide designer good advice on factor choice in partner selection by multiagent simulation.

Although the two-phase collaborative behavior model is proved effective in the research on OSD collaboration by multiagent simulation, there is more work to improve the model as well as simulation input. For example, more factors should be added to the collaboration model, such as designers’ preference on task type, and contribution reliability. Besides, the simulation input is based on a single project, which is easier compared to multiple projects of actual OSD. Therefore, the future work will focus on the improvement of collaboration model as well as multiproject simulation study of OSD. Furthermore, more behaviors in OSD will be studied such as version screening behavior, which is critical to the quality of OSD outcome, to make open source project in effective evolution.

Data Availability

In the article, 4 scenarios are designed in the simulation experiment, in which each scenario is simulated 50 times, getting totally 200 groups of data samples. First, to study the evolution of OSC (open source community) and individual designer’s collaborative behaviors, a group of data is selected, in which the data of collaboration numbers of OSC are processed to study OSC evolution and data of collaboration of OSC are processed for social network analysis and the data of designer A60 is processed to study individual’s collaborative behaviors. Second, to study different collaborative behaviors’ impact on OSD (open source design) evolution, the data of simulation time are extracted from the 200 groups of data samples, which are processed for two-way ANOVA. At last, there are large volumes of data which are outputted in simulation, such as each task’s evolution degree in each simulation step and each designer’s behaviors of task selection and task execution, which are unavailable to the study of this manuscript. Therefore, these data are not released.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.

Authors’ Contributions

Contributions of Shuo Zhang and Yingzi Li are equal.

Acknowledgments

This work is based on research work supported by the National Natural Science Foundation of China (nos. 71601078 and 51507061); Social Science Funds of Beijing (nos. 16GLC070 and 18GLC061); Humanities and Social Sciences of Education Ministry in China (no. 16YJC630060); and the Fundamental Research Funds for the Central Universities (nos. 2016MS72 and 2018ZD13).