Software systems are rarely developed in isolation. The development of current complex software systems often makes extensive use of components previously developed or acquired from external suppliers. Nevertheless, research on software systems has traditionally considered each system as an isolated and self-contained project. Such characteristic limits the quality of observations on studies as they do not consider the software ecosystem in which the project is inserted. In this paper we present an ongoing work that aims to enable the analysis of software ecosystems from both technical and sociotechnical perspectives. The novelty of our approach lies in the usage of interactive visualizations to facilitate uncovering relationships among software projects within an ecosystem.
Software systems are increasingly dependent on other software systems. The
need to cope with an increasingly competitive market and demanding customers
leaves no room for each new complex software system to be completely developed
from scratch. Software industry has therefore recurred to software reuse in order
to achieve its goals, making extensive use of solutions previously developed or
acquired from external suppliers and incorporating them within its products.
Although the usage of software components can o er several advantages to the
development of software projects, such as reduced development time, higher
productivity and reliability, a poor choice of components can undermine the quality
of the developed product [
The rest of this paper is organized as follows. In Section 2, we introduce concepts of Software Ecosystems, detailing our de nitions and comparing them to those of other works. Section 3 presents an overview of existing work involving visualization of software ecosystems. Section 4 describes our approach, including notions that comprise its foundations and visualization techniques. Section 5 presents a proof of concept conducted to demonstrate the feasibility of our approach. Finally, Section 6 presents our nal remarks and plans for future work.
As stated by Lungu et al. \no software project is an island" [
Albeit the aspiration to reach a bigger share on a particular market segment can
be observed in software industry and therefore on many software products,
interprojects relationships may appear for other reasons than business-oriented,
ranging from convenience to reuse a previously developed solution to simple interest
in adopting a particular technology. These relationships also establish
connections between projects, forming bonds that, when viewed in a broad perspective,
can be seen as a software ecosystem. Based on this reasoning, we adopted a broad
de nition for SECOs, independent of business features and also aligned to other
recent works [
There are many challenges and unanswered questions regarding SECOs,
particularly from perspectives such as software maintenance and evolution. One such
challenge involves the risks that a software project faces while entering a SECO.
Even though reusing software components with assured quality can provide
bene ts to software projects, a software ecosystem can also impose obstacles to the
development of a software project when the project is made upon components
with low technical quality. Also, these challenges cannot be seen from a strictly
technical point of view, as both technical and social factors play an important
role on the process of software development [
Though recent studies have explored characteristics and behaviors of SECOs,
few approaches have been concerned with ways to visualize and analyze SECOs
relationships. Among the studies on this topic, Perez et al. [
Both SECONDA and SPO o er mechanisms for data extracting, metrics evaluation and visualization of projects within SECOs for visual analysis. However, these tools have limitations related to data collection, being able to only process a so-called "super-repository" that contains all projects of a SECO, regardless of the fact that the data of all SECOs' projects are not necessarily stored in one common repository, limiting the analysis that can be done with these tools and posing as a threat to validity for these works. Furthermore, while these tools o er mechanisms for researchers to explore SECOs from both technical and sociotechnical perspectives, they do not provide means to explore how the relationships evolved over time.
Finally, there are other important but less related works that show charts and
indicators of ecosystems and relate to our proposal by providing results that can
assist us in formulating hypotheses, choosing metrics and constructing
visualizations that are applicable to analyze SECOs. Among this category of studies,
stands out the one described in [
Our approach consists on the usage of information visualization techniques to depict a SECO, applied over software projects repositories' data extracted using mining software repositories (MSR) methods. Our proposal features three main steps: data extracting, data processing, and SECO visualization. On the following subsections we describe each step and introduce key concepts to enable a better comprehension of our proposal.
The rst step of our proposal consists of obtaining data from version control systems and issue trackers of software projects that share technical dependencies, and are therefore members of a common ecosystem under our de nition. Software repositories such as VCS and issue tracking systems are widely used by software developers on both commercial and open source environments, and contain a plethora of available data about the underlying software projects and associated development process that can be mined to explore and investigate evidences about software development. Access to these software repositories is made using native Subversion protocol for VCS connection, while issue trackers data are collected using webcrawlers. Our proposal's data extraction is not limited to analyzing only one repository, being able to collect data from projects stored in di erent repositories to compose an ecosystem.
Following the data collection of a software project, we automatically identify a list of software dependencies from build managers and dependency managers' artifacts, such as Maven's pom.xml or Ivy's ivy.xml. These tools are also extensively used by software development communities and assist the development process, o ering features such as dependencies browsing and managing con icts. The identi cation of software dependencies may lead to data extraction of other software projects, and despite the fact that dependencies identi cation can be performed automatically, data extraction needs to be conducted manually because repositories addresses and their access credentials are not speci ed in the build managers' artifacts. Source code analysis was discarded as a way to establish links between projects since artifacts path or contents is not reliable to infer which project the artifact belongs to.
The Data processing phase has two distinct objectives, beginning with the
identication of dependencies between the collected ecosystems entities, these entities
being developers, actors on issue tracker communities, and software projects'
artifacts and metrics computation. The dependencies among the SECOs
entities are processed using three di erent techniques, namely logical dependencies,
static dependencies and coordination requirements. Static dependencies arise
from procedures and methods calls between projects' classes or compilation
units, while in contrast logical dependencies [
Information visualization techniques have been successfully employed by
researchers trying to understand software system features, especially those related
to software evolution, maintenance and monitoring [
Higher resolution images of the visualizations presented on next subsections are available at http://lab3d.coppe.ufrj.br/index.php/projetos/visecos. Communities View This view (Figure 1) focuses on the analysis of how the di erent communities of a SECO interact, i.e., how each project member of the SECO contributes to other projects from a sociotechnical point of view. The main usage scenario of this visualization is to identify the degree of participation and contributions between di erent projects of the same SECO, naively suggesting the health of the whole SECO community.
To represent these interactions within SECOs' communities we chose to use graphs, since it is regarded as an intuitive way to display dependencies. Based on data from both VCS repositories and issue trackers, we constructed two graphs at di erent levels of granularity. On the coarse grained graph, each project is represented by a vertex with a unique color and has two child vertices, representing the VCS developers' communities and issue trackers contributors. Each of these communities' vertices can then be linked by edges to vertices of other projects, meaning that there are collaborators that act on both communities. The ne grained graph in turn depicts interaction between the communities actors more explicitly based on both Coordination Requirements network and discussions on the same issue by di erent contributors.
The user can interact with the visualization by applying various lters, enabling to focus on the relationships that are of interest to his/her analysis. The lters currently implemented allow: i) hiding nodes from a speci c project or archive (VCS or issue tracker), enabling to focus on a selected set of projects of the SECO; ii) coloring the nodes based on how many di erent projects a contributor participates; iii) change the graphs granularity; iv) and select a speci c time-span to focus on, considering only contributions made within this period. Technical View This view focus on the analysis of how technically interdependent of each other the di erent projects within a SECO are, i.e., how the various artifacts/modules of one project make use of methods and/or objects declared on other projects' artifacts/modules. This visualization is employed to observe the most important artifacts of the ecosystems from a reuse perspective, enabling the visual identi cation of various characteristics such as the assets that are more central to the SECO (i.e., that various other artifacts depend upon) or those that depend upon artifacts supplied by several other projects. The technical view also makes use of graphs to evidence the links between artifacts (Figure 2), displaying the processed static dependencies. Technical view's graph also o ers lters to conduct analysis over ne or coarse grains, since the amount of dependencies between the various projects can prove to be too dense to interpret. In the ne-grained analysis all vertices are artifacts identi ed by the project's color, and edges represent dependencies between the artifacts, whilst on coarse-grain the vertices represent the projects modules obtained from the artifacts' package declaration, naively hinting at the components of each project.
To adequately observe the SECO technical dependencies, users can interact with the visualization likewise the communities view, being able to change the granularity of dependencies and show/hide artifacts of speci ed projects.
To demonstrate the feasibility of our approach, we conducted an exploration of the relationships of a SECO in the form of a proof of concept. The main objective was to highlight the usage of the visualizations we proposed in a real case, using open source projects. Our expectations were that the visualizations would help to identify how dense the technical and sociotechnical relationships between a software project and other projects that it depended upon were.
In order to observe the relationships of a SECO, we required a software project that satis ed three requirements: i) was hosted on Subversion (SVN) repository that we had read access; ii) reported issues on either JIRA or Bugzilla issue tracking system; and iii) listed its dependencies in structured artifacts (e.g., Apache Maven's pom.xml or Apache Ivy's ivy.xml). The rst two requirements are due to limitations of our supporting tools, which can only collect data from the speci ed repositories. The latter is given due to the technique we used to infer software project dependencies, using the speci ed artifacts to automatically gather this information.
Given our intentions and limitations, we chose to observe Apache Sling's ecosystem. Apache Sling is a large open source web framework designed to store and manage content over a Java Content Repository (JCR) speci cation developed by Apache Software Foundation (ASF), being one of its top-level projects since 2009. Apache Sling also matches all our established requirements: it is hosted on a public SVN repository, uses JIRA as issue tracking system and Maven as dependency manager. Furthermore, the project was handily picked due to our previous knowledge of its dependencies with other large ASF's top-level projects Jackrabbit and Felix.
Extracting relevant data depicting how software systems were developed is a complex task. The sheer amount of data can easily overwhelm researchers if appropriate tools and methods are not applied, misleading them to erroneously identify inexistent patterns and features. We made use of two tools to assist us on reaching our goals, namely XFlow and JDX.
XFlow [
We analyzed one speci c release of Apache Sling, developed from May 14th, 2009 to April 18th, 2011. The information about the release dates was obtained by browsing the project's mailing lists and looking for release announcements. In this period, the project was actively developed by a group of 7 people. Apache Sling is composed of several modules within the same repository, and our data collect procedure was con gured to extract data from all these modules' trunk directories, resulting in 830 commits found. We then proceeded with the data gathering by accessing and collecting data from Sling's JIRA, collecting 318 issues reported and/or resolved by a supporting community of 51 people. After this initial data collect we used XFlow to analyze Sling's dependencies and choose two related projects to consider on our analysis: Apache Felix (release 1.2.0 to 1.4.0) and Apache Jackrabbit (release 1.5.0 to 1.6.0). Apache Felix is an open source implementation of OSGi R4 Service Platform and other OSGirelated technologies, being widely used by well-known projects such as Glass sh application server and the Netbeans IDE; while Jackrabbit is an implementation of Content Repository for Java (JCR) speci cation, and provides content management services. We analogously collected data from these selected projects VCS trunks and issue trackers, ending up with a small portion of Sling's ecosystem for study.
For the data processing phase, we obtained the source bundle of analyzed projects on their o cial site to identify static dependencies between the artifacts and modules, while logical dependencies were identi ed using data extracted from VCS and issue trackers by XFlow. We then proceeded to generate visualizations and analyzed our results, discussed on the next subsection.
Our exploratory analysis was able to successfully depict interaction among projects under our SECO de nition (Figure 1 and Figure 2). This initial exploitation was a necessary step to justify further studies, since we couldn't predict how intense would be the interaction among communities of related software projects. Also while our visualizations may not scale to display a large amount of data, we believe that ltering graph nodes using metrics such as centrality and betweenness centrality on future studies can reduce these problems. Besides verifying the feasibility of our approach, we observed interesting features on the analyzed SECO. The discussion of these ndings has been divided in technical and sociotechnical perspectives.
Technical Discussion For the technical perspective analysis we focused on the dependencies between Apache Sling and both Apache Felix and Jackrabbits, excluding dependencies between the latter projects. We did that since the graph that resulted when considering all projects was too dense and proved di cult to represent in a legible gure and was beyond our exploratory context. Considering this limitation, we have analyzed the reused artifacts and the technical view suggests that there are some critical artifacts to the maintenance of Apache Sling that are provided by other projects. We did not nd any class that depended upon artifacts from two projects, and identi ed two interesting patterns on the assets reused: i) a large set of classes that depends on a single class of another project (Figure 3(a)); and ii) a class that depends on various artifacts of other projects (Figure 3(b)). These patterns suggest how prepared to reuse these components were, implying on the reliability of the modules that depend on them. In the rst pattern, for instance, a defect on the reused artifact could be propagated to several artifacts that reuse it; while the second one indicates that even small changes in a class could require knowledge of several other classes from other projects.
Sociotechnical Discussion From a sociotechnical perspective, we observed that all projects of the SECO were related (Figure 1). We identi ed that most of the interactions between the communities involved on the analyzed period has occurred via issue tracking systems, in which 8 collaborators from Apache Sling's issue tracker contributed to project Apache Jackrabbit's issue tracker and viceversa, 7 between Apache Sling and Apache Felix, and 3 between Apache Felix and Apache Jackrabbit. We also note that there is one contributor that bridges all the projects, contributing to all three issue tracker. Looking at the VCS communities, we observed that few developers had participated on two projects on the same period (3 between Apache Sling and Apache Felix), while none had participated in all three.
(a) (b)
Based on these exploratory ndings, we conclude that there have been considerable contributions between all the projects of the SECO and rea rm the importance of sociotechnical analysis on software engineering studies. This initial analysis also provides basis to the conception of an experimental hypothesis that needs further studies to be answered, regarding topics such as the role of those contributors who participate on various projects inside a SECO, or the identication of features that facilitate or hinder the contribution towards a speci c project from external developers that reuse its assets.
Our study is characterized as a proof of concept, and thus has not the same rigor as a formal experiment. Nevertheless, we found interesting results that must be interpreted considering the following validity threats.
Construct Validity. The relationships between developers that we have found may not be totally accurate as it's common to nd some contributors who do not have permission to commit to the project's VCS and have their contributions carried out by others developers.
Internal Validity. Our approach is based on the hypothesis that features of a project's dependencies impact the project that uses them as components, but we have not extensively veri ed the correlation between the projects. Considering this, we cannot determine that the characteristics we observed actually come from the related projects or are derived from unobserved attributes. External Validity. As we analyzed few projects, all of them belonging to the same organization (ASF), we do not claim that these results remain valid for other projects and in di erent development contexts.
Conclusion Validity. We did not conduct any statistical analysis in order to validate our ndings, making use of purely visual methods to perform our analysis. While this could be interpreted as a serious threat to our ndings, given the lack of related work with similar objectives we decided to rst conduct analyses without statistical rigor to explore the degree of interdependencies between projects and general interaction of SECO communities.
This paper presented an approach to analyze SECOs from a technical and sociotechnical perspective, focusing on projects that share reuse dependencies. Our exploratory study matched our expectations that the di erent projects interact beyond the technical level, and this motivated us to further inspect how features of a reusable component a ect software projects and the contributors' communities that reuse them.
We remark that this paper presents an initial e ort to explore SECOs and expect to expand this proposal under the following two major aspects: SECO Metrics: given that software ecosystems form a recent subject for Software Engineering studies, there is a lack of papers that list formal metrics and indicators applicable for SECOs. We intend to conduct a systematic mapping of studies to identify metrics used by recent works on SECOs context, gathering a list of metrics that will enable us to further investigate SECOs.
Expand Research Perspective: our initiative is part of a greater context of SECOs
exploration, with other researchers interested in the investigation of IT and
Governance aspects and the proposal of a framework for modeling and managing
SECOs [
Acknowledgments. Francisco Santana receives individual grant from CAPES, and Claudia Werner from CNPq.