Linear systems occur throughout engineering and the sciences, most notably as differential equations. In many cases the forcing function for the system is unknown, and interest lies in using noisy observations of the system to infer the forcing, as well as other unknown parameters. In differential equations, the forcing function is an unknown function of the independent variables (typically time and space), and can be modelled as a Gaussian process (GP). In this paper we show how the adjoint of a linear system can be used to efficiently infer forcing functions modelled as GPs, after using a truncated basis expansion of the GP kernel. We show how exact conjugate Bayesian inference for the truncated GP can be achieved, in many cases with substantially lower computation than would be required using MCMC methods. We demonstrate the approach on systems of both ordinary and partial differential equations, and show that the basis expansion approach approximates well the true forcing with a modest number of basis vectors. Finally, we show how to infer point estimates for the non-linear model parameters, such as the kernel length-scales, using Bayesian optimisation.

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 nonAPIs introduced in a given Eclipse release remain stable over successive releases. We provide a dataset of 327K stable nonAPI methods that can be used by both Eclipse interface providers as possible candidates of promotion. Instead of promoting nonAPIs 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 F-measure of ≥ 81%. We have also shown that the metrics of length of a method and number of method parameters in a nonAPI 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.

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 cross-link 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.

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 code-propagation 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) 72.7% 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.

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.

SUMMARY The iPhone SDK provides a powerful platform for the development of applications that make use of iPhone capabilities, such as sensors, GPS, Wi‐Fi, or Bluetooth connectivity. We observe that so far the development of iPhone applications has mostly been restricted to using Objective‐C. However, developing applications in plain Objective‐C on the iPhone OS suffers from limitations, such as the need for explicit memory management and lack of syntactic extension mechanism. Moreover, when developing distributed applications in Objective‐C, programmers have to manually deal with distribution concerns, such as service discovery, remote communication, and failure handling. In this paper, we discuss our experience in porting the Scheme programming language to the iPhone OS and how it can be used together with Objective‐C to develop iPhone applications. To support the interaction between Scheme programs and the underlying iPhone APIs, we have implemented a language symbiosis layer that enables programmers to access the iPhone SDK libraries from Scheme. In addition, we have designed high‐level distribution constructs to ease the development of distributed iPhone applications in an event‐driven style. We validate and discuss these constructs with a series of examples, including an iPod controller, a maps application, and a distributed multiplayer Scrabble‐like game. We discuss the lessons learned from this experience for other programming language ports to mobile platforms. Copyright © 2011 John Wiley & Sons, Ltd.