John Businge | Eindhoven University of Technology (original) (raw)

Papers by John Businge

Social coding platforms centred around git provide explicit facilities to share code between proj... more Social coding platforms centred around git provide explicit facilities to share code between projects: forks, pull requests, cherry-picking to name but a few. Variant forks are an interesting phenomenon in that respect, as it permits for different projects to peacefully co-exist, yet explicitly acknowledge the common ancestry. Several researchers analysed forking practices on open source platforms and observed that variant forks get created frequently. However, today little is known on the motivations for launching such a variant fork. Is it mainly technical (e.g., diverging features), governance (e.g., diverging interests), legal (e.g., diverging licences), or do other factors come into play? In this paper we report the results of an exploratory qualitative analysis on the motivations behind variants creation and maintenance. We surveyed 105 maintainers of different active open source variant projects hosted on GitHub. Our study extends previous findings, identifying a number of fi...

2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)

Eclipse framework provides two interfaces: stable interfaces (APIs) and unstable interfaces (non-... more Eclipse framework provides two interfaces: stable interfaces (APIs) and unstable interfaces (non-APIs). Despite the non-APIs being discouraged and unsupported, their usage is not uncommon. Previous studies showed that applications using relatively old non-APIs are more likely to be compatible with new releases compared to the ones that used newly introduced non-APIs; that the growth rate of non-APIs is nearly twice as much as that of APIs; and that the promotion of non-API to APIs happens at a slow pace since API providers have no assistance to identify public interface candidates. Motivated by these findings, our main aim was to empirically investigate the entire population (2,380K) of non-APIs to find the non-APIs that remain stable for a long period of time. We employ cross-project clone detection to identify whether non-APIs introduced in a given Eclipse release remain stable over successive releases. We provide a dataset of 327K stable non-API methods that can be used by both Eclipse interface providers as possible candidates of promotion. Instead of promoting non-APIs which are too fine-grained, we summarized the non-API methods groups in given classes that are stable together and present class-level non-APIs that possible candidates promotion. We have shown that it is possible to predict the stability of a non-API in subsequent Eclipse releases with a precision of ≥ 56%, a recall of ≥ 96% and an AUC of ≥ 92% and an Fmeasure of ≥ 81%. We have also shown that the metrics of length of a method and number of method parameters in a non-API method are very good predictors for the stability of the non-API in successive Eclipse releases. The results provided can help the API providers to estimate a priori how much work could be involved in performing the promotion.

Empirical Software Engineering

With the rise of social coding platforms that rely on distributed version control systems, softwa... more With the rise of social coding platforms that rely on distributed version control systems, software reuse is also on the rise. Many software developers leverage this reuse by creating variants through forking, to account for different customer needs, markets, or environments. Forked variants then form a so-called software family; they share a common code base and are maintained in parallel by same or different developers. As such, software families can easily arise within software ecosystems, which are large collections of interdependent software components maintained by communities of collaborating contributors. However, little is known about the existence and characteristics of such families within ecosystems, especially about their maintenance practices. Improving our empirical understanding of such families will help build better tools for maintaining and evolving such families. We empirically explore maintenance practices in such fork-based software families within ecosystems o...

Eclipse third-party plug-ins source code

Software developers often need to create variants to accommodate different customer segments. The... more Software developers often need to create variants to accommodate different customer segments. These variants have a common code base but also comprise variant-specific code. A common strategy to create a variant is to clone&own (or fork) an existing repository and then adapt it to the new requirements. This form of reuse has been enhanced with the advent of socialcoding platforms such as GitHub, and package distribution platforms like npm. GitHub offers facilities for forking, pull requests, and cross-project traceability. npm offers facilities for managing package release dependencies and dependents on the distribution platform. Little is known about the maintenance practices of the variants. We therefore performed an exploratory investigation on the evolution of variants, focusing on their technical aspects. We collected variants from the JavaScript ecosystem, whose sources are hosted on GitHub, and whose packages are released on npm. We have identified a total 12,813 variant fork...

Forking is an often used idiom in software ecosystems that allows for the immediate reuse of exis... more Forking is an often used idiom in software ecosystems that allows for the immediate reuse of existing software packages. Further, research shows that forking negatively impacts software quality since it distributes the maintenance effort across several repositories. However, there is a lack of sufficient knowledge exploring the validity and applicability of forking as an approach to solve software quality issues. In this position paper we present a plan to investigate the effectiveness of forking in managing technical debt.

Today, when constructing software systems, many developers build their systems on top of framewor... more Today, when constructing software systems, many developers build their systems on top of frameworks. Eclipse is such a framework that has been in existence for over a decade. Like many other evolving software systems, the Eclipse platform has both stable and supported interfaces (''good'') and unstable, discouraged and unsupported interfaces (''bad''). In this study, we investigate Eclipse interface usage by Eclipse third- party plug-ins (ETPs) based on whether they use bad interfaces or not. The investigations, based on empirical analysis present the following observations. First, we discovered that 44 % of the 512 analyzed Eclipse third-party plug-ins depend on ''bad'' interfaces and that developers continue to use ''bad'' interfaces. Second, we have observed that plug-ins that use or extend at least one ''bad'' interface are comparatively larger and use more func- tionality from Eclipse than those tha...

Proceedings of the 13th International Conference on Predictive Models and Data Analytics in Software Engineering

Context: In recent years, many research studies have shown how human factors play a significant r... more Context: In recent years, many research studies have shown how human factors play a significant role in the quality of software components. Code authorship metrics have been introduced to establish a chain of responsibility and simplify management when assigning tasks in large and distributed software development teams. Researchers have investigated the relationship between code authorship metrics and fault occurrences in software systems. However, we have observed that these studies have only been carried on large software systems having hundreds to thousands of contributors. In our preliminary investigations on Android applications that are considered to be relatively small, we observed that applications systems are not totally owned by a single developer (as one could expect) and that cases of no clear authorship also exist like in large systems. To this end, we do believe that the Android applications could face the same challenges faced by large software systems and could also benefit from such studies. Goal: We investigate the extent to which the findings obtained on large software systems applies to Android applications. Approach: Building on the designs of previous studies, we analyze 278 Android applications carefully selected from GitHub. We extract code authorship metrics from the applications and examine the relationship between code authorship metrics and faults using statistical modeling. Results: Our analyses confirm most of the previous findings, i.e., Android applications with higher levels of code authorship among contributors experience fewer faults.

2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)

Mobile app developers often need to create variants to account for different customer segments, p... more Mobile app developers often need to create variants to account for different customer segments, payment models or functionalities. A common strategy is to clone (or fork) an existing app and then adapt it to new requirements. This form of reuse has been enhanced with the advent of social-coding platforms such as Github, cultivating a more systematic reuse. Different facilities, such as forks, pull requests, and cross-project traceability support clone-based development. Unfortunately, even though, many apps are known to be maintained in many variants, little is known about how practitioners manage variants of mobile apps. We present a study that explores clone-based reuse practices for open-source Android apps. We identified and analyzed families of apps that are maintained together and that exist both on the official app store (Google Play) as well as on Github, allowing us to analyze reuse practices in depth. We mined both repositories to identify app families and to study their characteristics, including their variabilities as well as codepropagation practices and maintainer relationships. We found that, indeed, app families exist and that forked app variants fall into the following categories: (i) re-branding and simple customizations, (ii) feature extension, (iii) supporting of the mainline app, and (iv) implementation of different, but related features. Other notable characteristic of the app families we discovered include: (i) 73 % of the app families did not perform any form of code propagation, and (ii) 74 % of the app families we studied do not have common maintainers.

2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)

The incredible success of the mobile App economy has been attracting software developers hoping f... more The incredible success of the mobile App economy has been attracting software developers hoping for new or repeated success. Surviving in the fierce competitive App market involves in part planning ahead of time for the success of the App on the marketplace. Prior research has shown that App success can be viewed through its proxy-popularity. An important question, then, is what factors differentiates popular from unpopular Apps? GitHub, a software project forge, and Google Play store, an app market, are both crowdsourced, and provide some publicly available data that can be used to crosslink source code and app download popularity. In this study, we examined how technical and social features of Open Source Software Apps, mined from two crowdsourced websites, relate to App popularity. We observed that both the technical and the social factors play significant roles in explaining App popularity. However, the combined factors have a low effect size in explaining App popularity, as measured by average user rating on Google Play. Interestingly on GitHub, we found that social factors have a higher power in explaining the popularity compared to all the technical factors we investigated.

International Journal of Computer Applications, 2016

Energy efficiency in data center networks is increasingly becoming a gold standard for implemente... more Energy efficiency in data center networks is increasingly becoming a gold standard for implementers. Energy costs are becoming high while performance is highly demanded. And while efforts are directed to the design of energy efficient networks, a number of open issues require addressing including:-scalability, fault tolerance, efficiency in performance though their presence does not outweigh the benefits of networks energy-aware. Truly, we observe that improvements in computer networks hardware performance comes with increasing energy consumption. To address these complementary challenges, this paper technically surveys existing, approaches and techniques (virtualization, energyaware routing, among others), tools, and architectures employed in energy efficient computer networks. We have also provided a thorough review of data centre networks: server centric, switch centric and dual centric architectures with a view to inform developers and implementers of the overhead given architectural choice, identified challenges and opportunities. We conclude upon the survey that dual centric computer networks architectures have various nice properties for practical computer networks and provide flexible choices in designing of computer network architectures.

2016 IEEE 24th International Conference on Program Comprehension (ICPC), 2016

The Eclipse framework is a popular and widely adopted framework that has been evolving for over a... more The Eclipse framework is a popular and widely adopted framework that has been evolving for over a decade. Like many other evolving software systems, the Eclipse framework provides both stable and supported interfaces (APIs) and unstable, discouraged, and unsupported interfaces (non-APIs). However, despite being discouraged by Eclipse, the usage of bad interfaces is not uncommon. Our previous research has confirmed that as Eclipse states, indeed APIs are stable while non-APIs are unstable. Applications using non-APIs face compatibility challenges in new Eclipse releases. Furthermore, our previous studies further revealed that the reason why application developers use the unstable interfaces is because they cannot find stable interfaces with the functionality that they require. Moreover, in a study we conducted, Eclipse application developers stated that they manually find the functionality from Eclipse. Eclipse being a very large complex software system with a large number of committers, we hypothesize that as developers manually search for the functionality they they require, it is possible that they miss stable interfaces offering the same functionality. To this end, using code clone detection techniques, we analyzed 18 major releases of Eclipse for possible clones. Our findings are three fold: i) we discover that indeed there exist clones in Eclipse, ii) we also discovered that some of the identified clones originate from different Eclipse projects, iii) our findings reveal that there is no significant number of APIs (less than 1%) offering the same or similar functionality as the non-APIs in all Eclipse releases we studied. This reveals that there are very few syntactic clones between API and non-API, thus developers were forced to either use non-API or find an API that exists, that is similar in functionality, but not in syntax.

2013 17th European Conference on Software Maintenance and Reengineering, 2013

Eclipse guidelines distinguish between two types of interfaces provided to third-party developers... more Eclipse guidelines distinguish between two types of interfaces provided to third-party developers, i.e., APIs and non-APIs. APIs are stable and supported, while non-APIs are unstable, unsupported and discouraged as they are subject to arbitrary change or removal without notice. In our previous work, we found that despite the discouragement of Eclipse, the use of non-APIs in Eclipse third-party plug-ins (ETPs) is not uncommon. Furthermore, we found that these non-APIs are the main cause of ETP incompatibilities in forthcoming releases of the Eclipse. In the current work we conducted a survey aiming at understanding why do the ETP developers use non-APIs. We have observed that developers with a level of education of up to master degree have a tendency not to read product manuals/guidelines. Furthermore, while for less experienced developers instability of the non-APIs overshadows their benefits, more experienced developers prefer to enjoy the benefits of non-APIs despite the instability problem. Finally, we have observed that there are no significant differences between Open Source and commercial Eclipse products in terms of awareness of Eclipse guidelines and interfaces, Eclipse product size and updating of Eclipse product in the new SDK releases.

Abstract—Today numerous software systems are being developed on top of frameworks. In this study,... more Abstract—Today numerous software systems are being developed on top of frameworks. In this study, we analyzed the survival of 467 Eclipse third-party plug-ins altogether having 1,447 versions. We classify these plug-ins into two categories: those that depend on only stable and supported Eclipse APIs and those that depend on at least one of the potentially unstable, discouraged and unsupported Eclipse non-APIs. Comparing the two categories of plug-ins, we observed that the plug-ins depending solely on APIs have a very high source ...

2013 17th European Conference on Software Maintenance and Reengineering, 2013

Today, when constructing a new software system, many developers build their systems on top of fra... more Today, when constructing a new software system, many developers build their systems on top of frameworks. Eclipse framework is one such popular and widely adopted framework that has been evolving for over a decade. Like many other evolving software systems, the Eclipse SDK framework has both stable and supported APIs (good interfaces) and unstable, discouraged and unsupported non-APIs (bad interfaces). However, despite being discouraged by Eclipse, in our experience, the usage of bad interfaces is not uncommon. In this thesis, by means of a series of empirical studies, we quantify/qualify some the challenges faced by Eclipse thirdparty plug-in developers in using the interfaces provided by the Eclipse SDK framework. Furthermore, we propose solutions to the identified challenges, like changes in development strategy to both interface providers and interface users. In particular, the lessons learned from this study can provide valuable information in particular to the interface providers, i.e., Eclipse SDK developers, and the interface uses, i.e., ETP developers, in co-evolving the Eclipse framework. In general, the lessons learned can be transferable to other framework ecosystem.

Abstract—Incompatibility between applications developed on top of frameworks with new versions of... more Abstract—Incompatibility between applications developed on top of frameworks with new versions of the frameworks is a big nightmare to both developers and users of the applications. Understanding the factors that cause incompatibilities is a step to solving them. One such direction is to analyze and identify parts of the reusable code of the framework that are prone to change. In this study we carried out an empirical investigation on 11 Eclipse SDK releases (1.0 to 3.7) and 288 Eclipse third-party plug-ins (ETPs) with two main goals: First, to determine the relationship between the age of Eclipse non-APIs (internal implementations) used by an ETP and the compatibility of the ETP. We found that third-party plug-in that use only old non-APIs have a high chance of compatibility success in new SDK releases compared to those that use at least one newly introduced non-API. Second, our goal was to build and test a predictive model for the compatibility of an ETP, supported in a given SDK ...

Social coding platforms centred around git provide explicit facilities to share code between proj... more Social coding platforms centred around git provide explicit facilities to share code between projects: forks, pull requests, cherry-picking to name but a few. Variant forks are an interesting phenomenon in that respect, as it permits for different projects to peacefully co-exist, yet explicitly acknowledge the common ancestry. Several researchers analysed forking practices on open source platforms and observed that variant forks get created frequently. However, today little is known on the motivations for launching such a variant fork. Is it mainly technical (e.g., diverging features), governance (e.g., diverging interests), legal (e.g., diverging licences), or do other factors come into play? In this paper we report the results of an exploratory qualitative analysis on the motivations behind variants creation and maintenance. We surveyed 105 maintainers of different active open source variant projects hosted on GitHub. Our study extends previous findings, identifying a number of fi...

2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)

Eclipse framework provides two interfaces: stable interfaces (APIs) and unstable interfaces (non-... more Eclipse framework provides two interfaces: stable interfaces (APIs) and unstable interfaces (non-APIs). Despite the non-APIs being discouraged and unsupported, their usage is not uncommon. Previous studies showed that applications using relatively old non-APIs are more likely to be compatible with new releases compared to the ones that used newly introduced non-APIs; that the growth rate of non-APIs is nearly twice as much as that of APIs; and that the promotion of non-API to APIs happens at a slow pace since API providers have no assistance to identify public interface candidates. Motivated by these findings, our main aim was to empirically investigate the entire population (2,380K) of non-APIs to find the non-APIs that remain stable for a long period of time. We employ cross-project clone detection to identify whether non-APIs introduced in a given Eclipse release remain stable over successive releases. We provide a dataset of 327K stable non-API methods that can be used by both Eclipse interface providers as possible candidates of promotion. Instead of promoting non-APIs which are too fine-grained, we summarized the non-API methods groups in given classes that are stable together and present class-level non-APIs that possible candidates promotion. We have shown that it is possible to predict the stability of a non-API in subsequent Eclipse releases with a precision of ≥ 56%, a recall of ≥ 96% and an AUC of ≥ 92% and an Fmeasure of ≥ 81%. We have also shown that the metrics of length of a method and number of method parameters in a non-API method are very good predictors for the stability of the non-API in successive Eclipse releases. The results provided can help the API providers to estimate a priori how much work could be involved in performing the promotion.

Empirical Software Engineering

With the rise of social coding platforms that rely on distributed version control systems, softwa... more With the rise of social coding platforms that rely on distributed version control systems, software reuse is also on the rise. Many software developers leverage this reuse by creating variants through forking, to account for different customer needs, markets, or environments. Forked variants then form a so-called software family; they share a common code base and are maintained in parallel by same or different developers. As such, software families can easily arise within software ecosystems, which are large collections of interdependent software components maintained by communities of collaborating contributors. However, little is known about the existence and characteristics of such families within ecosystems, especially about their maintenance practices. Improving our empirical understanding of such families will help build better tools for maintaining and evolving such families. We empirically explore maintenance practices in such fork-based software families within ecosystems o...

Eclipse third-party plug-ins source code

Software developers often need to create variants to accommodate different customer segments. The... more Software developers often need to create variants to accommodate different customer segments. These variants have a common code base but also comprise variant-specific code. A common strategy to create a variant is to clone&own (or fork) an existing repository and then adapt it to the new requirements. This form of reuse has been enhanced with the advent of socialcoding platforms such as GitHub, and package distribution platforms like npm. GitHub offers facilities for forking, pull requests, and cross-project traceability. npm offers facilities for managing package release dependencies and dependents on the distribution platform. Little is known about the maintenance practices of the variants. We therefore performed an exploratory investigation on the evolution of variants, focusing on their technical aspects. We collected variants from the JavaScript ecosystem, whose sources are hosted on GitHub, and whose packages are released on npm. We have identified a total 12,813 variant fork...

Forking is an often used idiom in software ecosystems that allows for the immediate reuse of exis... more Forking is an often used idiom in software ecosystems that allows for the immediate reuse of existing software packages. Further, research shows that forking negatively impacts software quality since it distributes the maintenance effort across several repositories. However, there is a lack of sufficient knowledge exploring the validity and applicability of forking as an approach to solve software quality issues. In this position paper we present a plan to investigate the effectiveness of forking in managing technical debt.

Today, when constructing software systems, many developers build their systems on top of framewor... more Today, when constructing software systems, many developers build their systems on top of frameworks. Eclipse is such a framework that has been in existence for over a decade. Like many other evolving software systems, the Eclipse platform has both stable and supported interfaces (''good'') and unstable, discouraged and unsupported interfaces (''bad''). In this study, we investigate Eclipse interface usage by Eclipse third- party plug-ins (ETPs) based on whether they use bad interfaces or not. The investigations, based on empirical analysis present the following observations. First, we discovered that 44 % of the 512 analyzed Eclipse third-party plug-ins depend on ''bad'' interfaces and that developers continue to use ''bad'' interfaces. Second, we have observed that plug-ins that use or extend at least one ''bad'' interface are comparatively larger and use more func- tionality from Eclipse than those tha...

Proceedings of the 13th International Conference on Predictive Models and Data Analytics in Software Engineering

Context: In recent years, many research studies have shown how human factors play a significant r... more Context: In recent years, many research studies have shown how human factors play a significant role in the quality of software components. Code authorship metrics have been introduced to establish a chain of responsibility and simplify management when assigning tasks in large and distributed software development teams. Researchers have investigated the relationship between code authorship metrics and fault occurrences in software systems. However, we have observed that these studies have only been carried on large software systems having hundreds to thousands of contributors. In our preliminary investigations on Android applications that are considered to be relatively small, we observed that applications systems are not totally owned by a single developer (as one could expect) and that cases of no clear authorship also exist like in large systems. To this end, we do believe that the Android applications could face the same challenges faced by large software systems and could also benefit from such studies. Goal: We investigate the extent to which the findings obtained on large software systems applies to Android applications. Approach: Building on the designs of previous studies, we analyze 278 Android applications carefully selected from GitHub. We extract code authorship metrics from the applications and examine the relationship between code authorship metrics and faults using statistical modeling. Results: Our analyses confirm most of the previous findings, i.e., Android applications with higher levels of code authorship among contributors experience fewer faults.

2018 IEEE International Conference on Software Maintenance and Evolution (ICSME)

Mobile app developers often need to create variants to account for different customer segments, p... more Mobile app developers often need to create variants to account for different customer segments, payment models or functionalities. A common strategy is to clone (or fork) an existing app and then adapt it to new requirements. This form of reuse has been enhanced with the advent of social-coding platforms such as Github, cultivating a more systematic reuse. Different facilities, such as forks, pull requests, and cross-project traceability support clone-based development. Unfortunately, even though, many apps are known to be maintained in many variants, little is known about how practitioners manage variants of mobile apps. We present a study that explores clone-based reuse practices for open-source Android apps. We identified and analyzed families of apps that are maintained together and that exist both on the official app store (Google Play) as well as on Github, allowing us to analyze reuse practices in depth. We mined both repositories to identify app families and to study their characteristics, including their variabilities as well as codepropagation practices and maintainer relationships. We found that, indeed, app families exist and that forked app variants fall into the following categories: (i) re-branding and simple customizations, (ii) feature extension, (iii) supporting of the mainline app, and (iv) implementation of different, but related features. Other notable characteristic of the app families we discovered include: (i) 73 % of the app families did not perform any form of code propagation, and (ii) 74 % of the app families we studied do not have common maintainers.

2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER)

The incredible success of the mobile App economy has been attracting software developers hoping f... more The incredible success of the mobile App economy has been attracting software developers hoping for new or repeated success. Surviving in the fierce competitive App market involves in part planning ahead of time for the success of the App on the marketplace. Prior research has shown that App success can be viewed through its proxy-popularity. An important question, then, is what factors differentiates popular from unpopular Apps? GitHub, a software project forge, and Google Play store, an app market, are both crowdsourced, and provide some publicly available data that can be used to crosslink source code and app download popularity. In this study, we examined how technical and social features of Open Source Software Apps, mined from two crowdsourced websites, relate to App popularity. We observed that both the technical and the social factors play significant roles in explaining App popularity. However, the combined factors have a low effect size in explaining App popularity, as measured by average user rating on Google Play. Interestingly on GitHub, we found that social factors have a higher power in explaining the popularity compared to all the technical factors we investigated.

International Journal of Computer Applications, 2016

Energy efficiency in data center networks is increasingly becoming a gold standard for implemente... more Energy efficiency in data center networks is increasingly becoming a gold standard for implementers. Energy costs are becoming high while performance is highly demanded. And while efforts are directed to the design of energy efficient networks, a number of open issues require addressing including:-scalability, fault tolerance, efficiency in performance though their presence does not outweigh the benefits of networks energy-aware. Truly, we observe that improvements in computer networks hardware performance comes with increasing energy consumption. To address these complementary challenges, this paper technically surveys existing, approaches and techniques (virtualization, energyaware routing, among others), tools, and architectures employed in energy efficient computer networks. We have also provided a thorough review of data centre networks: server centric, switch centric and dual centric architectures with a view to inform developers and implementers of the overhead given architectural choice, identified challenges and opportunities. We conclude upon the survey that dual centric computer networks architectures have various nice properties for practical computer networks and provide flexible choices in designing of computer network architectures.

2016 IEEE 24th International Conference on Program Comprehension (ICPC), 2016

The Eclipse framework is a popular and widely adopted framework that has been evolving for over a... more The Eclipse framework is a popular and widely adopted framework that has been evolving for over a decade. Like many other evolving software systems, the Eclipse framework provides both stable and supported interfaces (APIs) and unstable, discouraged, and unsupported interfaces (non-APIs). However, despite being discouraged by Eclipse, the usage of bad interfaces is not uncommon. Our previous research has confirmed that as Eclipse states, indeed APIs are stable while non-APIs are unstable. Applications using non-APIs face compatibility challenges in new Eclipse releases. Furthermore, our previous studies further revealed that the reason why application developers use the unstable interfaces is because they cannot find stable interfaces with the functionality that they require. Moreover, in a study we conducted, Eclipse application developers stated that they manually find the functionality from Eclipse. Eclipse being a very large complex software system with a large number of committers, we hypothesize that as developers manually search for the functionality they they require, it is possible that they miss stable interfaces offering the same functionality. To this end, using code clone detection techniques, we analyzed 18 major releases of Eclipse for possible clones. Our findings are three fold: i) we discover that indeed there exist clones in Eclipse, ii) we also discovered that some of the identified clones originate from different Eclipse projects, iii) our findings reveal that there is no significant number of APIs (less than 1%) offering the same or similar functionality as the non-APIs in all Eclipse releases we studied. This reveals that there are very few syntactic clones between API and non-API, thus developers were forced to either use non-API or find an API that exists, that is similar in functionality, but not in syntax.

2013 17th European Conference on Software Maintenance and Reengineering, 2013

Eclipse guidelines distinguish between two types of interfaces provided to third-party developers... more Eclipse guidelines distinguish between two types of interfaces provided to third-party developers, i.e., APIs and non-APIs. APIs are stable and supported, while non-APIs are unstable, unsupported and discouraged as they are subject to arbitrary change or removal without notice. In our previous work, we found that despite the discouragement of Eclipse, the use of non-APIs in Eclipse third-party plug-ins (ETPs) is not uncommon. Furthermore, we found that these non-APIs are the main cause of ETP incompatibilities in forthcoming releases of the Eclipse. In the current work we conducted a survey aiming at understanding why do the ETP developers use non-APIs. We have observed that developers with a level of education of up to master degree have a tendency not to read product manuals/guidelines. Furthermore, while for less experienced developers instability of the non-APIs overshadows their benefits, more experienced developers prefer to enjoy the benefits of non-APIs despite the instability problem. Finally, we have observed that there are no significant differences between Open Source and commercial Eclipse products in terms of awareness of Eclipse guidelines and interfaces, Eclipse product size and updating of Eclipse product in the new SDK releases.

Abstract—Today numerous software systems are being developed on top of frameworks. In this study,... more Abstract—Today numerous software systems are being developed on top of frameworks. In this study, we analyzed the survival of 467 Eclipse third-party plug-ins altogether having 1,447 versions. We classify these plug-ins into two categories: those that depend on only stable and supported Eclipse APIs and those that depend on at least one of the potentially unstable, discouraged and unsupported Eclipse non-APIs. Comparing the two categories of plug-ins, we observed that the plug-ins depending solely on APIs have a very high source ...

2013 17th European Conference on Software Maintenance and Reengineering, 2013

Today, when constructing a new software system, many developers build their systems on top of fra... more Today, when constructing a new software system, many developers build their systems on top of frameworks. Eclipse framework is one such popular and widely adopted framework that has been evolving for over a decade. Like many other evolving software systems, the Eclipse SDK framework has both stable and supported APIs (good interfaces) and unstable, discouraged and unsupported non-APIs (bad interfaces). However, despite being discouraged by Eclipse, in our experience, the usage of bad interfaces is not uncommon. In this thesis, by means of a series of empirical studies, we quantify/qualify some the challenges faced by Eclipse thirdparty plug-in developers in using the interfaces provided by the Eclipse SDK framework. Furthermore, we propose solutions to the identified challenges, like changes in development strategy to both interface providers and interface users. In particular, the lessons learned from this study can provide valuable information in particular to the interface providers, i.e., Eclipse SDK developers, and the interface uses, i.e., ETP developers, in co-evolving the Eclipse framework. In general, the lessons learned can be transferable to other framework ecosystem.

Abstract—Incompatibility between applications developed on top of frameworks with new versions of... more Abstract—Incompatibility between applications developed on top of frameworks with new versions of the frameworks is a big nightmare to both developers and users of the applications. Understanding the factors that cause incompatibilities is a step to solving them. One such direction is to analyze and identify parts of the reusable code of the framework that are prone to change. In this study we carried out an empirical investigation on 11 Eclipse SDK releases (1.0 to 3.7) and 288 Eclipse third-party plug-ins (ETPs) with two main goals: First, to determine the relationship between the age of Eclipse non-APIs (internal implementations) used by an ETP and the compatibility of the ETP. We found that third-party plug-in that use only old non-APIs have a high chance of compatibility success in new SDK releases compared to those that use at least one newly introduced non-API. Second, our goal was to build and test a predictive model for the compatibility of an ETP, supported in a given SDK ...