Brief Description

Our goal is to provide a tool that will enable other researchers and practitioners to conduct Software Engineering research and practice in a far more innovative and efficient way. To do what, we want to make Open Source Software (OSS) computable.

There is a very large (and growing) amount of OSS on the web right now. This software can be used for all kinds of empirical analyses, quality assessments, testing of hypotheses on Software Engineering theories and methods. This potential is hampered by two factors:

• Although OSS code is available, those wishing to analyse it have to download the code from the primary repository; then they typically have to write code that analyses it, for instance by computing some metrics on it; and then they have to run it.

• The above steps are usually repeated as often as somebody else wants to analyse the same piece of software. That is, a metric calculator for a certain OSS project is not usually available (or known) to other people wishing to do research on the same project. One may wonder how different wc implementations for different OSS projects have been written the last few years.

• During a lifetime spanning multiple decades, several OSS projects have amassed gigabytes of data worth studying. The computational cost for processing such large volumes of data is not trivial. For fast experiment turnover, researchers must design their analysis tools to exploit modern multiprocessor machines. However those efforts are often not enough, as the capacities of single machines are easily saturated by the processed data volumes.

• Each project uses its own combination of SCM, mailing list, BTS and other project management tools, such as Wikis and documentation systems. Without the appropriate abstractions, it is challenging to build tools that can process data from various projects at the same time.

• Empirical studies are often conducted in several phases, and a diverse set of tools can be applied in each phase. Intermediate results must be stored and retrieved efficiently in formats suitable for use by chains of tools.

Moreover, people developing metric measuring tools are often the same people who will use the metrics. This is not necessary. We propose to separate the two concerns: having the ability to ask questions on a piece of software is an enabler for research and innovation on Software Engineering. We also want to go one step further: asking questions should be so easy that researchers should be able to do it interactively in an exploratory manner.

WolframAlpha is an interesting example of what can be achieved by making information executable. In the same vein, we want to make Software Engineering knowledge, taken from OSS repositories, executable. Researchers should be able to ask questions like:

• What is the metric X for project P?

• How does metric X for project P correlate with metric Y for project P?

• How does metric X for project P correlate with metric Y for project P?

• Where does metric X in project P exceed value V?

and so on.

To make such a tool meaningful, the set of metrics that could be calculated should be open-ended. In fact, the tool should be developed in such a way that interested researchers could easily create their own metrics and offer them to the tool, so that the set of metrics offered by the tool will be increasing with the number of people using and contributing to it. At the same time, the execution of contributed metrics should take into account security issues. Virtual machines and sandboxing should be employed to make them safe to execute.