A Sociotechnical Negotiation Mechanism to Support Component Markets in Software Ecosystems

Organizations have opened up their software platforms and reusable assets to others, including partners and third-party developers around the world, creating software ecosystems (SECOs). This perspective can contribute to minimize nontechnical barriers of software reuse in industry because it explores potential benefits from the relations among companies and stakeholders. An inhibitor is the complexity in defining value for reusable assets in a scenario where producers try to meet customers’ expectations, and vice-versa. In this paper, we present a value-based mechanism to support component negotiation and socialization processes in a reuse repository in the SECO context as an extension of the Brechó-EcoSys environment. Social resources were integrated into the mechanism in order to aid component negotiation. An evaluation of the negotiation mechanism was initially performed based on an analysis of its elements and functions against critical factors in the negotiation within a SECO, identified in a previous systematic literature review. In addition, an analysis of the social resources supporting the negotiation mechanism was performed against popular sociotechnical elements for SECOs, identified in a previous survey with experts in the field. Finally, the negotiation process and the potential support provided by sociotechnical resources were investigated through an observational study where participants were engaged in some tasks playing as consumer and producers using the sociotechnical negotiation mechanism at Brechó-EcoSys environment. We concluded that sociotechnical resources (e.g., forum and tag cloud) support component producers and consumers with useful information from the SECO community.


Background
SECOs represent a new perspective in the SE field due to their rapid evolution in the last decade, even though Business Schools performed the first researches in this topic in the 90's as "business ecosystems" [23]. Santos & Werner [24] define SECO as sociotechnical networks for developing software products and services that are composed by technical, transactional and social elements. Such elements relate to each other to the engineering and management of one or more platforms, creating value and innovation in software industry. SECOs studies in the Software Reuse community were initially motivated by the SPLs approach aiming at allowing external developers to contribute to hitherto closed repositories through a global software development [10] [25]. Research directions in literature and industrial cases reinforce some SECO perspectives, e.g., architecture, management, mobile, social networks, modeling, business, and a multidisciplinary study.
Another motivation of studies about SECOs was related to the software vendors' routine since they no longer function as independent units that can deliver separate products, but have become dependent on components and infrastructures provided by others (i.e., operating systems, libraries, component stores, and platforms) [26]. It means that software vendors resort to virtual integration through alliances to create and keep networks of influence and interoperability, creating SECOs. Some challenges are emerging in this scenario [27]: (i) software vendors have to be aware of SECOs in a global software development; (ii) they also want to be aware of survival strategies adopted by stakeholders within the SECOs; and (iii) they need to know possible ways for opening up their platforms but protecting intellectual property.
Since SECO community looks at software artifacts and technical repositories as a combination of business, social and technical elements, the platform and its interactions result from both technical and social networks. Networks represent mappings of elements and relationships. The network that emerges from interactions among SECOs elements is known as a sociotechnical network [24]. Improvements on the social perspective of software platforms come to the surface in order to create other features and functionalities to support SECO sustainability and diversity [28].
As such, a SECO can be seen as a set of actors working as a unit and interacting with a market of software and services along with relationships among these entities [27]. These relationships are supported by a common technological platform on which actors exchange artifacts and information. The sociotechnical network emerges from SECOs due to intense flow of resources among actors (social network) and artifacts (technical network). As a technical network lacks information on the actors' relationships, the social mechanisms then aim at stimulating actors to interact and communicate. For instance, in SECOs supported by none or few social mechanisms, a software vendor has little access to resources and information (e.g., sales history) to publish news artifacts. Once social mechanisms are incorporated in the platform, vendors can interact with each another. This type of relation generates new information like requirement suggestions and price negotiations [29].
Therefore, it is important to study a SECO as composed of a software platform, a network of actors (stakeholders) and network of artifacts and devices (e.g., reuse repository) [30]. A few types of software artifacts are seen in SECOs, such as software components, applications, services, and requirements [18]. Focusing on those artifacts and the roles of 'producer' and 'consumer' performed by companies, communities or developers, there are many possible relationships to explore. Since repositories are built upon technical interactions (e.g., buying, selling, versioning etc.), social aspects of SECO relationships still require additional investigation in SE [5].

Negotiation
Negotiation can be defined as a process in which two or more parties exchange information and take decisions aiming at achieving an agreement on the exchange of goods and services [31]. Some negotiation states are [12]: (i) prenegotiation, when information is gathered and problems are realized, i.e., interlocutors, interests of the parties, strategies and alternatives to the negotiated agreement; (ii) conduction of negotiations, when arguments, messaging, offers and counter offers are exchanged to hold positions and proposals between the parties before the agreement; and (iii) post negotiation, when the commitments are established by the parties, including the evaluation of interactions.
Three concepts are important in a negotiation [32] [33]:  Reservation Price (RP) is the last satisfactory point to which a party accepts the agreement, i.e., the limit value a buyer (seller) will pay for (agree with) goods;  Zone Of Possible Agreement (ZOPA) is an area that satisfies both parties involved in a negotiation, and then an agreement can be reached;  Best Alternative to a Negotiated Agreement (BATNA) corresponds to the fact that all negotiations should have an alternative, just in case the agreement is not reached [34]. The better it is, the more power a party has to negotiate, increasing even the chances of improving an agreement.
Finally, the negotiation process can be divided into four steps [32]: (1) preparation, where negotiators define BATNA and ZOPA, try to improve the relationship and make their positions; (2) value creation, where the parties should explore the interests of others, creating alternatives to increase mutual gains; (3) value division, when different sharing forms are discussed, including standards and criteria; and (4) execution, where the arrangements for monitoring and verification of the decisions are established. After the last step, the negotiators work continuously to improve their relationship and to fairly resolve their differences [35].

Component Repository
A component repository is defined as a base to store and retrieve software artifacts in the context of a strategic reuse program [36]. The effectiveness of search and retrieval mechanisms depends on the additional information collected during the storage and documentation [3]. For example, the easiness to locate and retrieve components implies in promoting reuse of components instead of developing them from scratch. Additionally, components' functionalities should be documented so as the repository is able to help stakeholders to search, retrieve, acquire, and integrate them towards increasing productivity in software development. As such, reuse process support is required, e.g., specification visualization, comprehension, adaptation, testing, deployment, change, evolution, and quality management [4] [37].
Large-scale repositories have historically failed, mainly because they have been implemented as centralized systems, disregarding good results with domain-specific and reference repositories [2]. Distributed, heterogeneous repositories have contributed to the growth of reference repositories, such as the current "fever" of application stores in mobile computing and ecosystems [38]. In any type of repository, the component publication data should be carefully modeled to reach appropriate and effective retrieval and reuse. Producers, consumers, and repository managers are common actors in a component repository environment [5]. Their relationships contribute with useful information for measuring reuse success and helping to understand the notion of value. Therefore, a repository must collect and analyze sociotechnical network data, and it is common in the ecosystem context [39]. A key factor is component documentation since it is essential to establish and operate repositories [29].

Related Work
Related work was found in component repository literature, but without an explicit negotiation and/or socialization approach. Brereton et al. [19] developed an infrastructure to support a component marketplace, named CLARiFi. It distinguishes three roles (supplier, integrator and broker) and focuses on search and retrieval activities. CLARiFi lacks support to component negotiation and value-based resources. Overhage and Thomas [9] propose a marketplace model for trading components based upon economic theory of perfect markets, named CompoNex. Despite the strategy to match supply-demand, different facets of value were not analyzed. Finally, ComponentSource [21] is a real component marketplace based on commercial mechanisms to attract producers and consumers. It explores marketing strategies to sustain a web store but it lacks negotiation and socialization mechanisms to help stakeholders to interact and trade. Finally, Lima et al. [22] stated that the structure of a SECO is better understood through the definition of its elements, e.g., actors, assets, platforms, and relationships. Using a sociotechnical network approach, basic mechanisms were initially proposed to support SECO analyses from an asset repository. The evaluation of social resources relevant to real SECOs allowed identifying which ones should be included in the technical network originated from the repository. The current work focuses on the implementation of such resources as an extension of Brechó-EcoSys, exploring negotiation as a sociotechnical mechanism not covered before, as well as evaluating them with an observational study.
On the other hand, negotiation systems have been investigated in the Decision Making field, where the main objectives are [12] [47]: offering a learning environment; allowing asynchronous negotiations; offering advices; making checklists; reducing cost of transaction; providing justification for negotiation positions; structuring offers; generating negotiation data; and defining negotiation or protocol processing. Some negotiation support systems exist around the world, such as Inspire, SimpleNS, WebNS, and SmartSettle. SimpleNS is the only one that provides negotiation beyond the traditional negotiation table. None of them treats 'value' by combining economic and social aspects as in the Brechó-EcoSys.
This work is part of the Brechó Project [8]. It involves the development of Brechó Repository, a Web information system that provides documentation, storage, publishing, search, and retrieval mechanisms for reusing components and services, including a database with producers and consumers (version 1.0) [8]. Brechó considers a component as any reusable asset produced throughout the component lifecycle (e.g., models, code, binary etc.). The goal is to store all artifacts produced after providing the following information: hierarchical categories they belong to, documentation required from customizable templates, and their dependency tree. For search, there are keyword and category mechanisms with filters based on documentation and synonyms. For retrieval, Brechó uses the concept of purchase cart as in the e-commerce domain. Brechó also provides strategies for publishing external web services, hosted internal services generated from published components, and hosted composite services [40].
This repository was evolved to support a sociotechnical network, where reuse processes are directly related to a platform established over a common product architecture, a community, and business strategies and tactics [11] [28] [41]. Therefore, Brechó was evolved from an "implementation of a reuse repository" to an "implementation of a valueand ecosystem-based reuse infrastructure", named Brechó-EcoSys [16]. It consists of an evolution of Brechó 1.0 with business and social mechanisms incorporated by Brechó-VCM (Value-based Component Market in Brechó) [7]. From such reuse environment, this section presents a value-based mechanism to support the preparation of a component negotiation driven by social and business aspects of reuse. As discussed in Section 2, the preparation step in a negotiation process is the most important part since information is collected aiming at facilitating the agreement by identifying the interests of all parties [42]. Each negotiation requires data from the whole process of communication and consists of one to any number of proposals, considering the order of income and exploring steps 1, 2 and 3 (pre-negotiation), as explained in Section 2.
This process also involves two SECO actors, a producer and a consumer, respectively the component owner and the stakeholder interested in obtaining it. Proposals can be made by both actors (conduction of negotiations), and are composed of a value proposition (i.e., suggested price) and a textual explanation (i.e., other facets of value). After the negotiation process is concluded, successfully or not (step 4), each actor has the right to evaluate those actors who he/she interacts with. This information is stored in the repository database, consisting of a "1 to 5" rate and, optionally, of textual comments (post negotiation). Figure 1 shows this process.
Based on the SECOs challenges presented in Section 2, the negotiation mechanism (1) tries to put the stakeholders in contact, aiming to maximize the realization of the facet of value risks in Internet-based markets and reuse repositories, propitiating RP [29], and (2) explores the facet of value flexibilities when it contributes to trade customizations, propitiating BATNA and ZOPA [2]. This mechanism considers different perspectives (consumers and producers) involved in a value chain instance (negotiation invitation, and negotiation analysis and trade customization activities, respectively) of a component marketplace.
Moreover, this mechanism uses a conceptual element (negotiation history) to explore the stakeholders' profiles through our model (Discussion-Based Negotiation Model) which was inspired on (i) value-based decision theory (for ZOPA): how stakeholders' values determine decisions in negotiating win-win plans towards a balanced value realization; and (ii) stakeholder value proposition elicitation and reconciliation (for BATNA): identify and treat clashes using expectation management, visualization, trade-off-analysis techniques, prioritization, and groupware [13]. The mechanism model leads to two contexts: producer profile, visible for stakeholders who act as consumers, and consumer profile, visible for stakeholders who act as producers. Both profiles have SECO-based information regarding the mechanism's interface with other mechanisms in Brechó-VCM. This information comprises: (i) reputation, previous textual evaluations and related responses, based on an evaluation mechanism [7]; (ii) previous acquisition contracts, based on a pricing mechanism (for RP) [7]; and (iii) statistics related to percentage of successful negotiation and number of negotiation invitations, i.e., filtering to show only possible and useful information for the stakeholder and his/her specific profile (considering the market as well as a specific producer-consumer interaction).
A consumer can negotiate a trade immediately before acquiring a component, then putting it in a purchase cart ("My Cart", in Figure 2), if the producer previously enables it for negotiation in the SECO (see 10th column in "Listing my components", in Figure 3). This corresponds to the preparation phase. In this moment, the consumer can see the component's evaluations and check the producer's profile within a SECO ( Figure 4). It aims to make the producer's earned value (e.g., the brand) more visible for consumers in a value creation phase. As a result of the value realization, the consumer can start a negotiation process, describing the reasonsexploring facets of value costs, needs, and flexibilitiesand waiting for a future notification in the BATNA area ( Figure 2).

Figure 3:
Negotiation mechanism in a producer's view. Source: [43] The producer will be notified through a "mark" in his/her components and can check the negotiation requests, as presented in Figure 3. He/she can see the consumer's profile and choose one out of three options (value division phase): accept, renegotiate (new proposal), or deny. In the first case (ZOPA), the producer changes the value of his/her component directly in the consumer's purchase cart and waits for the consumer appreciation in "Negotiation Details", as observed in Figure 2. In the second case (BATNA), the producer checks the negotiation process aiming at discussing with the consumer. This action can create an interactive cycle towards one of the other cases, as shown in "Negotiation Details" (Figure 3).
Finally, in the third case (RP), the producer rejects the offer without an extra discussion, and the consumer is notified. This communication process allows the interactive cycle (execution phase) towards an agreement that can happen in the first case (successful), or the consumer gives up on this process (unsuccessful).
At the end, the consumer can download the asset and evaluate the negotiation (option "evaluate" at the 9th column of the "Negotiation Items" table in "My Cart", in Figure 2), or delete it from the list, using "X" icon. In any situation, the consumer can evaluate the negotiation (post negotiation). Similarly, the producer can evaluate the experience, aiming at balancing the SECO perspectives, i.e., production and consumption. Both evaluations will be registered in the respective stakeholder's profile to be used by other mechanisms at the Brechó-EcoSys environment, e.g., evaluation mechanism, to calculate the credibility degree based on reputation and experience [7].

Improving Social Aspects of the Negotiation Mechanism
Negotiation is an inherent human process being an important activity in the SECO context [14]. The negotiation mechanism presented in Section 3 treats not only people involved in an interactive process, but also components (artifacts), creating a sociotechnical network. The decision of a participant to enroll in this kind of interaction relies on the stakeholders' perceptions and on that information provided by the SECO about the component to be negotiated. This issue was not handled in Brechó-EcoSys so far.
Based on the work of Seichter et al. [44] regarding the social networks in SECOs, we identify some social resources as solutions for the problem of providing component information as well as a channel for stakeholders to communicate with: profile, forums, requirements coordination support, evaluation system, teams, tag clouds, and news feed. These resources can help producers and consumers to be aware of SECO trends, and discussions would be of great value for the negotiation process. The extension of the negotiation mechanism at Brechó-EcoSys to comprise such social resources was named as sociotechnical negotiation mechanism. All the resources and functions related to the sociotechnical network implemented at Brechó-EcoSys are joint at the "My Network" panel, as shown in Figure 5.
The resource forum implemented in Brechó-EcoSys is organized in three sections, as presented in Figure 6 (first column). The first section is used for general discussion, organized by "topics". These topics are theme-free, i.e., consumers can talk to producers about a component function, ask for help, report a bug etc. This section allows a potential consumer of a component to communicate with others before starting a negotiation with a producer, for example. Also, one can infer how active the community is and how many errors have been reported so far. Thus, the forum is an important source of information for negotiators since it contributes to the value realization [44].
The second section intends to gather "suggestions" from the community, as shown in Figure 7. Anyone who is a member of a forum can contribute with suggestions for new component functions. A component producer (forum administrator) is responsible for managing such suggestions. Finally, the third section allows the producer to register "requirements" for the component, as illustrated in Figure 8. The producer registers these requirements, or he/she can select a suggestion from the second section and make it into a requirement.    Producers and consumers can "follow" a requirement, triggering suggestions and news feed updates. Therefore, this resource works as a strategy for requirements coordination support [14] since it involves the SECO community, existing discussions, and suggested functions. In addition, every message in a topic (as well as suggestions) is subjected to an evaluation system [15]. An actor can vote for positive (+1) or negative (-1) regarding his/her opinion for each message, as shown in Figure 8. An actor can collect points for registering a suggestion that has received many positive votes, including those points joint after performing negotiation evaluations, as explained in Section 3. These points are used to acquire components, or even to boost a producers' component exhibition at the repository's initial page.
Considering the evaluation system, producers can better understand the relevance of components' needs registered by consumers, as well as all the demands emerging from the consumers' community. Therefore, this extra information allows producers to make better decisions on the next releases and functions to be added into a componentand how to negotiate them. With the first three social resources, consumers already have much more information about the component before buying or negotiating it, not only relying on the producer's word, but on the 'word of mouth'.
Furthermore, actors can create teams and add other actors [6]. Different types of team can be created, e.g., Android's producer team, a specific software project team, a service's consumer team etc. Teams are represented as a type of user, which means that they keep a repository's profile. They can produce and/or acquire components, publish in forums and negotiate components on behalf of the team. Every team has administrators and members, and it may have a forum associated with it. The team administrator can manage the members, as shown in Figure 9 (A). Figure 9 (B) shows "Team" page with related information, e.g., description, members and actions (modify member's privileges, modify member's view of a team, leave team, and delete team). Options for managing members and deleting a team are only available to administrators.
(A) (B) Additional resources were implemented to provide actors with SECO information in order to improve negotiation activities, as shown in Figure 5. For example, my profile area shows the proportion of actions an actor performed within the SECO, being a producer, a consumer, or a simple user. This proportion is calculated according to the actions performed at Brechó-EcoSys, such as publishing, acquiring or downloading. In turn, the tag clouds area improves the way new trends and popular information are visualized in the repository, affecting component negotiation strategies. It is a direct summarization of what is being discussed and developed by the SECO's community. The tag cloud is a data mining function that uses as input forums' discussions, suggestions and requirements, as well as teams' descriptions.
The suggestion area comprises suggestions that the repository gives to an actor. It is based on the forums he/she participates, as well as the profiles and requirements he/she follows. Suggestions refer to candidate teams, interesting forums, and components of interest. In addition, the news feed area was implemented in Brechó-EcoSys. The feed is updated with information about the teams that an actor participates, new releases of components a consumer already acquired, component recommendations etc. It aims to bring new information to an actor, motivating him/her to keep updated and search for further information.
As observed, producers and consumers are the main types of actors in a SECO supported by reuse-based repositories. To face the social barriers, SECO leverage the importance of groups of actors pursuing a common goal. From the team resource, actors can send requests for developing solutions to existing requirements and play the role of producers. The requirement owner (component producer) has to accept it in order to allow those producers to publish their solutions as extensions of a given component. Extensions correspond to a new type of artifact published at Brechó-EcoSys, i.e., they are components linked to others that are published as solutions to requirements made public.
Finally, at the main page of Brechó-EcoSys, options for allowing producers and consumers to manage the requirements they are related to were incorporated, as shown in Figure 10. "My requirements" table helps an actor to manage and monitor requirements he/she manifested interest in, i.e., marked as 'following' in a forum (first box in Figure 10). There are options for managing the following resource: to know if the requirement is being developed or not, and to publish an extension for the component that is related to the requirement. There is also a panel to manage the requirements an actor administrate, i.e., the requirements belonging to forums he/she is the owner (second box in Figure 10). For those requirements, the actor can discontinue a requirement, i.e., closing it for anyone's request to develop. Since the 'developing' option consists of a request to the actor that owns the requirements (producer), there is also a panel for managing development solicitations (third box in Figure 10).

Cross-check Evaluation
An evaluation of the negotiation mechanism was performed at first, based on an analysis of its elements and functions against critical factors in the negotiation within a SECO, identified in a previous systematic literature review [17]. Secondly, an analysis of the social resources supporting the negotiation mechanism was performed against popular sociotechnical elements for SECOs, identified in a previous survey with experts in the field [18].
The first analysis aimed to find out opportunities to enrich the negotiation process. We chose as input the research conducted by Rodrigues et al. [17] due to the fact that a research group whose expertise is on negotiation methods and infrastructures performed this study. Moreover, this study was planned and executed based on a systematic methodology to investigate the existing literature in SE [45]. Therefore, some contribution to the negotiation mechanism evaluation could be collected from this experience. The previous work reinforces the trend of improving negotiation processes in marketplaces using mobile devices [12] [32] [42]. In this sense, a mobile-based environment is a future research direction for the Brechó-EcoSys platform.
From the scientific papers analyzed by Rodrigues et al. [17], 28 critical factors of mobile learning in negotiation approaches in the SECO context were extracted and grouped into 10 categories. For the scope of our evaluation here, we selected 12 business factors that were relevant to negotiation process in the SECO context considering our specific interest, as shown in the third column in Table 1. Based on these factors, the negotiation mechanism' elements and functions presented in Section 3 were analyzed thought a peer review session in order to verify their strong and weak points, as well as opportunities and threats, as shown in Table 2. This study allowed us to conclude that the existing business mechanisms in Brechó-EcoSys require collaboration support since negotiation relates to social resources. It means that the business factors should be treated together with social resources introduced by SECO context, as stated by Bosch [10], Messerschmitt & Szyperski [23], Jansen et al. [27], and Santos & Werner [28]. As such, this result also reinforced our effort to evolve the negotiation mechanism with social resources. Therefore, we decided to perform a second analysis to complement the previous one. The goal was to verify the social resources presented in Section 4. We chose as input the research conducted by Lima et al. [18] because this study involved several researchers and practitioners in SECO, collaborative systems and distributed development. In addition, the study was planned and executed based on a systematic methodology to investigate the experts' opinion in SE [46]. The negotiation mechanism was structured from the negotiation process and key concepts, as explained in Section 2 and illustrated in Section 3. Therefore, it considers a real-life-based negotiation process and also has been implemented as part of a digital-based distribution channel (Brechó-EcoSys). Finally, the concept of component is flexible, allowing different software artifacts to be negotiated among producers and consumers within a SECO.

9 17
Currently, it is not possible to dynamically and automatically synchronize data in order to support synchronous negotiation processes since there is no specific decision tree algorithms or even agents implemented at Brechó-EcoSys. This infrastructure was conceived to support an auto regulated environment to explore information visualization and value realization, and to stimulate collective intelligence practices.

11 15
Two main opportunities were identified from this initial evaluation since a negotiation mechanism is both a business element and a social element in SECOs: (i) a component marketplace should be integrated to a social network site to explore social elements, such as interaction, utility, recommendation, promotion, and reputation [32]; and (ii) a mobile-based infrastructure can maximize the value proposition and realization in the SECO context, as concluded by Rodrigues et al [17].

22 26
As a mechanism focused on generating a negotiation process infrastructure in the SECO context and not on the applied artificial intelligence to support it, imprecision and uncertainty may not be solved with a purely communication and value-based environment. For example, different contexts can affect the communication between producers and consumers, and the negotiator profile is not supporting contextual analysis in SECOs.
In the survey executed by Lima et al. [18], a set of several sociotechnical resources for SECO was prioritized. For each resource, a relevance level was assigned based on a 5-point Likert scale. Results showed a ranking of the most acceptable social aspects to be implemented in a repository within the SECO context. For the scope of our evaluation in this paper, the top 12 social resources were selected, i.e., those resources where the sum of experts' 'important' or 'very important' votes got 80% or more. Table 3 shows the resource's ID, name and its relevance for the sociotechnical negotiation mechanism. Although the resources labeled with IDs 1, 2, 5, 8 and 10 are important for many SECO's sociotechnical networks, they have little impact on the negotiation process. Artifact forum provides information coming directly from the community, helping consumers to argue during negotiation rounds. It means that the more information (and from different sources) the negotiator has, the more effective decisions he/she can make in changing or accepting offers. Moreover, decisions regarding dropping the negotiation or waiting for the next release are made easier.
Forum's discussion evaluation helps to prioritize the information in a forum according to the SECO's trends and stakeholder's demands. Environment to report problems also provides the negotiator with more information to realize different facets of value for a component of interest before acquiring it. For instance, when a component's list of problems reported by the community is growing for some time, the negotiator might wait until the component becomes more stable.
Differently from forum's messages, the Message resource aims a direct, synchronous communication among users. It is useful for negotiation activities because it creates a direct and private channel between a producer and a consumer. Additionally, this resource stimulates actors to ask for information without initiating a formal negotiation process. If the team members have to wait for their leader's approval before initiating a negotiation, message is an important resource since the following actions are later evaluated and displayed at the user profile as a reputation.
Frequent questions and Environment to report problems are somehow alike. Both provide information about the component's problems reported by different stakeholders. Frequent questions can be considered as a source of the most popular registered issues. In turn, Demands registering is directly responsible for supporting requirements coordination. A producer can benefit from the community's demands to get a direction for new component functions that add value to it.
Finally, Rewards for member who identifies and evaluates new demands highlights the importance of a loyalty program to incentive SECO actors to be active. In other words, they can prioritize and assess demands, whose evaluations consist of positive or negative votes from forums' discussions, suggestions and requirements. Thus, it complements Forum's discussion evaluation and Demands registering. At the end, we observed that some social resources offer direct support for the negotiation mechanism, making more information that can help negotiators' activities available.

Experimental Evaluation
In order to assess the negotiation process and the potential support provided by sociotechnical resources of the sociotechnical negotiation mechanism at Brechó-EcoSys, a feasibility study was planned and conducted. The participants executed some tasks playing as consumers and producers, simulating a negotiation with a researcher responsible for the study. They also used forum's discussions and tag cloud from Brechó-EcoSys to obtain additional information. Then, they fulfilled a questionnaire for feedback about the negotiation process and the infrastructure.
The hypothesis of this research is that introducing sociotechnical mechanism on the negotiation process improves the negotiator capabilities (both buyer and seller) in the negotiation process. This hypothesis was evaluated by using the Brechó-EcoSys environment in order to answer the following research questions (RQs): RQ1: Do the sociotechnical mechanisms at Brechó-EcoSys help the users in the negotiation process? RQ2: Is the usability of the soctiotechnical mechanisms satisfying the users?

Planning
For this study, ten participants were invited. An online questionnaire was applied with four sections: (1) Informed Consent Form: participant's rights and responsibilities; (2) Characterization Form: participants' background and experience with the study's concepts and similar tools; (3) Execution Form: tasks to be executed with our infrastructure, assuming the role of consumer (the researcher being the producer) and vice versa; and (4) Evaluation Form: a questionnaire for the participant to provide feedback about usability and the execution of negotiation tasks. Participants who were out of Rio de Janeiro (the researchers' city) used a PC remote access software. The invitations to participate in this study were based on a list of students/former students from the System Engineering and Computer Science Department at Federal University of Rio de Janeiro who are/were researching on Software Engineering and Knowledge Management areas. After completing a negotiation round for each role, the following mandatory questions were asked in order to evaluate the negotiation process and the support of sociotechnical resources (forum/tag cloud):  Q1: Were you able to accomplish all the tasks?  Q5: What difficulties did you have?
 Q6: What negotiation resources or information you missed?
The participants had access to a .pdf document illustrating the negotiation process and functionalities used in the study. This document included Brechó-EcoSys' snapshots and a brief indication where to find the functions and resources. Participants could use it at any time during the study execution. Aiming to assess the infrastructure usability regarding the negotiation tasks, the ten Nielsen's heuristics [48] were used. The set of heuristics and respective questions is shown in Table 4. For every question, a scale of 5-point from totally agree to totally disagree was used. The proposed tasks are listed in Table 5. This information was given to the participants within the evaluation form. Every participant was informed about the component to be negotiated. The participants were free to accept, deny, or send new proposals. The study was planned following the script bellow:

Execution
From the set of ten invited participants, seven were able to attend the study's sessions. Four of them executed the tasks remotely. Either physically or remotely, participants did not see the research's actions during the negotiation tasks, so they did not learn from that before changing profile. The study execution happened on November 3rd and 4th, 2016.

Results and Analysis
The participants' academic profile was distributed as follows: Master (Ongoing) = 2; PhD (Ongoing) = 2; PhD = 1; and Post-doc = 2. Figure 11 describes the participant's level of experience with the concepts used in the study. Only Negotiation and Social networks had one participant each with no experience (not the same), the others informed to have theoretical and practical experience, and use in industry (Software engineering, Software artifacts management, Negotiation, and Social networks). Figure 12 presents the experience with the related tools. All participants had some familiarity with the related tools, mainly Collaboration tools and Software artifacts management tools.
Participant's answers regarding the tasks they performed as consumers are presented in Figure 13. None of them said that the Brechó-Ecosys' resources could not be found, or that the tasks could not be performed. The use of forum and tag cloud in the negotiation process as consumer was completely found by 4 participants and partially helpful for 2 participants. Only one participant did not find it helpful (this same who did not found forum and tag cloud useful).
In Table 6, participants' difficulties in performing the consumer's tasks in the negotiation process are listed. The common problem faced by the participants was on how to find some resources that they did not know where they were located, or that they were clickable, e.g., evaluate the negotiation and check negotiation history. Another problem was how to distinguish negotiation evaluation and component evaluation. Those resources were in different tables in the tool (with the corresponding titles), even though they use the same labelwhat might have confused the participants. Table 7 presents comments regarding information or resources that participants missed playing as consumers in the negotiation process supported by tool. Although a set of snapshots was given to the participants, one of them missed a 'getting start' tutorial. Another difficulty was the lack of complete information on the component and its negotiator at the same page.
Extra information on the component as well as on its past negotiations were suggested by the participants, e.g., information from repositories, number of sales per period (e.g., total, a year, a month), average price (including a time chart). The only resource recommended was filters for the forum. Since the forum's topics are free of type, the filters would not have clear options to choose/select. For example, if a filter was an open search field, it would be necessary to search a content that is too general, making the topics of interest hard to find. As such, filters could work better if there was a negotiation section at the forums (or posts) with a specific mark like 'negotiation'.  Even with the tutorial, it was hard to find the forum. P2 It was easy. The forum helped because it had some extra information.

P3
Navigability and orientation in the tool.

P4
Difficulties in executing some negotiation tasks. For example, to seek negotiator profile, counter button and negotiation history. You must know the features of Brechó-EcoSys before using it. What information is available to guide negotiations. It was not so intuitive to find and follow the process continuously , only if the consumer already has knowledge of the product and the price margins for negotiation.

P5
Since I did not know the tool, it took me a while to find the options requested in the tasks, such as where to click to evaluate the negotiation.

P6
Since I was not familiar with the tool, I had difficulty to find the available resources. However, once they were found, they were easy to run.

P4
Information on the negotiation screen about the product; possibility of applying filters in the forums that would lead me to topics relevant to a negotiation; a product history in the trading panel, or direct access through this screen.

P5
The available resources were sufficient. P6 None P7 Number of sales per period (total, this year, this month), average price paid (including time chart).
The majority of participants found helpful to use forum and tag cloud when they played as producers in the negotiation process at Brechó-Ecosys. The sociotechnical negotiation mechanism's resources were found and the tasks were completely performed in most cases. This result might be better because many resources were used at the first part of negotiation (i.e., when participants played as consumers, according with the study procedure).
Participant's answers regarding the tasks they performed as producers are presented in Figure 14. All participants found the Brechó-Ecosys' resources (two of them answered partially). Six participants accomplished all tasks and one answer partially (the same result for the consumer's tasks). The use of forum and tag cloud in the negotiation process as a consumer was positive: 4 participants voted Yes, and 2 voted Partially (the same result for the consumer's tasks).
Participants' difficulties in the negotiation process when they played as producers are presented in Table 8. Some reports were the same as the consumer profile, such as how to locate information and navigability. A concern that raised in the participants' answers referred to clearly inform the producer regarding the consumer's action after the negotiation finishes, i.e., alert if the consumer bought the component or not. This part of the negotiation might have few difficulties because the participants had already used some of the required resources when played as a consumer.
In Table 9, the participants reported information or resources that they missed playing as producers in the negotiation process supported by tool. The participant P2 faced the same difficulty of P5, and they suggested a new resource: to explore sentiment analysis in the components' forums and negotiators' profiles. This strategy could be useful for both roles since it adds information on positive or negative feelings. Furthermore, information automatically provided by Brechó-EcoSys about the components' average price discount and negotiators' behavior would help to know about flexibility and then optimize proposalsthose data are related to ZOPA.  None.

P2
I think the forum and the tag cloud resources should help, but they did not help me because I did not have the information that was useful to me.

P3
Navigability and orientation in the tool.

P4
Not having the initial price of the product on the trading screen as well as additional private information that may indicate margins for trading.

P5
After denying the negotiation request, I was unable to see if the consumer had purchased the product (perhaps due to my little knowledge about the tool).

P6
Locating my list of components.

P4
Have a brief history of the negotiations on a given product; use filters on the forum to find specific topics related to a particular consumer or product.

P5
The value of the traded product could be explicit in the negotiation in order to facilitate a comparison with the proposed new value. P6 None.

P7
If Brechó-Ecosys calculated the average price discount from the consumer's purchase history (as a percentage of the average and standard deviation it obtained in previous trades), the producer would have knowledge of the tolerance margin for a specific consumer's purchase limits. This information could be used to perform optimized counter-proposals and consequently to obtain higher values and reduce the number of negotiations concluded without success.
After every set of consumer's and producers' tasks, participants were requested to report their perceptions on the negotiation process at Brechó-EcoSys. Despite the suggestions of improvements, the tool got a positive feedback from all participants. The main results are summarized as follows: • Knowing what the community thinks about a specific technology is a valuable information for making decisions on what artefacts should be acquired. Resources like forum and tag cloud help in this process; • If the consumer already knows the product to the acquired, the negotiation process can directly begin with no additional information. Otherwise, the process should initiate by searching the product so that the proposals make sense, or it can end up putting a price with no advantage; • The process is simple, without major difficulties for the negotiator, but requires an introduction on how to operate the tool. The process includes all the necessary steps for a negotiation, such as: direct channel with the producer; consumers' opinion on the available products and existing producers etc.;  Producer: • The participant did not know if the negotiator (consumer) accepted or not the proposal. Similarly to the negotiator profile, access to social information is important to the negotiation process; • During the negotiation tasks, it is important that the producer knows the consumer, or already set a certain price margin for possible negotiation rounds; • It is simple and very similar to the previous one (consumer's perspective). In other words, it has all steps and subsidies to aid in finding both consumer information and past discussions. Figure 15 illustrates the results of the evaluation form regarding the usability heuristics according to the questions from Table 4. The best evaluated heuristics considering the majority of votes for Agree and Totally agree are: Visibility of system status; Match between system and real word; and Aesthetic and minimalistic design. On the other hand, the worst evaluated heuristic based on the majority of votes for Disagree and Totally disagree was Consistency and standards. This is an aspect to be improved in the next release of Brechó-EcoSys, as informed by the participants. This study allowed us to collect suggestions of improvements related to the existing resources, information, visualization, and usability of Brechó-EcoSys. New resources were suggested by participants playing either as producers or consumers. On the other hand, there was a positive outcome related to the negotiation activities performed by the participants with the tool since the number/level of difficulties did not stop any negotiation to be completed.
As threats to internal validity, we highlight: the infrastructure could influence the user's experience, the execution form could interfere in the participant's understanding, and the tasks were open to misinterpretation. The time the participants had to explore the tools was limited. In turn, as threats to external validity, we point out that it was not possible to represent the SECO context in one scenario. The low number of participants was a limitation that makes difficult the generalization of results. However, the results can be used as an initial indication for further investigations. Moreover, all the participants were Brazilian. Nevertheless, this is an initial investigation that showed promising results and instigates to execute the study with a broader population for next rounds.

Results Discussion
Low number of participants and variety in negotiation cases do not allow to generalize the results and to confirm the hypothesis at once. However, it is possible to extract initial positive results from the answers captured as most of the participants explicitly said that they found the proposed mechanisms helpful for the negotiation process. Considering RQ1: "Do the sociotechnical mechanisms at Brechó-EcoSys help the users on the negotiation process?", initial results showed that they help users to get information about the negotiation "object" specially coming from the community. This information can be identified in Figure 14 focusing on the tag cloud and forum functionalities, and the subjects' perceptions and observations can confirm that.
As for RQ2: "Is the usability of the soctiotechnical mechanisms satisfying the users?", the presented mechanisms satisfied the users, but the participants identified a few other attributes or elements that could improve the negotiation experience and the search for information, such as: clarity on the producer's final decision (e.g., an alert when a negotiation proposal is rejected or accepted), sentiment analysis to have a quick sense of what people think of their negotiation and products, a tutorial clarifying the negotiation steps, statistic on sales, among others.

Conclusion
New strategies for software markets are fundamental to evaluate CBSE as a reuse approach that allows exploring real benefits for Software Economics [1]. According to Szyperski et al. [2], an imperfect technology in a working market is sustainable through sociotechnical interactions, and a perfect technology without any market vanishes. So, considering the trajectory of researches on component libraries as well as search and retrieval mechanisms in the 80's and 90's [4], reuse repositories has been submitted to a tendency of opening up software platforms so that CBSE critical issues emerge again in the SECO context. It involves business and social aspects that can be treated through negotiation processes. In this case, a value-based research can contribute since it focuses on stakeholders' needs and the notion of value in SE.
This paper presented a value-based mechanism to support component negotiation and socialization processes in a reuse repository in the SECO context as an extension of the Brechó-EcoSys environment. The main contribution is to treat nontechnical issues of component repositories in the SECO context. Social resources were also incorporated into the mechanism in order to enrich the negotiation process. An evaluation of the negotiation mechanism was performed, based on an analysis of its elements and functions against critical factors in the negotiation within a SECO, identified in a previous systematic literature review. In addition, an analysis of the social resources supporting the negotiation mechanism was performed against popular sociotechnical elements for SECO, identified in a previous survey with experts in the field.
As such, an observational study with software engineers was executed aiming at observing negotiation processes in simulated situations using Brechó-EcoSys environment. Software quality issues were also analyzed in this empirical study through usability measures. The idea was to ask participants to perform some negotiation tasks in the Brechó-EcoSys environment in order to evaluate the feasibility and usability of the sociotechnical negotiation mechanisms. Therefore, this study helped us to collect some perceptions regarding the implemented resources. This is very important since the motivation of this research is to provide a reuse environment based on VBSE and SECO perspectives [15]. The results showed a positive feedback for all the proposed goals, mainly at the negotiation process and the support of sociotechnical resources (forum and tag cloud) providing information from the community. Improvements were pointed by the participants on the usability and new information to be displayed at the negotiation process for consumers and producers. This study has some limitations. However, as a feasibility study, it brings some indications for further investigations.
This research aims to provide a tight relationship among three dimensions of SECOs: technical [11], transactional [16] and social [28]. This is part of an approach to explore the ecosystem domain in SE and improve the comprehension of SECOs in a globalized software development environment [24]. Therefore, we intend to contribute with new strategies to evolve reuse to a VBSE and SECO reality on a components and services platform in software industry. As future work, a study case will be conducted in a real SECO using the Brechó-EcoSys' mechanisms to better evaluate them considering their behavior in a broader context. In addition, a new experiment will be executed aiming to compare the use of the presented resources with other types of negotiation, evaluating more negotiation cases for consumer and producer with different types of objects. This design will allow us to analyze the results' variation using different domains of negotiation.