Introduction

Software Ecosystems (SECOs) represent a phenomenon in the Software Engineering (SE) field considering their rapid evolution in this decade, though the first researches in this topic were done by Business Schools in the 90's [18] [19]. SECOs studies in the SE community were motivated by the software product lines (SPLs) approach aiming to allow external developers to contribute to hitherto closed platforms [4]. However, different research directions indicated by literature and industrial cases reinforce a lot of important perspectives to be explored, such as architecture, social networks, modeling, business considerations, mobile platforms and organizationalbased management [14]. Besides, SECOs need a multidisciplinary treatment, including Sociology, Communication, Economy, Business and Law.

These studies are also motivated by the software vendors' routine since they no longer function as independent units that can deliver separate products, but have become dependent on other software vendors for vital software components and infrastructures, for example, operating systems, libraries, component stores, and platforms [6]. So, software vendors resort to virtual integration through alliances to architecture. Also, some results of a preliminary analysis of the Software Reuse Lab's SECOs at COPPE/UFRJ are used to exemplify the first dimension of the proposal.

Besides this section related to the introduction and background, the paper is organized in the following: Section 2 presents an overview of the proposal for SECOs engineering, based on steps to contemplate a SECO tridimensional view during its life cycle; Section 3 explores the architectural dimensions; and Section 4 concludes the paper, discussing ways to detail the SECOs engineering approach.

The Proposal for Software Ecosystems Engineering

Understanding SECOs from a three-level division discussed in Section 1 [15] requires focusing on the SECO scope. Each level has different research challenges starting from the effect of SECO architectural changes to develop general metrics and measure the SECO health. These challenges can be articulated through the definition of general properties of target objects (in organizational, SSN, or SECO scope level) such as health, interaction, performance, inputs, outputs, competition, value sharing and coordination methods. Beyond the scope, different dimensions that cross the SECO levels should be considered in order to represent the pillars extracted from literature researches [4] [7] [14][15] [16][22]: (i) software; (ii) networks and social business; and (iii) actors, organizations and business ecosystems. In other words, many organizations play with their older and newer SE process models in the market that are mixed with their business models, their involvement with third-part developers and their open product architecture or platform.

These views are also observed from a classification of 15 papers published at the First and Second IWSECO1 in three categories:

 SECO architecture: five papers explore decision-making aspects and architectural properties maintenance, for example, using design and code visualization [1][2][5] [9][21];  SECO strategies and tactics: seven papers explore analysis of SECOs perspectives, make analogies with other ecosystems types, and also provide methods and models for organizing, classifying and evaluating SECOs [7][10] [12][15] [17][22][25];  SECO social networks: three papers explore nets focused on stakeholders (i.e., SECO community management) and artifacts (i.e., knowledge management in requirements, for example), as well as their combinations [8][11] [24]. From the SECO challenges discussed at IWSECO 2010, such as "why do SECOs appear and disappear?" and "how to define and monitor SECO scope, types, roles and characteristics", and the current lacking of researches in this direction, this research defines a proposal for SECO engineering, initially focused on researches presented at IWSECO. The goal is to understand SECOs generated by different SSNs throughout their life cycle phases (from their birth to their death or impairment) considering their three levels of scope and allowing the identification of new SECOs. So, the proposal is structured in a set of related steps classified according to a SECO tridimensional view, initially distinguished by Campbell & Ahmed [7].

 The next section discusses the goal and steps of the first dimension. Examples from a preliminary analysis of four Software Reuse Lab's Brazilian free software projects at COPPE/UFRJ are presented to illustrate some concepts. These projects are: (i) Odyssey3 : a large Java SE project, which is a standalone IDE to support domain engineering and software reuse, involving a platform kernel (Odyssey-light) with several plug-ins (subprojects) in evolution to support software process lines, developed since 1997; (ii) Brechó4 : a medium Java EE project, which is a components and services web library to support reuse management processes and value-based component markets and environment based on open source frameworks (Struts and Hibernate), being a self-contained platform in a kernel/plug-ins refactoring phase, developed since 2005; and (iii) EduSE Portal5 : a medium Java EE project, which is a collaborative web environment for empirical research on SE education (systematic reviews, surveys and bodies of knowledge management) based on open source frameworks (JBoss Seam), being a self-contained platform in development phase, developed since 2009; and (iv) RPP Portal6 : a medium Joomla project, which is a collaborative web environment for social sciences research on public politics, being a self-contained platform in development phase, developed since 2010, which will support 10 academic groups that want to share research components as web contents (videos, pictures, interviews, thesis, reports and their combinations).

Dimension #1: Architecture

The first dimension is related to the organizational and SSNs scope levels (internal point of view) more than the SECO scope level (external point of view) since it focuses on the platform element. This dimension aims at knowing how SE is applied to the platform conception, development and maintenance, considering three steps:

Step 1: contextualize platform project and development -corresponds to the platform analysis phase done via three activities. The involved concepts can be matched to van den Berk et al.'s concepts relationship domain model [25]:

Activity 1: select platform -represents a decision point in choosing a platform in order to study it, depending on the SECO boundary (i.e., market, technology, infrastructure or organization). In the Software Reuse Lab, Odyssey and Brechó platforms were selected for a preliminary analysis, as distinct SECOs. Despite, some examples mention EduSE Portal and RPP Portal in the following steps. Activity 2: identify roles -aims to define who are the SECO actors, considering the different roles previously pointed out by the business ecosystem literature since a SECO is a specialization of a business ecosystem [13]. These roles are grouped in two categories: hubs and niche players [15][25]:  The hubs can be keystones (responsible for creating and sharing value with all SECO actors, e.g., bachelors, master and PhD students who work in the Software Reuse Lab's platforms), or dominators (responsible for extracting a value as he/she can assimilate or eliminate it from the SECO, e.g., Eclipse SECO is attracting students to develop their researches out of Odyssey or Brechó's platforms). In turn, the niche players use the platform to create value to it, developing and improving its capabilities and differentiation by themselves.  The niche players can be influencer (SECO participant who influences keystone, e.g., Quality and Empirical SE Groups at COPPE/UFRJ, and also users from different Brazilian regions who report issues and make suggestions), hedger (SECO participant who wants to belong to the concurrent SECOs to minimize risks, e.g., SE groups from other Brazilian universities such as UFF, PUC-RS and IFF that work with the Software Reuse Group) and disciple (SECO beginner who wants to expose opinions about the platforms, e.g., SE Group from UFLA, integrated to EduES Portal and Brechó through a national research project approved in 2010). Activity 3: analyze health -consists in quantifying and qualifying some health indicators related to the SECO state from its platform. The main three indications are [10][15]:

 productivity: describes the SECO activity level, i.e., how much business is created, how much value is earned and how many actors are joined. For example, in May 2008, the Brechó SECO has a special mark with the most intense period of development as reported by the StatSVN7 tool (Fig. 1). Other interesting measures in this case are: developed use case points, flow of component production, number of reports, quality of thesis and dissertations etc.  robustness: describes how a SECO can recover from a major stress by itself, such as keystone loss, the "death" of some niche players, or a technological advance that affect the major part (community and/or platform) of the SECO. For example, the effective exit or loss of master and PhD students due to industry opportunities or federal concourses reduce the number of members developing and leading new Odyssey plug-ins or Brechó extensions. Other interesting measures in this case can be: quality of research (publishing impact) and quality of platforms' software product according to international standards such as ISO 25000 8 .  niche creation: describes the SECO capability in creating opportunities to new and old actors to explore new business chances. For example, the continuous search for national and regional agencies for financial support (e.g., CNPq, CAPES, FAPERJ in Brazil) to join new research groups (e.g., SE Group at UFLA, and IPPUR -Regional and Urban Plan Research Institute -at UFRJ) and strengthen new Software Reuse Lab's SECOs (EduSE Portal and RPP Portal, respectively). Another example is the marketing used to promote Brechó and EduSE Portal SECOs through short courses and papers presentation in national and international events. Other interesting measures in this case are the number of new collaborators and users in the platform.

Step 2: plan the process of opening the platform architecture -corresponds to the platform design phase done through three activities:

Activity 1: specify levels -aims to identify and separate modules or components from the platform, exploring the layer-based architecture benefits and making its opening process easier, because it can be organized in tasks and subtasks workgroups where each actor leads with a particular abstraction level, based on [2]. For example, Brechó Library and EduSE Portal web platforms in their SECOs, as well as Odyssey IDE desktop platform in its SECO, have three layers: (i) extended applications developed by external developers (other SE groups in Brazil) and installed by users in their target systems or infrastructure (researchers and professors who use the platforms); (ii) native applications developed by the Software Reuse Lab and, in some cases, do not modified; and (iii) kernel developed by keystones, which represents the platform hearth and treats low-level components such as device drivers, security, framework etc. Activity 2: delineate factors -consists in defining platform extension and accessibility mechanisms from making the conditions that govern the access to different layers and components explicitly, based on [2]. For example, three actions are used to make clear the notion of architecture opening in Brechó SECO: (i) integrate: allows using components from an existing layer in an application via API, service call, code inclusion, shared data objects or other software extension mechanisms, e.g., a project that integrates the tool for supporting software development process Microsoft Team Foundation Server (TFS) 9 to Brechó [26]; (ii) extend: allows enhancing the functionalities of components in a layer, e.g., the evolution of Brechó platform from a component repository to a component marketplace environment, generating Brechó-VCM SECO [23]; and (iii) modify: allows replacing or modifying components in a layer, e.g., the evolution of a component trade mechanism [26] to support pricing models [22]. Activity 3: define licenses -tries to facilitate and restrict the participation of the SECO actors over the platform through rights and obligations that govern the process of opening the architecture [1]. Aspects related to components evolution and replacing, architecture evolution, component license evolution, and modification of wished rights and acceptable obligations should be considered. This happens through a process called platform "co-evolution" because it shows the interdependence among software vendors (keystones) and suppliers (niche players), and the need of communication and coordination mechanisms in this scenario. Besides, the emergence of licenses should consider some kinds of common elements in software architecture in a platform such as source code components, executable components, web services, APIs, software connectors, connection methods, and systems and subsystems configured architectures. For example, Software Reuse Lab always requires allowance to integrate, extend or modify entities in Brechó platform, as shown in Table 1.

Step 3: balances architecture modularity 10 and transparency 11 in SECO platformcorresponds to platform implementation phase done through four activities: 9 Available at: <http://msdn.microsoft.com/en-us/tfs2008/default.aspx>. 10 Modularity consists in applying the traditional engineering principle related to decomposing a system in manageable modules, minimizing the technical coupling among its parts [9]. 11 Transparency consists in making all kinds of development information available, including design and code, development tasks, defects and interactions among SECO stakeholders [9].

Table 1. Comparison among architecture opening strategies in the Software Reuse Lab' SECOs, based on [2]. P = Possibility, L = License status, Po = Possible, Pc = Possible for some components, Np = Not possible, Pn = Permission is not needed, Ps = in some cases, permission is needed, and Pa = Permission is always needed. Specially, Brechó's kernel is being studied in order to derive components (critical), and EduSE Portal architecture is in a good stage to start thinking about this (alert). Activity 1: capture context and establish strategies -its objective is to detail the SECO platform scope, classifying it according to the abstraction level (e.g., reusable asset in requirement, design, code or executable level, resource, information etc.) and type (e.g., functionalities, components, crosscutting concerns etc.) of knowledge manipulated in SSN, as well as the actor profile (e.g., platform manager, requirement engineer, analyst, internal or external developer etc.). Thus, it is easier to apply the component-based development (CBD) using interfaces, since the architecture is layered. For example, Brechó platform is a web application developed over Java EE platform using MVC pattern and web (Struts) and persistent (Hibernate) frameworks, and use Tomcat container and MySQL database servers to run the system. SVN version control system presents 17 developers since 2005. Finally, the platform mostly deals with code artifacts, based on modules and components and has a manager (keystone player since 2007) and two developers in different geographical regions (niche players since January 2011). From the lack of market-style documentation and the niche players volatility (undergraduate students), a strategy adopted since the beginning of Brechó SECO was the use of javadoc and design patterns, as well as known and free technologies, though it is difficult to update and migrate the platform to new ones because sometimes there is no available human/financial resource. Activity 2: define information elements -its objective is to make three platform architectural key elements explicit, the first one related to platform translucence interfaces and the last one to visibility of how modeling, designing and coding platform components evolve, based on [9]:  uncertainty: is the probability of changing platform interfaces, requiring decisions in time (e.g., evolution, correction etc.) and space perspectives (e.g., collaborative development etc.). The goal of treating this information element is the interfaces stability, impacting the tracing among different abstraction levels and types of manipulated components. For example, Odyssey SECO has niche players using its platform kernel to work in different geographical regions, and they need to coordinate their activities through discussion lists and annual workshops in order to orchestrate decisions overtime.  complexity: is the property of standard and understandable interfaces compose the platform development process, exploring the information hiding principle in order to benefit from the niche players activities in different abstraction levels of platform components (code, model and requirement). The goal of treating this information element is the standardization (use of code and design patterns), impacting product characteristics such as maintainability and reusability (how to calculate cost and effort to evolve the platform). For example, Brechó platform was developed over MVC architectural pattern, using known frameworks and following code patterns established by Sun's Java Code Conventions -this decision directly represents an advantage to propitiate the entrance of new niche players in Brechó SECO.  activity awareness: is the capability of actors to clearly know process activities, dependencies and barriers in two perspectives, artifacts and roles, based on [24]. The goal of treating this information element is the coordination and communication (from CSCW), impacting the platform knowledge comprehensibility (e.g., how to calculate cost and effort to manage the platform). For example, Odyssey, Brechó and EduSE Portal SECOs platforms are submitted to a version control system (SVN) and have a modification control system (Bugzilla) that allows the old and new niche players to communicate and collaborate in developing and maintaining architectural components in each platform, including Yahoo and Google groups. Activity 3: calculate and analyze metrics related to information elements -its objective is to extract platform architecture knowledge from the information elements discussed in the last activity:

Brechó

 Measuring uncertainty requires data collected from niche players' experiences (e.g., architects and developers) when they face requirements comprehension and platform characteristics (e.g., knowledge map), as well as from models that quantify uncertainty points based on historical similar projects in the platform. For example, the time line and the effort (LoC) to develop a new component or extension to show information in bar/pizza graphics can be extracted from SVN data considering the components developed in marketing and evaluation mechanisms at Brechó platform [23].  Measuring complexity requires data collected from components interfaces in different layers (e.g., number and parameters types), from OCL architectural descriptions, and from platform's nonfunctional properties or crosscutting concerns. For example, in Brechó platform, javadoc improves the code legibility and maintainability, and that characteristics can be verified through the use of product metrics on component interfaces overtime.  Measuring activity awareness requires data collected from contracts that govern the links between artifacts and roles, and from reports of architectural design tools that capture, document and track the platform evolution during decision-making processes (e.g., uses of new resource, blocks of code parts, establishment of pre and post conditions etc.). For example, StatSVN was used to collect and analyze Brechó platform data such as source code time line, packages and files per change, developers contribution (commits history), activities per hour, per day or per week etc. This can help the licenses definition. Some information is presented in Fig. 2. Activity 4: apply translucence to artifacts interfaces in the platform -its objective is to contribute to the SECO coordination and communication mechanisms, supporting collaboration and cooperation and avoiding information overload (i.e., each stakeholder profile can access an abstract level and a type of platform knowledge according to his/her role). In parallel, the property and safety should be treated in order to maintain the reliability of the manipulated knowledge (e.g., in models and source code). For example, the Brechó platform implementation is based on javadoc and is controlled by SVN. This fact allows mining repository data to visualize change impacts in platform components, and filter information (e.g., set of classes) to be shown to a developer based on his/her task requirements and stakeholder profile. Cataldo & Herbsleb [9] point out that a strategy to do this would make information elements explicit through tags in architectural descriptions and javadoc in source code, contributing to the interfaces translucence, i.e., improving the visibility of information elements or behaviors and hiding others via links among technical and socio-organizational roles. Thus, rules that relate knowledge in different abstract levels and types to stakeholders profiles at SECOs can benefit from information visualization. More details can be found in [9].

Conclusion and Future Work

Since the lack of theoretical and applied research in SECOs management through a SE point of view is a challenge to make this field well established in academic research, this paper presented an initial proposal for SECOs engineering to outline a set of steps that combines three different dimensions of SECOs and joins different existing perspectives in the SECOs research literature through a survey. The preliminary contribution was to understand how SECO community is treating ecosystems in a SE point of view, and integrate the works presented at the two first IWSECO editions. In this paper, the focus was on the first dimension, that is, architecture, but the others (business and social) are being studied and linked to the architectural one, since it is impossible to treat SECOs with a pure engineering approach. The discussed proposal will provide a framework to guide and allow deeper researches related to an approach to support SECOs management and development based on empirical studies (primary and secondary ones) which also will involve case studies with well-known SECOs such as Android, Force.com, Eclipse, Microsoft, Linux etc. This can provide a body of knowledge to make SECOs diagnosis, design, and validation and decision-making processes available based on the fact that ecosystems appear, are developed, mature and/or disappear as well as markets, technologies, platforms and organizations, processes, models, techniques etc. The results of a preliminary analysis of the Software Reuse Lab's Brazilian SECOs at COPPE/UFRJ point out that several concepts presented at IWSECO 2009 and IWSECO 2010 can be connected in a broader SE approach, as discussed in Section 3. Thus, it can be realized that understanding SECOs requires joining a lot of instable IT elements in an entity (platform), adding SE elements which alter those elements during the ecosystems creation, development and maintenance -a SE challenge of treating the social and economic aspects [3]. Future work consists of expanding the proposal with other case studies and with expert-based surveys to calibrate the architectural dimension and integrate it to the other two dimensions in a unified approach. Additionally, extensions in the Brechó Library to support component-based architecture SECOs management and development will be done, since this tool has a lot of mechanisms that can help business and social dimensions.