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)