Politecnico di Torino Andrea Capiluppi Characterizing the Open Source Software Process: a Horizontal Study A. Capiluppi, P. Lago, M. Morisio

Politecnico di Torino2 Outline Rationale behind the current study Methodology Conclusions Actual and future work

Politecnico di Torino3 Rationale Most Open Source analyses focus on a single, flagship project (Linux, Apache, GNOME) Limitation: the conclusions are based on a ‘vertical’ study there is a lack of ‘horizontal’ studies a pool of projects a wider area of interest

Politecnico di Torino4 Methodology Choice of projects Attributes definition Coding Analysis

Politecnico di Torino5 Choice of projects: repository Selected FreshMeat repository FreshMeat ( is focused on Open Source development since 1996http://freshmeat.net It gathers thousands of projects, either doubled on the pages of SourceForge ( or hosted on FreshMeat only. FreshMeat lists more than projects (many inactive)

Politecnico di Torino6 Choice of projects: sampling I From to how? FreshMeat organizes projects by filters and categories Filter = “Topic” Categories = {“Internet”, “Database”, “Multimedia”,…} Other filters: Programming language, Topic (i.e. application domain), Status of Evolution, etc.

Politecnico di Torino7 Choice of projects: sampling II We picked randomly a number of projects through the “Status” filter Rationale: limited number of categories associated {“Planning”, “PreAlpha”, “Alpha”, “Beta”, “Stable”, “Mature”} The overall count is 406 projects

Politecnico di Torino8 Attribute definition Age Application domain Programming language Size [KB] Number of developers Stable and transient developers Number of users Red: defined by FreshMeat Black: defined by us Modularity level Documentation level Popularity Status Success of project Vitality

Politecnico di Torino9 Coding Each attribute was coded twice, to capture evolutive trends First observation: January 2002 Second observation: July 2002

Politecnico di Torino10 Analysis Here we discuss: Application domain issues Developers [stable & transient] issues Subscribers (as users) issues Code size issues

Politecnico di Torino11 Application domain distribution

Politecnico di Torino12 Attributes: project’s developers We evaluate how many people write code for an application External contributions are always credited in special-purpose files, or in the ChangeLog We distinguish between Stable developers Transient developers Core team: more than one stable developer Manual inspections and pattern-recognition scripts

Politecnico di Torino13 Developers over projects We observe: 72% of projects have a single stable developer 80% of projects have at most a number of 10 developers

Politecnico di Torino14 Developers distribution over projects

Politecnico di Torino15 Definition: clusters of developers Cluster 1: 1 to 3 developers (64.5%) Cluster 2: 4 to 10 developers (20%) Cluster 3: 11 to 20 developers (9.5%) “Average” nr. of stable dev: 2 “Average” nr. of transient dev: 3 Cluster 4: more than 20 developers (6%) “Average” nr. of stable dev: 6 “Average” nr. of stable dev: 19

Politecnico di Torino16 Productivity vs. ‘global’ developers

Politecnico di Torino17 Productivity vs. ‘stable’ developers

Politecnico di Torino18 Code variation over clusters

Politecnico di Torino19 Attributes: subscribers We use some publicly available data to gather some proxy about users Users ~ Mailing List subscribers (public datum) It’s not a monotonic measure: subscribers can join and leave as well We have a measure of users in two different observations

Politecnico di Torino20 Distribution of subscribers over project Around 42% of projects have at most 1 subscriber-user

Politecnico di Torino21 Users evolution

Politecnico di Torino22 Attributes: project’s size We evaluate the code of each project twice Code evaluated is contained in packages. We exclude from the count: Auxiliary files: documentation, configuration files, GIF files, etc. Legacy code: inherited libraries (e.g. Gnome macros), internationalization code

Politecnico di Torino23 Distribution of code size over projects

Politecnico di Torino24 Evolutive observations of size changes

Politecnico di Torino25 Conclusions I The vast majority of projects are developed by only one developer Adding people to a project has small effect on productivity (i.e. code per developer) Open Source software is made by experts for experts (72% of horizontal projects have more than 10 developers) 58% of projects didn’t change their size 63% of projects had a change within 1%

Politecnico di Torino26 Conclusions II Java is relevant for 8% of the projects, C/C++ for 56%, PERL with Python for 20% Observations from flagship projects (Apache, Linux, Gnome) are not confirmed for an average Open Source project Several projects are white noise: to be filtered out Huge amount of data on public repositories: empirical researchers have an invaluable resource of software data

Politecnico di Torino27 Current and future work Eliminating white noise: only projects in cluster 3 and 4 have been selected Deeper analysis: the whole story of a project is being studied What can we say with respect of conclusions on bigger OS projects? What can be said about OSS evolution compared with traditional software evolution?

Politecnico di Torino28 Attributes: age of a project Age: time interval from a project’s first posting on the FreshMeat pages This measure is a proxy of its actual development time We are ignoring all its past history Most open source projects have a short history behind Most open source projects keep a ChangeLog with first releases date

Politecnico di Torino29 Attributes: modularity How we define the modules composing an application? We define three levels for it: Poor modularization (at most 1 folder containing source code) Average modularization (at most 2 folders, typically ‘src’ and ‘lib’ folders) Adequate modularization (more than 3 folders)

Politecnico di Torino30 Attributes: popularity and vitality Popularity: composite measure for success in users of an application Vitality: composite measure for success in development of an application Together they give a first definition in the success of a project We are interested in observe how these two attributes evolve together