Multihoming in Software Ecosystems

Multihoming in Software Ecosystems

Open source software ecosystems generally have a large number of developer contributors. These relationships are not exclusive: developers may come and go, or work at different (even competing) ecosystems at the same time (multihoming) instead of limiting themselves to a single ecosystem (singlehoming). Mulithoming can improve the popularity of the code; participating in two ecosystems means more users, which is an advantage for the developer. Little is known about the effects of multihoming on software ecosystems. This paper describes a study of open source developers in the Eclipse ecosystem to determine if they work on various projects in the ecosystem or work on comparable projects in other ecosystems.

A tool named ‘Darkharvest’ is created in Ruby to mine information about the Eclipse ecosystem via the GitHub API. The source of Darkharvest is available through a link in the paper we wrote on this subject. DarkHarvest collects the meta-data (id, name, description) of all public repositories managed by the Eclipse Foundation on Github. Next, of all the Eclipse repositories, all contributors are identified and their public meta-data (id, name) gathered. Finally, Darkharvest collects all personal, publicly available repositories of these contributors.


Piechart that shows the multihoming combinations and their share of all repositories. Please note, that we also identified triplehomers, but only a small number.

Darkharvest found 565 Eclipse Foundation repositories in the initial step. Of these repositories, we collected the proles of a total of 736 contributors. These contributors controlled a total of 9756 repositories (excluding the initial 565 Eclipse repositories) for a grand total of 10321 repositories in our data-set.

Most multihoming developers (87.79%) only work in one competing ecosystem besides Eclipse. A minority of multihoming developers (12.21%) work in two competing ecosystems besides Eclipse, while no developers contribute to four or more ecosystems. The average number of ecosystems in which a multihoming Eclipse developer works is found to be at 2.12.

The data furthermore showed two correlations: one between repositories at the Aptana ecosystem and at the Eclipse ecosystem, being .574 with two-tailed significance of .000, the other between repositories at the Eclipse ecosystem and the Textmate ecosystem, being .356 with a .012 significance. It is unknown why those correlations exist.

Next, multihoming behavior is analyzed: the results show that more active developers tend to have more repositories outside of Eclipse. However, if only the ratio is calculated between Eclipse and other ecosystems to which a developer contributes, it is the other way around: for every Eclipse repository active developers have less non-Eclipse repositories than less active developers.

Multihoming ratio

Multihoming ratio (Number Eclipse repos divided by number of non-Eclipse repos) per amount of total repositories

To identify relationships, we created a Gephi visualization. The colors identify the different ecosystems, the nodes display the repositories, and the size of the node grows if more developers work at the repository. Lines are users which work at both repositories; which are thicker when more developers share the same two repositories.

Ecosystem Color
Eclipse Yellow
Aptana Red
Intellij Green
Sublime Cyan
Textmate Blue
Vim Orange
Visual Studio Grey
Gephi visualization

The Gephi visualization, displaying repositories as nodes and users as lines between nodes

Some interesting ‘islands’ are visible. Some of them exist of only one developer being very active (the blue cluster to the east), while other islands exist of multiple developers working at one cluster.

Because the resolution of the screen matters a lot for the readability and the visualization has one of 3000×3000 pixels, we provided multiple sizes.

Link to visualization Resolution
Link 3000×3000 pixels (large)
Link 2000×2000 pixels (medium)
Link 1500×1500 pixels (smaller)
Link 1000×1000 pixels (small)

Merits of a Meritocracy in Open Source Software Ecosystems

The Eclipse open source ecosystem has grown from a small internal IBM project to one of the biggest Integrated Development Environments in the market. Open source communities and ecosystems do not follow the standard governance forms typically used in big organizations. A meritocracy is a frequently occurring form of governance on different levels in open ecosystems. In this paper we research how this form of governance influences the health of projects within the Eclipse ecosystem in terms of the amount of commits within each month. We analyzed the hierarchy of Eclipse, how merits are conceptualized within the ecosystem and the effect of the appointments of mentors and project leads on the amount of commits. From our research, we can conclude that this system is not always as fair as it seems; merits are only a benefit in some cases.

Sample of project lead data with commit averages in months

Table 3 provides an example of the analyzed data on the effect of project lead appointments per project. The change column shows if the project was less productive(‘<‘), equally productive(‘=’) and more productive (‘>’) during the assignment of the project lead.

We concluded, that while commit data is of importance when a commiter wants to climb the ladder to the top, it is certainly not the only one. Rather, personality and connections are even more important. The Meritocracy itself is also not as ‘fair’ as it seems. The more to the top you get, the less it is about merits – and more about politics.


Eckhardt, A.E. & Kaats, E.J. (2014) The Merits of a Meritocracy in Open Source Ecosystems. Poceedings of Seminar Software Ecosystems 2013-2014, Utrecht, The Netherlands. Retrieved on 18/04/2014 from


Research Proposal SECO Seminar (Group ProductLines)

As part of the Utrecht University’s Master of Business Informatics curriculum, dr. Slinger Jansen currently teaches a seminar on Software Ecosystems. During this seminar, students are introduced to the field and performed research of Software Ecosystems. Furthermore, students will perform their own research, contributing knowledge on this domain. With this blog post, we (Michiel Pors and Peter van Stijn) present our research proposal hoping for feedback of domain experts and other students – please do not hesitate to reply on this post with comments or criticism as it will definitely improve the quality of our final research paper.

We are planning to do research on portfolio management within software ecosystems Portfolio management is a dynamic decision process in (software) product management, whereby a business’s list of active new product (and development) projects is constantly updated and revised [1]. In a software ecosystem a set of actors are functioning as a unit and interacting with a shared market for software and services, together with the relationships among them [2].

As research in (software) portfolio management focuses mainly  on the traditional software product lines, controlled and produced by one company, we are wondering how the shift from software product lines towards software ecosystems [4] has influenced portfolio management. Especially to what extend old challenges have remained or been solved, and to what extend new challenges have emerged. Scientifically, this will contribute to both the research domains, increasing the understanding and insights of these domains and their combination. In practice, this research will contribute to the understanding of the risks and difficulties (concerning portfolio management) that will be faced by companies who are switching, or considering to switch, from a traditional software product line towards an extended software ecosystem.

We have formulated our research question as follows:

“How do the challenges of portfolio management in large software ecosystems differ from those in software product lines?”

Obviously, this will mainly be an exploratory research, which will structure and identify (new) problems in the field of portfolio management and software ecosystems. It will be a combination of a primary and secondary research, i.e. a combination of summarizing existing research and collecting data that does not yet exist. The research will be performed in two steps:

First, a literature study will be conducted in order to create a thorough understanding on software ecosystems, portfolio management and the boundaries of these concepts. In addition, this section will function to position this particular paper in this research area. Beside an overview on the current state of research on the topic, this literature research will result in a conceptual solution to the research question. This solution would comprise known challenges for portfolio management in traditional software product lines, these traditional challenges that will most likely persist in software ecosystems and newly identified challenges for software ecosystems.

After this literature study, case studies will be performed to validate the found challenges on the practical experiences of a company, and to search for more possible challenges and approaches  on the portfolio management. Two or three companies will be examined to conform time limitations of the research, but still allow triangulation. The companies will preferable have changed their business model from software product line (SPL) oriented towards a software ecosystems (SECO) oriented approach recently. This way, much information on old and new challenges can be obtained from one case study.

The results of the literature and case study will be presented in the form of a table where both the portfolio management challenges for SECOs and SPLs are listed. Directions for future research will most likely be towards constructive researches, where a solution to the identified problems can be developed.


[1] Cooper, R., Edgett, S., Kleinschmidt, E. (2001) Portfolio Management for new Products. Perseus Publishing, Philadelphia

[2] Jansen, S., Finkelstein, A., Brinkkemper, S. (2009) A Sense of Community: A Research Agenda for Software Ecosystems. 31st International Conference on Software Ecosystems, New and Emerging Research Track, 187 -190

[3] Pohl, K., Bockle, G., Van Der Linden, F. (2005) Software Product Line Engineering: Foundations, Principles and Techniques. Springer

[4] Bosch, J. (2009) From software product lines to software ecosystems. Proceedings of the 13th International Conference on Software Product Lines (SPLC). Springer LNCS.

Partnership Characteristics within Large Software Ecosystems

Partnership and membership models are a powerful tool for large software ecosystem orchestrators to manage clusters within their ecosystem. A partnership model is utilized by a software vendor or platform owner to sustain, manage, cluster and expand their partner ecosystem while open source associations strive to achieve the same with their software ecosystem utilizing a membership model. Both model types are clusters of active participants within a certain section of the ecosystem, that is why we refer to these models as ecosystem participant clusters.

The taxonomy above describes the structure of an ecosystem participant cluster. A cluster owner can posses zero or more ecosystem participant clusters, each having a unique type (e.g. partnership model, membership model). A large software vendor, for example, can utilize a global partnership model and can at the same time have separate region or market-specific partnership models. As mentioned, each ecosystem participant cluster consists of a certain number of participants, organizations that did engage into one or more commitments with the cluster owner. Each commitment has a unique contract, that is agreed on by the participant and the cluster owner. Within each commitment the participant fulfills a role. Roles within the model can have zero or more dimensions, an example of a role with more than one dimension is a golden level value-added reseller. Each role has a set of requirements that has to be met in order to obtain or retain this role. Also, every role has a set of predefined benefits it brings for the participant. Furthermore fulfilling a role within a cluster comes with certain costs, except for educational and community commitments that are often free of charge.

While the structure of different clusters is similar, differences are identified in other areas. While studying the global partnership model of SAP and the membership models of the Open Design Alliance and Eclipse Foundation as case studies, differences were indentified in primary structure, entry barriers, model governance, accessibility of documentation and goals, as summarized in the classification table above. Both membership models have a layered primary structure that is designed on an increasing level of involvement by a participant over time while the global partnership model of SAP has a role-based structure that suits function-specific needs. Furthermore the openness of a software ecosystem has an influence on the model governance. SAP, a closed software ecosystem, includes platform defence in the governance for their partnership model, which, for example, means participants can possibly lock themselves out of partnering with SAP by having a high level of involvement with another closed software ecosystem. While all three software ecosystems share some goals for their clusters, (e.g. extending the ecosystem, product development and co-innovation) their different organizational form makes them prioritize these goals in a different way. SAP, for example, strives to monetize on their partnership model and aims for the extension of market reach through their partners while ODA and Eclipse prioritize product development instead. The different organizational form also influences the range of benefits expected for participants. Benefits in a membership model cover a wider range and include influence on the decision-making process within the open source association.