n impact of internal dynamics (j) n on quality of open source softwares of internal dynamics on...
Post on 17-Jun-2020
7 Views
Preview:
TRANSCRIPT
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
top related