How Does Opensource Affect Software Development

7/31/2019 How Does Opensource Affect Software Development

http://slidepdf.com/reader/full/how-does-opensource-affect-software-development 1/6

2 8 I E E E S O F T WA R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 7 4 5 9 / 0 4 / $ 2 0 . 0 0 © 2 0 0 4 I E E E

work on open source components, libraries,frameworks, systems, platforms, and develop-ment environments. The possibilities rangefrom reusing a particular subsystem such as theSQLite or the H SQLDB embeddable database en-gines to basing our work on a complete appli-cation server such as JBoss. The number of open source projects available to developers is

staggering: 30,000 projects are registered onhttp://freshmeat.net, 70,000 projects (of vary-ing quality, completeness, and stability) arehosted on http://sourceforge.net, 5,400 Perlmodules are on the Comprehensive PerlArchive Network (www.cpan.com), and10,000 ports, all regularly regression tested forcorrect compilation and installation, are dis-

focus

How IsOpen Source AffectingSoftware Development?

The dynamism of open source software development efforts, nu-merous high-profile success stories, and the novel economic,business, and legal aspects of open source software adoption are

justifiably creating a stir in the development community. We soft-ware practitioners increasingly face the possibility of using or basing our

guest editors’ introduction

Diomidis Spinellis, Athens University of Economics and Business

Clemens Szyperski, Microsoft Research



tributed with the FreeBSD operating system.(Many projects appear on more than one of thelocations just listed.) Following the reusedopen source code’s evolution and deploying thecorresponding components are also becoming

less haphazard operations, with mechanismssuch as installable packages and anonymousConcurrent Versions System (CVS) access en-abling the automation of many operations.This special issue examines how the prolifera-tion and availability of open source are affect-ing software development practices.

From a developer’s perspective, open sourceis a combination of two important properties:visible source code and a right to make (rela-tively) unencumbered derivatives. The motiva-tions behind the two properties are different,and each can occur in isolation—examples in-clude Microsoft’s shared source and libraryvendors’ code licenses for developing derivativeproducts from nonvisible source. Both proper-ties affect—in positive and negative ways—thesoftware artifacts (products) we develop andhow we develop them (process).

Influence on software productsThe most obvious boon of open source to

software developers is the opportunity to basea design on existing software elements. Theopen source community gives us a rich base of reusable software, typically available at thecost of downloading the code from the Inter-net. So, in many cases we can select best-of-breed code to reuse in our system without hav-ing to reinvent the wheel. The resultingproducts benefit in two ways. First, the reusedopen source code will typically be of higherquality than the custom-developed code’s firstincarnation. Second, the functionality thereused element offers will often be far morecomplete than what the bespoke developmentwould afford. Products can easily incorporatea standardized, sophisticated open source ele-

ment such as an XML parser, a sophisticatedscripting language, a regular-expression en-gine, or a relational database to satisfy re-quirements that in the past a custom-built,small-scale suboptimal implementation wouldhave fulfilled.

Moreover, reuse granularity is not re-stricted by the artificial product boundaries of components distributed in binary form (whichmarketing considerations often impose).When reusing open source, code adoption can

happen at the level of a few lines of code, amethod, a class, a library, a component, a tool,or a complete system. Furthermore, whensoftware is available in source code form, wecan more easily port to our target platform

and adjust its interfaces to suit our needs.Consequently, software reuse possibilitiesopen up on three axes: what to reuse (pro-moted by the available software’s breadth andprice), how to reuse it (diverse granularity andinterfacing options), and where to reuse it (in-herent portability of source code over most bi-nary packaged component technologies).Movement along all three axes increases thebreadth of software reuse opportunities in anydevelopment effort.

In addition, source code’s availability letsus perpetually improve, fix, and support thereused elements. This factor often mitigatesthe risk of orphaned components or incom-patible evolution paths that are associatedwith the reuse of proprietary components.Also, by incorporating the source code of areused element into the system being built, de-velopers can achieve tight integration and asystem that can be maintained as a whole.

On the other hand, many of the reuse op-tions that open source opens can isolate reusedcode from its original authors and maintainers,leading to divergent evolution paths or a fos-silized code base. Consider as an example a de-veloper reusing a regular-expression library bydirectly incorporating its source code into hisor her application (perhaps to port it into anembedded environment where the original li-brary couldn’t compile). The developer wouldhave to (expensively) reintroduce any new im-provements and fixes made on the original li-brary code into the modified version. The con-sequences can be dramatic, as in the case of the slow or lacking propagation of securityfixes. In cases where the software industry ismoving toward new technologies such as 64-

bit architectures or Unicode character encod-ing, the effort of upgrading reused source codeelements might mean large-scale duplicationof effort. Reuse in source code form can alsoresult in undesired coupling between separatecomponents when programmers hack togetherthe adopted code into a working implementa-tion instead of using or designing modular in-terfaces. This problem is exacerbated whendevelopers fail to prune reused elements andend up dragging along unneeded dead code

J a n u a r y / F e b r ua r y 2 0 0 4 I E E E S O F T WA R E 2 9

The number ofopen source

projectsavailable todevelopers is

staggering.



that will nevertheless be compiled, distributed,and maintained with their product.

However, even when reusing open sourcecomponents with precisely defined and man-aged interfaces (for example as a library), usingthat source is problematic. It’s all too easy toinadvertently create deep dependencies on im-plementation details that will likely change inthe reused element’s future releases. (Thisproblem can also occur with binary compo-nents—one prominent process that leads tosuch dependencies is debugging, which com-monly gives away implementation details thatthe debugged code then depends upon.) In ad-dition, even the published interfaces of opensource components often change in ways thataren’t backward compatible; rapid innovationin open source projects coupled with the lackof financial pressure from an existing customerbase tend to make such changes more preva-lent than on proprietary products. As an ex-ample, you can read more about how the evo-lution and distribution model of GNU/Linuxcan create problems for independent soft-

ware vendors at http://primates.ximian.com/ ~miguel/texts/linux-developers.html.Furthermore, the availability of source code

affords an anarchic array of different depend-ency modalities between adopted open sourceelements. These include dependency require-ments for specific source code, compiled li-braries, packaged components, shared libraries,header files, templates, databases, plug-ins, andcomplete programs belonging to different opensource elements. The practically zero cost of the

reused elements further contributes to thiscommendable phenomenon of extensive reuse.As an example, Figure 1 illustrates the morethan 20 library dependencies associated withthe FreeBSD port of the xine multimedia player.Consider, however, restrictions that are oftenplaced on the supported or required elementversions as well as on processor and operatingsystem platforms. Such restrictions—combinedwith the possibility of deploying the samereused element multiple times through differentproducts—can easily result in incompatible de-pendencies that are nightmarishly difficult totrack, reconcile, and maintain. By comparison,the infamous DLL problems of Windows plat-forms often look downright simple.

Reusing open source components can alsoaffect the licensing model of the resultantproduct. Some open source licenses dictate un-der which license you can distribute derivativeproducts. The Ruffin-Ebert article in this issueexpands on the relevant licensing and intellec-tual-property issues.

An additional problem associated with

reusing open source elements is that theirquality varies widely from shoddy to indus-trial strength, and no standardized processesand metrics exist for assessing the quality of agiven element. This can adversely affect prod-ucts that depend on substandard software ele-ments. Often, however, you can use the under-lying source code, associated mailing listarchives, and bug-tracking databases as indi-cators of the software’s quality, degree of adoption, and support. Some software reposi-

3 0 I E E E S O F T WA R E w w w. c o m p u t e r. o rg / s o f t w a r e

XFree86-4-libraries

png

libxine

x11-fontconfigfreetype2

expat2libiconv

Mesa3

libdvdcss

svgalib

libdvdread

libmng

sdl12

liba52

xine

aalib

lcms

jpeg

gettext

libogglibvorbis

mad

Figure 1. Librarydependencies of thexine multimedia player.



tories, such as sourceforge.net, even providemetrics of a project’s activity based on factorssuch as those just listed.

On the security front, products using opensource can benefit from reusing widely de-

ployed and scrutinized algorithms and proto-cols. However, adversaries having access tothe source can more efficiently locate and ex-ploit vulnerabilities, while the original devel-opers may lack communication channels or re-sources for informing the users of theirsoftware about security vulnerabilities (see the“Keep in Touch” sidebar on page 46).

Process issuesAs we indicated in the introduction, open

source affects not only the products we buildbut also how we build them.

First of all, open source’s low cost has con-tributed to the widespread adoption of sophis-ticated development platforms and tools.These include operating systems such asGNU/Linux and FreeBSD, databases such asPostgreSQL and MySQL, application serverssuch as JBoss, optimizing compilers such asthe GNU Compiler Collection, integrated de-velopment environments such as Eclipse andKDevelop, build managers such as Make andAnt, and version control management systemssuch as CVS. Today, even small programmingshops with a couple of developers can use so-phisticated tools that once only large and well-funded development efforts could afford.

Of course, having access to sophisticatedtools doesn’t imply that developers actuallyuse them. However, large open source devel-opment projects increase the visibility, accessi-bility, and adoption prospects of importantsoftware engineering processes such as versioncontrol, peer reviews, issue tracking, releaseengineering, and regression testing. Theseprocesses are standard in any CMM Level 3and above organization, but most small shops

and development efforts used to ignore them.Now, open source developers often diffuse thebest-of-breed practices they learn while work-ing in large, organized open source projects tothe (possibly proprietary) projects they under-take for pay.

In addition to familiarizing themselves withsophisticated development practices, develop-ers reusing software in source form can readthe code and can often learn valuable codingpractices from well-engineered software. 1

Dick Gabriel and Ron Goldman point out thatours is one of the few creative professionswhere writers are not allowed to read eachother’s work:

The effect of ownership imperatives hascaused there to be no body of software as lit-erature. It is as if all writers had their own

private companies and only people in the Melville company could read “Moby-Dick” and only those in Hemingway’s could read “The Sun Also Rises.” Can you imagine devel-oping a rich literature under these circum-stances? Under such conditions, there could beneither a curriculum in literature nor a way of teaching writing. And we expect people tolearn to program in this exact context? 2

Open-source software has changed this sit-uation: we can now access millions of lines of code (of variable quality), which we can read,critique, and improve, and from which we canlearn. In fact, many of the social processes thathave contributed to the success of mathemati-cal theorems as a scientific communication ve-hicle also apply to open source software. 3

Most open source programs have been

I Documented, published, and reviewed insource code form

I Discussed, internalized, generalized, andparaphrased

I Used for solving real problems, often inconjunction with other programs

On the other hand, if the reused software isnot evolving, or is evolving in a direction in-consistent with the needs of the organizationthat uses it, the organization must contributeresources to its improvement. These resourcescan’t always be planned in advance becausethe organization reusing the code typically haslimited control over the reused code’s develop-ment process. Disagreements with or within

the software’s development team often createproduct forks and can result in effort duplica-tion, waste, and confusion in the communitydepending on the project. Forks can also occurowing to genuine irreconcilable technical con-siderations, in which case they might createdifferent evolutionary paths that are all valu-able to their separate user communities. As anexample, at the time of this writing, softwareplatforms based on the original BSD Unix dis-tribution include


Many of thesocial

processesthat havecontributed tothe success ofmathematicaltheorems asa scientific

communicationvehicle also

apply toopen sourcesoftware.



I FreeBSD, targeting Intel and 64-bit plat-forms

I NetBSD, having as its design goal porta-bility to various hardware architectures

I OpenBSD, emphasizing security and cryp-

tography as explicit project goalsI DragonFly BSD, experimenting with dif-

ferent feature sets and algorithms

Furthermore, when an organization wants oris forced to support a reused software element,it must integrate into its development processthe reused element’s (typically incompatible) de-velopment process. This includes issue tracking,software updates, security advisory notifica-tions, software builds, and the actual softwarerepository. Integrating multiple software ele-ments (and therefore multiple incompatible soft-ware processes) can be challenging.

In addition, reusable software’s widespreadavailability and the numerous reuse patternsafforded by open source are reducing the fo-cus that many organizations put on centrallyorganized, promoted, and maintained soft-ware reuse efforts. As we discussed earlier, theability to download open source from the In-ternet isn’t always a proper substitute for anin-house reusable component library.

Finally, adopting open source developmentpractices can make organizations pay less at-tention to strategic planning, detailed require-ments elicitation, testing, and organized sup-port. These activities are often neglected inmany open source projects. Therefore organi-zations whose members, through their in-volvement in open source projects, haveadopted the corresponding mindset are likelyto skip or downgrade the importance of theselife-cycle tasks.

Open source and non-open source de-

velopment models are not at logger-heads with each other. They each havestrengths and weaknesses and, most likely,they are both here to stay.

Developing with open source creates newchallenges and opportunities for the productswe build and the processes we use. Opensource is a disruptive technology (in the sensearticulated in Clayton Christensen’s Innova-tor’s Dilemma .4 It currently affects develop-ment in numerous small ways, but could in the

3 2 I E E E S O F T WA R E w w w. c o m p u t e r. o rg / s o f t w a r e

Further Reading ListBooks and articles

I Understanding Open Source Software Development by J. Feller andB. Fitzgerald (Addison-Wesley, 2001). Open source development from a software engineering perspective

I The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary by E.S. Raymond (O’ Reilly and As-

sociates, 2001). The ideas behind open sourceI Component Software: Behind Object-Oriented Programming by C.

Szyperski (Addison-Wesley, 2002). The canonical reference regard-ing software components

I Software Ecosystem—Understanding An Indispensable Technol-ogy and Industry by D.G. Messerschmitt and C. Szyperski (MITPress, 2003). Discusses software as an ecosystem of interactingparticipants

I “Code Reading: The Open Source Perspective” by D. Spinellis,Ef-fective Software Development Series(Addison-Wesley, 2003). Morethan 600 examples from open source projects presenting commondevelopment and coding practices and the skill of reading code

I Managing Open Source Projectsby J. Sandred (John Wiley & Sons, 2001). Demonstrates how the ideas and models behind themanagement of open source projects can apply to any type of software development

I “Release Management within Open Source Projects” by J.R. Ehren-krantz,Proc. 3rd Workshop Open Source Software Eng., Int’l Conf.Software Eng.(IEEE CS Press, May 2003, http://opensource.ucc.ie/icse2003/3rd-WS-on-OSS-Engineering.pdf). Examines therelease practices of three open source projects (the Linux kernel,Subversion, and the Apache HTTP server) to identify areas of weaknesses in their release management processes and suggest improvements

I “Innovation by User Communities: Learning from Open Source Soft- ware” by E. Von Hippel,Sloan Management Rev.(vol. 42, no. 4,Summer 2001, pp. 82–86). Presents the relationship between theopen source development culture, innovation, and learning

Web sites

I www.opensource.org.The open source home page. It includes alist with all software licenses that classify a software distribution asopen source and also a list of successful open source projects.

I www.onlamp.com.The LAMP Model is a widely used recipe for im-plementing dynamic Web sites. It entails using the GNU/Linux op-erating system; the Apache Web Server; the MySQL Database En-gine; and Perl, Python, or PHP as a scripting language. The modeldemonstrates how you can use open source to implement Web-based enterprise systems.

I http://opensource.mit.edu. The open source directory maintainedby the MIT Sloan School of Management includes a large catalog of scientific publications related to open source.

I http://freshmeat.net, http://sourceforge.net. These two Web sitesare hubs hosting thousands of open source projects. Developers canuse them to search for software to reuse, browse the correspondingforums and mailing lists, and download packages.



long run lead to a paradigm shift in theway we develop software.

AcknowledgmentsVassilios Karakoidas reviewed earlier drafts

of this introduction and contributed perceptiveremarks. Publication of this issue’s articleswouldn’t have been possible without the re-viewers’ valuable and constructive comments.Special thanks to Terry Bollinger for shepherd-ing the issue and to Warren Harrison, DaleStrok, and Pauline Hosillos for their supportleading to a smooth editorial process. We alsothank Nikos Korfiatis, who helped compile theFurther Reading section, and Erast Athanasia-dis, Ioanna Grinia, Alexandra-Maria Sigala,Stephanos Androutsellis-Theotokis, and VasilisVlachos, who performed the background re-search for planning this issue.

References1. D. Spinellis, “Code Reading: The Open SourcePerspective,” Effective Software Development Series, Addison-Wesley, 2003, pp. 2–3.

2. R.P. Gabriel and R. Goldman, “Mob Software:The Erotic Life of Code,” Proc. ACM Conf. Ob-

ject-Oriented Programming, Systems, Languages,and Applications , ACM Press, Oct. 2000, www.dreamsongs.com/MobSoftware.html.

3. R. DeMillo, R. Lipton, and A. Perlis, “SocialProcesses and Proofs of Theorems and Pro-grams,” Proc. 4th ACM Symp. Principles of Programming Languages , ACM Press, 1977,pp. 206–214.

4. C.M. Christensen, The Innovator’s Dilemma:When New Technologies Cause Great Firms toFail , Harvard Business School Press, 1997.


About the Authors

Diomidis Spinellis is an assis-tant professor in the Department ofManagement Science and Technology atthe Athens University of Economics andBusiness. He has written a number ofopen source tools and libraries, some of which are part of FreeBSD and the XWindow system. He has also been a de-veloper and manager in large commer-

cial software projects. He is also the author ofCode Reading: The Open Source Perspective (Addison-Wesley, 2003). Contact him atAthens Univ. of Economics and Business, Patision 76, GR-104 34Athens, Greece; [email protected].

Clemens Szyperski is a software architect at Microsoft and is affili-ated with Microsoft Research, where hefurthers the principles, technologies,and methods supporting componentsoftware. He is also an adjunct profes-sor in the Swiss Federal Institute of Technology’s School of Computing Sci-ence. He is the author ofComponent

Software: Beyond Object-Oriented Programming (Addison-Wesley,2002) and the new bookSoftware Ecosystem: Understanding an Indispensable Technology and Industry (MIT Press, 2003). He re-ceived his PhD in computer science from the Swiss Federal Instituteof Technology in Zurich. Contact him at Microsoft Research, OneMicrosoft Way, Redmond, WA 98052; cszypers@microsoft. com.

The Department of Electrical & Computer Engineering invites applicants for tenure-trackpositions at the rank of Assistant or Associate Professor to expand its already strong team

of software engineering researchers. Applicants who are in the process of finishing theirPhD are also welcome. Outstanding senior candidates will be considered for a full Professorshipas iCORE chair, see http://www.icore.ca/grants.htm.

We are interested in candidates whose primary research interest is in the area of SoftwareEngineering. Applicants must possess a PhD in Software Engineering or a closely relateddiscipline and have a strong research record. Foundational areas of software engineering,real-time software engineering, hardware-software co-design and emerging technologies areof particular interest, but highly qualified candidates working in other areas of softwareengineering will also be considered.

The Department is committed to excellence in research and teaching. It has one of the firstCEAB-accredited software engineering programs on the undergraduate level and has awell-established graduate program in software engineering. More information about theDepartment is available at http://www.enel.ucalgary.ca/DepartmentalWeb/index.htm.

The University of Calgary has unique funding opportunities for software engineering research.Various government agencies (e.g., Alberta Ingenuity Fund [AIF], Canada Foundation ofInnovation [CFI], The National Science and Engineering Research Council [NSERC]) andnumerous private companies from Calgary’s high-tech sector as well as internationalcorporations have contributed to a well-funded research program in the Depar tment.

The University of Calgary is a public institution with a full-time student population of about25,000. The City of Calgary has a population of over 900,000 and is one of the fastestgrowing high-tech industry based cities in Canada. It is situated within an hour's drive ofBanff National Park, one of the most beautiful areas of the Rocky Mountains.

Rank and salary are commensurate with qualifications and experience. Applicants areencouraged to apply as soon as possible for positions which are currently open.

Applications – including a curriculum vitae, a statement of interests, current and projectedresearch activities, a sample of written work, and any available teaching evaluationsshould be sent to: Dr. Joshua Leon , Head, Department of Electrical & Computer Engineering,University of Calgary, 2500 University Drive N.W., Calgary, AB, Canada, T2N 1N4.Email to: [email protected]

All applications should also include names and contact information of at least threeindividuals from whom the selection committee may request a written or verbal reference.

Engineering

www.ucalgary.ca

All quali fied candidates are encouraged to apply ; however, Canadians and permanent residents will be given priority.The University of Calgary respects, appreciates and encourages diversity.

How Does Opensource Affect Software Development

Documents

Transcript of How Does Opensource Affect Software Development