Browsing by Author "Businge, John"
Now showing 1 - 18 of 18
Results Per Page
Sort Options
Item Analyzing the Eclipse API Usage: Putting the Developer in the Loop(IEEE, 2013) Businge, John; Serebrenik, Alexander; van den Brand, MarkEclipse 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.Item Blockchain-Oriented Software Variant Forks: A Preliminary Study(IEEE, 2022) Rocha, Henrique; Businge, JohnIn collaborative social development platforms such as GitHub, forking a repository is a common activity. A variant fork wants to split the development from the original repository and grow towards a different direction. In this preliminary exploratory research, we analyze the possible reasons for creating a variant fork in blockchain-oriented software. By collecting repositories in GitHub, we created a dataset with repositories and their variants, from which we manually analyzed 86 variants. Based on the variants we studied, the main reason to create a variant in blockchain-oriented software is to support a different blockchain platform (65%).Item Can We Find Stable Alternatives For Unstable Eclipse Interfaces?(IEEE, 2016) Kawuma, Simon; Businge, JohnThe 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 t hat a s E clipse s tates, i ndeed A PIs a re 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 s table i nterfaces w ith t he f unctionality t hat they require. Moreover, in a study we conducted, Eclipse application developers stated that they manually find t he 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 a re t hree fold: i ) we discover that indeed there exist clones in Eclipse, ii) we also discovered that some of the identified c lones o riginate f rom different Eclipse projects, iii) our findings r eveal t hat t here i s 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 a n API t hat e xists, t hat i s similar in functionality, but not in syntax.Item Clone-Based Variability Management in the Android Ecosystem(IEEE, 2018) Businge, John; Openja, Moses; Nadi, Sarah; Bainomugisha, Engineer; Berger, ThorstenAbstract—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.Item Co-evolution of the Eclipse SDK Framework and its Third-party Plug-ins(IEEE, 2013) Businge, JohnToday, 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.Item Code Authorship and Fault-proneness of Open-Source Android Applications : An Empirical Study(International Conference on Predictive Models and Data Analytics in Software Engineering, 2017) Businge, John; Kawuma, Simon; Bainomugisha, Engineer; Khomh, Foutse; Nabaasa, EvaristIn 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.Item Compatibility Prediction of Eclipse Third-Party Plug-ins in New Eclipse Releases(IEEE, 2012) Businge, John; Serebrenik, Alexander; van den Brand, MarkIncompatibility 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 thirdparty 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 release in a newer SDK release. Our findings produced 23 statistically significant prediction models having high values of the strength of the relationship between the predictors and the prediction (logistic regression R2 of up to 0.810). In addition, the results from model testing indicate high values of up to 100% of precision and recall and up to 98% of accuracy of the predictions. Finally, despite the fact that SDK releases with API breaking changes, i.e., 1.0, 2.0 and 3.0, have got nothing to do with non-APIs, our findings reveal that non-APIs introduced in these releases have a significant impact on the compatibility of the ETPs that use them.Item Eclipse API usage: the good and the bad(Software Quality Journal, 2015) Businge, John; Serebrenik, Alexander; van den Brand, Mark G. J.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 thirdparty 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 functionality from Eclipse than those that use only ‘‘good’’ interfaces. Third, the findings show that the ETPs use a diverse set of ‘‘bad’’ interfaces. Fourth, we observed that the reason why the bad interfaces are being eliminated from the ETPs’ source code is, because (ETP developers believe) these non-APIs will cause incompatibilities when a version of the ETP is ported to new Eclipse SDK release. Finally, we observed that when developers eliminate problematic ‘‘bad’’ interfaces, they either re-implement the same functionality in their own API, find equivalent SDK good interfaces, or completely delete the entities in the ETPs’ source code that use the functionality from the ‘‘bad’’ interfaces.Item An Empirical Investigation of Forks as Variants in the npm Package Distribution(BENEVOL, 2020) Businge, John; Decan, Alexandre; Zerouali, Ahmed; Mens, Tom; Demeyer, SergeSoftware 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 forks from the JavaScript ecosystem. In general, we observed that mainlines have more number of package releases, package dependencies, dependent packages and dependent projects compared to their variant counterparts. However, it is still interesting that some variants have quite a considerable number of package releases and dependent packages/projects; in a some cases even more than their mainline counterparts.Item An Empirical Study of Technical Debt Management as a Motivation for Forking(In BENEVOL, 2020) Njima, Mercy; Businge, John; Demeyer, SergeForking 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.Item An Empirical Study of the Evolution of Eclipse Third-party Plug-ins(International Workshop on Principles of Software Evolution (IWPSE), 2010) Businge, John; Serebrenik, Alexander; van den Brand, MarkSince the inception of Lehman's software evolution laws in the early 1970s, they have attracted signi cant attention from the research community. However, to our knowledge, no study of applicability of these laws on the software sys- tems that exhibit constrained evolution process has been carried out so far. In this paper we take a rst step in this direction and investigate the constrained evolution of 21 Eclipse third{party plug-ins. We investigate the trends followed by the plug-ins dependencies on Eclipse over time. The study spans 6 years of the evolution of Eclipse evolving from release 3.0 to release 3.5. Our ndings con rm the laws of continuing change, self regulation and continuing growth when metrics related to dependencies between the plug-ins and the Eclipse Architecture are considered. Unlike this, the conservation of familiarity law was not con rmed and the results for the declining quality law were inconclusive.Item How Stable are Eclipse Application Framework Internal Interfaces?(IEEE, 2019) Businge, John; Kawuma, Simon; Openja, Moses; Bainomugisha, Engineer; Serebrenik, lexanderEclipse 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 promotionItem How Stable are Eclipse Application Framework Internal Interfaces?(IEEE, 2019) Businge, John; Kawuma, Simon; Openja, Moses; Bainomugisha, Engineer; Serebrenik, AlexanderEclipse 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.Item Reuse and maintenance practices among divergent forks in three software ecosystems(Empirical Software Engineering, 2022) Businge, John; Openja, Moses; Nadi, Sarah; Berger, ThorstenWith 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 of open-source software. Our focus is on three of the largest software ecosystems existence today: Android, .NET, and JavaScript. We identify and analyze software families that are maintained together and that exist both on the official distribution platform (Google play, nuget, and npm) as well as on GitHub , allowing us to analyze reuse practices in depth. We mine and identify 38 software families, 526 software families, and 8,837 software families from the ecosystems of Android, .NET, and JavaScript, to study their characteristics and code-propagation practices. We provide scripts for analyzing code integration within our families. Interestingly, our results show that there is little code integration across the studied software families from the three ecosystems. Our studied families also show that techniques of direct integration using git outside of GitHub is more commonly used than GitHub pull requests. Overall, we hope to raise awareness about the existence of software families within larger ecosystems of software, calling for further research and better tools support to effectively maintain and evolve them.Item Studying Android App Popularity by Cross-Linking GitHub and Google Play Store(IEEE, 2019) Businge, John; Openja, Moses; Kavalery, David; Bainomugisha, Engineer; Khomh, Foutse; Filkov, VladimirThe 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.Item Survival of Eclipse Third-party Plug-ins(IEEE, 2012) Businge, John; Serebrenik, Alexander; van den Brand, MarkToday 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 compatibility success rate compared to those that depend on at least one of the non-APIs. However, we have also observed that recently released plug-ins that depend on non-APIs also have a very high forward source compatibility success rate. This high source compatibility success rate is due to the dependency structure of these plug-ins: recently released plug-ins that depend on non-A PIs predominantly depend on old Eclipse nonAPIs rather than on newly introduced ones. Finally, we showed that the majority of plug-ins hosted on SourceForge do not evolve beyond the first year of release.Item Tools, Architectures and Techniques for Monitoring Energy Efficiency in Computer Networks: State of the Art Survey(International Journal of Computer Applications, 2016) Mwavu, Rogers; Mugonza, Robert; Businge, JohnEnergy 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, energy-aware 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.Item Variant Forks - Motivations and Impediments(IEEE, 2022) Businge, John; Zerouali, Ahmed; Decan, Alexandre; Mens, Tom; Demeyer, Serge; De Roover, CoenSocial 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 they permit 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, 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? We report the results of an exploratory qualitative analysis on the motivations behind creating and maintaining variant forks. We surveyed 105 maintainers of different active open source variant projects hosted on GitHub. Our study extends previous findings, identifying a number of fine-grained common motivations for launching a variant fork and listing concrete impediments for maintaining the co-existing projects.