Overview. Previous research. What is software evolution? Lehman s Laws in a nutshell. Lehman s examples

Transcription

1 Evolution in Open Source Software: A Case Study Michael W. Godfrey Qiang Tu Overview What is software evolution? Why should we care? Previous research A case study: The Linux OS Observations, hypotheses, and future research Software Architecture Group University of Waterloo What is software evolution? Evolution is what happens while you re busy making other plans. Usually, we consider evolution to begin once the first version has been delivered: Previous research Lehman s laws Parnas on software geriatrics Eick et al. on code decay (1 MLOC telecom) Gall et al. (1 MLOC telecom) Munro, Burd et al. (2 MLOC gcc) Maintenance is the planned set of tasks to effect changes. Evolution is what actually happens to the software. Lehman s Laws in a nutshell Observations: (Most) useful software must evolve or die. As a software system gets bigger, its resulting complexity tends to limit its ability to grow. Development progress/effort is (more or less) constant; growth is at best constant. Advice: Need to manage complexity. Do periodic redesigns. Treat software and its development process as a feedback system (and not as a passive theorem). Lehman s examples 1

2 A case study in evolution: The Linux OS A case study in evolution: The Linux OS It s Linux! Large system, very stable, many releases over several years, many developers Growing mainstream adoption Open source development model Interesting phenomenon in itself Easy to track, can publish results, many experts Not much previous study Linux background Linux v1. released March source files, 165 KLOC, i386 only Linux v released January source files, 2.2 MLOC, 1 hardware architectures supported, over 3 developers credited Maintained along two parallel paths: development and stable Methodology Examined 96 versions of Linux 34 of the 67 stable releases 62 of the 369 development releases All measures considered only.c/.h files contained in the tarball Counted LOC using wc l and an awk script that ignored coents and blank lines Counted # of fcns/vars/macros using ctags Architectural model (SSs hierarchy) based on default directory structure We plotted growth against calendar time Lehman suggests plotting growth against release number Growth of compressed tar file Growth of # of source files 2,, 6 Size in bytes 18,, 16,, 14,, 12,, 1,, 8,, 6,, 4,, Development releases (1.1, 1.3, 2.1, 2.3) Stable releases (1., 1.2, 2., 2.2) # of source code files (*.[ch] ) Development releases (1.1, 1.3, 2.1, 2.3) Stable releases (1., 1.2, 2., 2.2) 2,, Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 2

3 Growth of # of global fcns, variables, and macros Growth of Lines of Code (LOC) 14, 2,5, Total LOC ("wc -l") -- development releases # of global fcns, variables, and macros 12, 1, 8, 6, 4, 2, Development releases (1.1, 1.3, 2.1, 2.3) Stable releases (1., 1.2, 2., 2.2) Total LOC 2,, 1,5, 1,, 5, Total LOC ("wc -l") -- stable releases Total LOC uncoented -- development releases Total LOC uncoented -- stable releases Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Average/median.c file size Average/median.h file size Uncoented LOC Average.c file size -- dev. releases Average.c file size -- stable releases Median.c file size -- dev. releases Median.c file size -- stable releases Uncoented LOC Average.h file size -- dev. releases Average.h file size -- stable releases Median.h file size -- dev. releases Median.h file size -- stable releases Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Growth of major SSs (dev. releases) SS LOC as percentage of total system 1,2, 7. Total uncoented LOC 1,, 8, 6, 4, 2, drivers arch include net fs Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Percentage of total system uncoented LOC 6. drivers 5. arch include net 4. fs Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 3

4 SS LOC as percentage of total system (ignoring drivers) Growth of small core SSs 3. 9 Percentage of total system uncoented LOC arch include net fs Total uncoented LOC Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Growth of arch SSs Growth of drivers SSs 4, 3, Total uncoented LOC 35, 3, 25, 2, 15, 1, arch/ppc/ arch/sparc/ arch/sparc64/ arch/m68k/ arch/mips/ arch/i386/ arch/alpha/ arch/arm/ arch/sh/ arch/s39/ Total uncoented LOC 25, 2, 15, 1, drivers/net drivers/scsi drivers/char drivers/video drivers/isdn drivers/sound drivers/acorn drivers/block drivers/cdrom drivers/usb drivers/"others" 5, 5, Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Observations and hypotheses Growth along devel. path is super-linear y =.21*x^ *x + 9,55 r2=.997 y = size in LOC x = days since v1. r2 is coefficient of determination using least squares [Lehman/Turski s model: y = y + E/y^2 < y + x*e/y^2 ] Linux s strong growth is continuing. This is stronger growth at MLOC level than observed by others (Lehman, Gall), even for other OSs. Why has Linux been able to continue its geometric growth? Core code quality is carefully maintained Architecture/problem domain It s largely drivers Much of the code is parallel It s not as big as you might think Vanilla configuration used only 15% of files Development model (OSD) and its sociology Popularity and visibility has encouraged outsiders (both hackers and industry) to contribute 4

5 Growth of fetchmail [Raymond] Growth of pine ( client) # of Modules Jan-93 Jun-94 Oct-95 Mar-97 Jul-98 Dec-99 Apr-1 # of Modules Growth of X Windows X11R6 X11R6.1 X11R5 X11R3 X1R4 X11R2 X1R3 X11R1 Growth of gcc/g++/egcs 1 X11R6.3 9 X11R6.4 # of modules g++ gcc 5 egcs Nov-84 Aug-87 May-9 Jan-93 Oct-95 Jul-98 Apr-1 1 Aug-87 Dec-88 May-9 Sep-91 Jan-93 Jun-94 Oct-95 Mar-97 Jul-98 Dec-99 Apr-1 16, Growth of vim (text editor) 31. vim avg % coents and blank lines per file Total LOC 14, 12, 1, 8, 6, 4, 2, Total LOC ("wc -l") Total LOC (ignoring coents and blank lines) Average percent coents + blank lines May 199 Sep 1991 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr May 199 Sep 1991 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 5

6 Uncoented LOC vim avg/median file size Average uncoented LOC per source file Median uncoented LOC per source file vim s architecture May 199 Sep 1991 Jan 1993 Jun 1994 Oct 1995 Mar 1997 Jul 1998 Dec 1999 Apr 21 Hypotheses Factors affecting evolution include Size and age of system Use of traditional sw. eng. principles during development PLUS Problem domain Problem complexity, multi-platform, multi-features Software architecture Process model Sociology, market forces, and acts-of-god Software evolution research: What next? So far, we have examined only growth. More case studies needed Qualitative and quantitative Industrial and open source systems Different problem domains, architectures Supporting tools to aid analysing, visualizing, and querying program evolution More than just RCS and perl Support for architecture repair Codified knowledge: Why and how does software change? Build catalogue of change patterns and evolutionary narratives Codified knowledge Mature engineering disciplines codify knowledge and experience. Arguably, this is lacking in software engineering. Software architecture styles [Shaw] Design patterns [GoF] Codified knowledge of how and why programs evolve: Evolutionary narratives [Godfrey] Long term, coarse granularity Change patterns Short term, fine granularity Change patterns and evolutionary narratives Phenomena observed in Linux evolution Bandwagon effect Contributed third party code Mostly parallel enables sustained growth Clone and hack Careful control of core code; more flexibility on contributed drivers, experimental features 6