ETJOURNALoFENGINEERING&TECHNOLOGY

Autumn 2010coNcoL{)I

0)NNNZ(J)(J)Impact of Internal Dynamics

on quality of opensource Softwares

KumudArora

Abstract

Software product is a critical and strategic asset in anorganization's business. The challenge is to developmore complicated software products within theconstraints of time and resources without the sacrifice ofquality.

In this article, some important software characteristicsthat contribute to the quality in the OSS are explored.Studies on OSS have mainly examined a small number oflarge, well-known and successful case studies [5}. Theprior studies on OSS quality promoting factors have beenextended. More specifically, what attributes must bepossessed by quality-related interventions for them to befeasibly adopted in open source practice are analyzed.The model for impact of parameters promoting quality inOSS is developed and empirically tested using the datacollected from OSS projects hosted at the Source forge.Sample includes varieties of projects ranging from thelarge to small projects and the projects that aresuccessful and projects that do not progress well. Fewopen source software criteria used for quality evaluationare: Software Size in terms of Source line of code (SLOC),Percentage of lines of comments with respect to thenumber of lines of code (PerCM) describes the selfdescriptiveness of the code. Number of releases, bugtracking, bug removal pattern and software maturity index(SMI), which is an indication of the stability of the softwareproduct.

Key Words: OSS(Open source software) , OSSO (Opensource software development)

INTRODUCTION

In countries with a growing economy where

massive IT deployments cannot be of very highbudgets, an Open Source Software (aSS)approach can be used as a rescue measure.With the rising costs of hardware, software andassociated licensing fees, the IT community isforced to review their options with respect toimplementing innovative technology solutionsother than proprietary systems. The alternativeto proprietary systems coming to the forefront isOpen Source Software. The concept of freesoftware can be traced back to free softwarefoundation, founded by Richard Stallman, aresearcher in MIT who developed anddistributed software under general publiclicense history (GPL) while ass, a paradigmshift from the closed the software product, isslowly revolutionizing the processes involved inthe software development life cycle. BrucePerens defined a set of guidelines which hecalled as OSI. ass isa general term to describe asub culture or community that works incollaboration with each other using internet as amedium of communication. The philosophy ofFree Software is not about cost. The theorybehind Free Software is when the code isavailable to read, only then can innovation trulyoccur. ass grants not only the developers butalso the users, who are potential developers, the

11"YTr-~right to read and change the source code. OSSI~""""'"

Senior Lecturerlnderprastha Engineering CollegeGhaziabad

development has been conceptualized as aphenomenon at community and team/grouplevel. OSS provides an ongoing project to newdevelopers. Developers, users and users turneddevelopers form a community of practiceinformally bound by their common interests andpractices in a specific domain. Communitymembers regularly interact with each other forknowledge sharing. Learning is one of the majormotivational forces that attracts softwaredevelopers and users to participate on OSSdevelopment and to become members of theOSS community. Eric states that developers areattracted towards open source developmentbecause that gives an opportunity todemonstrate their ability. When theprogrammer's code gets accepted, it booststheir ego and they get recognized for their effortsin the community. Peer recognition creates areputation and a reputation as a goodprogrammer is a great motivating factor for theprogrammer [11]. The distinction between theusers and developers is very little. Stricthierarchical structures do not exist in OSScommunities; the structure of OSS communitiesis not completely flat.

Although the evolution of an OSS system is notwell planned, "giving users of a product accessto its source code and the right to createderivative works", it allows them to helpthemselves, and encourages natural productevolution as well as preplanned product design[14] "Research has assessed the output ofindividual OSS projects and examined how thedynamics within OSS projects influence thedevelopment of a software product (e.g.:[7,25]).Some specific indicators applied to commercialsoftware projects, e.g.being on time, on budgetand meeting specifications ,may not be easilyapplied in the OSS setting. In an OSS settingthere may be no prior budget, timeline or set ofspecifications [25]. Also OSS often depends onvolunteer labor, the extent to which the projectattracts and retains developers. Software quality

Autumn 2010

is one of the most important metrics for successof a software project. Barry Boehm definessoftware quality as "Achieving high levels of usersatisfaction, portability, maintainability,robustness and fitness for use" [20]. Jonesrefers to quality as "the absence of defects thatwould make software either stop completely orproduce unacceptable results" [21]. Howeverthese definitions of quality cannot be applieddirectly to OSS. Unlike close software systems,user requirements are not formally available inOSS. The OSS phenomenon derives its strengthby harnessing the active participation from coredevelopers, peripheral groups and beta testers.

Issues for OSSD and 055 dependability

The informal OSS approach is in contrast withthe more formal software engineeringprocesses. In OSS, tools are geared towardsenhancing human collaboration and co-ordination during the development activities[31 ][32], whereas, trad itionally, softwareengineering has typically been more orientedtowards reducing and deskilling the human roleof the developer through tool-support andmethods that automate the softwareconstruction task wherever possible. At theprocess level, the OSS approach is notsubjected to the same level of negative externalprocess constraints of time and budget that canoften subtly undermine the development ofdependable systems within an organizationalsetting. Furthermore, despite thecharacterizations of the OSS approach as beinghighly ad-hoc and chaotic, OSS projects appearto be highly organized, in many cases, andprovide tool-support focused upon enhancinghuman collaboration, creativity, skill andlearning - considered vital in developingtrustworthy systems. However, the five mostimportant issues with Open Source softwaredevelopment are as follows:

a) User interface design: In OSSD the interfaceis not intuitive, as open source developersbelieve in "Programming forthe self."

ETJOURNALoFENGINEERING&TECHNOLOGY

b) Documentation: In Open Source projectsthe documentation is usually intended to bea general guide rather than a completemanual that can guide a novice user andhelps the user to figure out how to dosomething. Open Source software coredocumentation is found in usenet articles,bulletin boards and chat logs.

c) Feature-centric development: In OSSD, it'sthe individual programmer who wants toadd the feature to a project. With so muchemphasis on features, sometimes thefundamental aspects of a programmingproject (like coding standards, security,project direction) go missing.

d) Programming for the self: Open Sourceprojects of community members investtime only in building the features theythemselves would want to use rather thanbe audience-specific.

e) Vulnerability to attacks: A potential problemparticularly associated with ass is thevulnerability to attacks by distribution ofmaliciously altered versions of softwaresystems.

OSS Dependability

ass dependability is concerned with how suchsystems can be designed and developed toprovide an acceptable continuity of service inthe event of such faults giving rise to errors thatmay affect the expected delivery of service. Theimpairments of dependability are concernedwith faults, errors and failures .There exists acollection of methods and techniques topromote the ability to deliver a service on whichreliance can be placed and to establishconfidence in the system's ability to helpaccomplish:

a) Fault prevention (to prevent faultoccurrence or introduction)

b) Fault removal [to reduce the presence(number or seriousness) offaults]

Autumn 2010

c) Fault tolerance (to provide a servicecomplying with the specification in spite offaults)

d) Fault forecasting (to estimate the presentnumber, the future incidence and theconsequences offaults).

In open-source development process since thenumber of contributors are more, there is anincreased bug finding ability through massivepeer reviews of submitted source-code. Thiswas also characterized by [8] in his seminalpaper on evaluating the open-source softwaredevelopment approach as: " Given enougheyeballs, all bugs are shallow.". This informalapproach to using human diversity for bugfinding was, however, exemplified much earlierby Weinberg, 1971 in his "ego lessprogramming" philosophy. The voluntary natureof open-source, developers naturally"gravitates" to software development work; theyare naturally interested and/or alreadyknowledgeable about performing [Lang, 2000].This, combined with the reality that open-sourcedevelopers are also users of the software theydevelop [Gacek et al., 2001] reveals that open-source developers have an intrinsicallyenhanced understanding and knowledge of theuser-domain in which the software will bedeployed.

Proposed framework depicting interrelationof internal dynamics that promote quality ofOSS

ass projects exhibit high quality despite theabsence of defined users, requirements, costsor schedules. Research suggests manypotential factors that may influence bothdevelopment and usage success. assdevelopment has been conceptualized as aphenomenon at the community [2],organizational [10] and team/group level [8].The work of Stewart [29]suggests a multifacetedunderstanding of success in ass from both adevelopment perspective [i.e. success in termsof attracting inputs and producing and usagep..A-u....;;;;-.J

perspective (i.e: success in terms of userinterest, adoption and impact related to specificOSS projects)]. This kind of success may beindicated by such factors as the number ofdevelopers involved, the level of project activity(e.g., bug fixes, patches provided, new featuresand software releases), or project developmentstatus (e.g., alpha testing, beta testing,production etc) [3, 27]. A circular framework isproposed for the factors that affect/promote thequality of OSS .In this framework five factorshave been taken:

A) Development team size

B) Language and OSSD tools familiarity

C) Bug Fixing Time

D) Documentation within open source code

E) Adaptive and perfective maintenance

All these factors are interrelated to each other.Increase or decrease in any of the factorsimpacts the other.

Figure 1. Framework of internal dynamics of OSS

The proposed framework is based upon thequantitative data analysis of the various opensource projects of the sample taken. In the datacollection stage, few target open source projectswere selected following Source Forge's "Mostactive" rank list as of May 2007. To rank projects

Autumn 2010

according to activities, Source Forge.net usesan activity measure. It takes a number ofdownloads, number of times mentioned in theforum and other measures into considerationand combines them to form an activity index.Most F/OSS project data is available as by-products of development, maintenance andsystem-use activities in F/OSS communities.Ten open source projects (A,B,C,D,E,F,G,H,I,J)were choosen for samples with the developmentlanguage varying from C+ +, Java, C# ,Python,Pearl,Javascript to PL/SQL. The topics of theprojects varied from file sharing,instantmessaging, gaming and ERP to securitysystems. Actual names of the projects were notrevealed to follow standard softwareengineering ethics [3].

Impacts of Internal Dynamics on OSS Quality

The timeline of the open source project is oftencharacterized by three distinct phases: Initialdevelopment phase(Phase I), user initiatedchange requests due to ad hoc partneringbetween the developers(Phase II),establishment and re-factoring of the opensource development project (Phase III). Thequantitative analysis of the archival data of theproject is correlated with the evolution of theproject functionality through the three-phasedtimeline through the following parameters:

Impact of Development Team Size

Since the FLOSS development process relies oncontributions from active users as well as coredevelopers, development team size reflectedthe size of this extended team, rather than justthe core developers listed on the project page.This parameter can be attributed to the fact ofgrowing interest of OSS community members inthe project .The requests for new features startthe evolution of the framework where the idea ofthe core developer starts progressing from thefirst stage of the timeline of the project to the nextphase of the project . Average number ofsoftware downloads for the sample projects aregiven below in the graph:

ETJOURNALoFENGINEERING&TECHNOLOGY

I - 73,529,161180000000,.----...:..=.:.:="-'-------~.......,

60000000+-----

40000000

20000000

o

Figure 2: Average number of downloads vsTimeline

The success of most ass projects is not judgedtypically by profits (although some companiesdo make profits with aSS); the success isjudged chiefly by how many people use thesoftware.

Bugs Reporting Location

Reliability assurance activities can be tailoredand improved on the understanding of locationswhere the bugs are reported by theusers/developers and their nature .In a survey ofbugs reported for the project sample chosen, itis found that the following are the categories ofthe project and their reporting percentages:

• User Interface Bugs• Logical bugs

Database bugs

• Network bugsPlatform incompatibility bugs

Figure 4 : Percentage of Bugs Reporting Location

Impact of language and tools familiarity

ass work requires specific skills and there is alimited pool of people with the knowledge and

Autumn 2010

motivation to be able to productively contribute,leading to potential competition among projectsto attract developer efforts. In the ass context,although the code is available for inspection,users may not have the necessary backgroundknowledge to evaluate the inner workings andfeatures of a software program before they installit, or even if they do have the requisite skill, theymay seek to minimize the cognitive effortinvolved in evaluation by relying on more easilyinterpreted cues. Familiarity with various aSSDtools helps the contributor to contributeeffectively. Language with good support makescontributors' learning and usage processeasier.The greater the familiarity of thecontributors with aSSD tools, the greater theass developer motivation and the greater will bethe development success of the project.

Impact of documentation in open source code

Qualities that make an ass process appropriateinclude a high degree of responsiveness(release early, release often), to be inclusive,reliable and coherent. A large part of the assdesign process takes place in the discussionspace and is archived in the documentationspace. Tools are also used to extract relevantdata from a large quantity of archived datagenerated from the design discussions.Documentation helps in providing learners a"gentle slope" learning curve. Mailing lists andchat logs contain a wealth of information aboutthe project. The availability of structureddocumentation along with the source code willenhance the ass usage success which in turnwill enhance the motivation of developers tocontribute to a project and thereby have apositive effect on development success.

Impact of perfective and adaptivemaintenance

ass development emphasizes themaintainability of the software released. Makingsoftware available on the Internet allowsdevelopers around the world to contribute a

code, add new functionality (paralleldevelopment), improve the present one andsubmit bug fixes to the current release (paralleldebugging). A well-known conjecture in modernsoftware engineering is that external qualitycharacteristics are correlated to internal qualitycharacteristics. The measurement of sourcecode provides useful information for theassessment of its quality, predicting to someextent the external system qualitycharacteristics. Project output affects the userinterest. Feedback from usage success todevelopment success motivates OSSdevelopers. More active projects are morepopular .The greater the user interest in a project,the wider the audience for individualcontributions and therefore the more visible theefforts of contributors.

CONCLUSIONS

The goals of open-source software developmentare not unique. It aims to sustain end-userconfidence, goodwill by minimizingdevelopment and quality assurance costs. Theprocess of OSSD tries to limit regression errorsthereby avoiding breaking features whichdegrade performance relative to prior releases.Frequent "beta" releases, e.g., several times amonth are used to ensure consistent quality ofOSS. The overall results from the facts statedabove seem to indicate an acceptable level ofOSS quality during the development phase ofthe open source project. As far as functionality ofOSS is concerned, the ad hoc partneringbetween the developers and user initiatedchange requests has proved its suitability andacceptability for the systems with horizontalrequirements. The "many eyeballs" quote 'alsoneeds to be further explored with morequantitative studies. If structured documentationalong with the source code is made viable to theusers, then it will promote OSS usage successamong the common users. Various other qualitymetrics may be used to explore the fact of

Autumn 2010

improvement in the development success of theopen source project. Though the contributors tothe project continuously carry out perfective andadaptive maintenance, the evolution of themaintainability of OSS has to be investigatedfurther.

As a final conclusion, the open sourcesoftware's quality depends upon a variety ofinterdependent factors and is an open issue.Research is going on to develop quality metricsfor open source software to establish theirreliability in contrast to proprietary software.Open source software continuously strives forbetter quality as developers are users of thesoftware.

00

REFERENCES

1. M. S. Elliott and W. Scacchi. Free software

development: Cooperation and conflict in a

virtual organizational culture.ln S. Koch, editor,Free/Open Source Software Development. Idea

Publishing, 2004.

2. L. Gasser and W. Scacchi. Continuous design of

free/open source software: Workshop report and

research agenda, October 2003.

http://www.isrl.uiuc.edu/ - gasser/papers/CD-

OSS-prelim-report.pdf.

3. S. Koch and G. Schneider. Results from software

engineering research into open source

development projects using public data.

4. Libre Software Engineering tool repository.

http://barba.dat.escet.urjc.es/index.php

5. A. Mockus, R. T. Fielding, and J. Herbsleb. Two

case studies of open source software

development: Apache and Mozilla." ACM

____ L

ETJOURNALoFENGINEERING&TECHNOLOGY

Transactions on Software Engineering and

Methodology, 11 (3): 1-38, July 2002.

6. G. Ripoche and L. Gasser. Scalable automatic

extraction of process models for understanding

F/OSS bug repair. In Proceedings of the

International Conference on Software & Systems

Engineering and their Applications (ICSSEA'03),Paris, France, December 2003.

7. John C. Georgas , Michael M. Gorlick & Richard

N. Taylor," Raging Incrementalism: Harnessing

Change with Open Source Software", Institute

for Software Research, University of California.

8. Raymond,E.S.",The Cathedral and Bazaar"

0'Reily & Associates,2000.

9. Siraj A. Shaikh and Antonio Cerone" ,Towards a

quality model for Open Source Software

(OSS)", International Institute for Software

Technology (liST) , Macau SAR China

10. Nakakoji, K., Y Yamamoto, Y Nishinaka, K.

Kishida, and Y Ye. "Evolution Patterns of Open-

Source Software Systems and Communities," in

Proceedings of International Workshop on

Principles of Software Evolution (1WPSE 2002)(Orlando, FL, 2002), 76-85.

11. O'Reilly, T. Lessons fro~ Open-Source Software

Development. Communications of the ACM,

1999.42(4): 33-37.

12. DiBona, C., S. Ockman, and M. Stone. eds. Open

Sources: Voices from the Open Source

Revolution. 1999, O'Reilly & Associates:

Sebastopol, CA.

13. Vidyasagar Potdar, Elizabeth Chang , Open

Source and Closed Source Software

Development Methodologies, School ofInformation System, Curtin University of

Echnology, Perth, Australia.

14. Lyu, Michael R. (1996) Handbook of Software

Engineering Reliability. McGraw-HilI.

15. The Open Source Initiative. Open source

definition, version www.opensource.org/ docs /

definition.php.

16. Stewart,K.J. and S.Gosain."An exploratory study

Autumn 2010

of ideology and trust in open source development

groups " in proceedings of of the 22nd

International Conference on Information

Systems,2001 ,New Orleans, LA.

17. Scott H, Charles W, Plakosh D., Jayatirtha A.,

"Perspectives on Open Source Software",Software Engineing Institute, Pittsburgh, Nov

2001 p49.

18. Walt Scacchi, "Is Open Source Software

Development Faster, Better and Cheaper than

Software Engineering?", 23rd International

Conference on Software Engineering, Toronto,

Ontario, Canada, 2001 .

19. Saachi,W.,"Understanding Requirements for

developing Open Source Software Systems

"IEEE Proceedings on Software, 2002, 149(1):p

24-39.

20. B.Bohem,"Software Engineering Economics,"

IEEE Transactions on Software Engineering,

Vol. 10,ppA-21, 1984.

21. C.L. Jones "A process integrated Approach to

Defect Prevention ",IBM SystemsJournal,voI.24,pp. 150-167,1985.

22. M.Godfrey and Q.Tu,"Evolution in Open source

software: A Case study ,"Proc. International conf.

Software Maintenance, pp.131-142,2000.

23. J.Paulson, G.Succi and A.Eberlein,"An empirical

study of Open Source and Closed source

software products,"IEEE transactions onsoftware engineering, vo1.30. no. pp.-246-

256,2004.

24. M. S. Elliott and W. Scacchi. Free software

development: Cooperation and conflict in a

virtual organizational culture. In S. Koch, editor,

Free/Open Source Software Development. Idea

Publishing, 2004.

25. R. J. Sandusky, L. Gasser and G. Ripoche. Bug

report networks: Varieties, strategies and impacts

in an OSS development community. In

proceedings of the ICSE/MSR Workshop,

Edinburgh, Scotland, UK, 25 May 2004.

26. IEEE standard for a software quality metrics

methodology. In IEEE Std 1061-1998, 1998.

27. Kemerer, C.F. Software Complexity and Software

Maintenance: A Survey of Empirical Research.

Annals of Software Engineering, 1,1 (1995) 1-22.

28. Gorla N. and Ramakrishnan, R. Effect of Software

Structure Attributes Software Development

Productivity. Journal of Systems and Software,

36,2 (1997) 191-199.

29. Katherine J. Stewart, University of Maryland,

"OSS Project Success: From Internal Dynamics

to External Impact" .

30. Bergquist, M. and J. Ljungberg, "The Power of

Gifts: Organizing Social Relationships in Open

Autumn 2010

Source Communities," Information Systems

Journal, 2001,11 (4): p. 305-320.

31. Reis, C., R. Pontin, and M. Fortes (2002): An

Overview of the Software Engineering Process

and Tools in the Mozilla Project. In Proceedings of

the Open Source Software Development

Workshop, Newcastle upon Tyne, UK, February

25-26,2002, ed. C. Gacek pp.155-145.

32. Randell, B. (2000). Turing Memorial Lecture:

Facing up to faults. The Computer Journal, Vol.

43. No.2. pp 95-1 06.

000