Open Source Software Development(Adapted from Dr. Kostadin Damevski)

Sung Hee Park

Department of Mathematics and Computer Science

Virginia State University

August 23, 2012

Outline Mythical Man Month Open Source Software Development

Review What is a Software Process Model?

It determines the order of the stages involved in software development and evolution

It provides the answer to the following two questions? What shall we do next? How long shall we continue to do it?

Software process models: waterfall, spiral, agile, others

Mythical Man-Month Seminal software engineering titled

by Fred Brooks The book is based on Brooks’

experiences at IBM while managing the development of OS/360

Most ideas in book still apply to software engineering today

Key Idea

Brooks’ Law

Adding more programmers to a late project makes it later

What’s The Rationale Behind Brooks’ Law? Bugs tend strongly to cluster at the interfaces

between code written by different people Communications/coordination overhead on a

project tends to rise with the number of interfaces between human beings.

Thus, problems increase with the number of communications paths between developers, which scales as the square of the number of developers (more precisely, according to the formula N*(N - 1)/2 where N is the number of developers).

Other Interesting Fred Brooks Points The “Second System” effect - plan to throw

one away "Good" programmers are generally five to ten

times as productive as mediocre ones “Conceptual Integrity” - separating

architecture from implementation Many others - the book is full of great advice Wiki, Mythical man-Month, http://

en.wikipedia.org/wiki/The_Mythical_Man-Month, Retrieved on August 23, 2012

What Is Open Source? The source code is included The license must allow derived works

(distributable under the same license terms) It is all free!!!

How Is Open Source Software Developed? Teams of varied sizes that are loosely coupled

Don’t know each other Only communicate through Internet, usually just e-

mail and newsgroups People are NOT directly compensated for their

work

How Does Open Source Software Stack Up To Proprietary Software? In terms of...

quality (reliability, performance, etc.) speed of development

This is the question we will try to answer in this lecture.

Of course, this is in general and not about specific projects/products.

Another Good Book: The Cathedral and The Bazaar written by Eric Raymond

Cathedral... “carefully crafted by individual wizards or small bands of mages

working in splendid isolation, with no beta to be released before its time”

Bazaar... “a great babbling bazaar of differing agendas and approaches

(aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles”

Open source software development is more like a bazaar than a cathedral!

Eric Raymond discusses the merits of open source software through his experience in building “popclient”, an e-mail client, in the mid 90s.

Major Points of The Cathedral and The Bazaar (1 of 4) Every good work of software starts by

scratching a developer’s personal itch. Necessity is the mother of invention The joy of the craft

Good programmers know what to write. Great ones know what to rewrite (and reuse). Certainly easier to do with more open source

software available

Major Points of The Cathedral and The Bazaar (2 of 4) “Plan to throw one away; you will, anyhow.”

(Fred Brooks, The Mythical Man-Month) If you have the right attitude, interesting

problems will find you. When you lose interest in a program, your last

duty to it is to hand it off to a competent successor.

Major Points of The Cathedral and The Bazaar (3 of 4) Treating your users as co-developers is your least-

hassle route to rapid code improvement and effective debugging. Having users is important, otherwise it is much harder. Maybe the most important point in open source design.

Release early. Release often. And listen to your customers. This can come back to bite you if you release buggy code.

You may lose some of your users. Therefore, most open source projects develop a two

release philosophy The “newest” release will get you all the cool features, but there

may be bugs. The “stable” release will get you something that is known to

work well.

Major Points of The Cathedral and The Bazaar (4 of 4) Given a large enough beta-tester and co-

developer base, almost every problem will be characterized quickly and the fix obvious to someone Given enough eyeballs, all bugs are shallow Take care of your developer / user base

In open source development, the line is blurred That might make debugging easier - developers produce

better bug information that testers

Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Case Study: Linux The first significant open source software

product Lead developer: Linus Torvalds Started with the code from another operating

system: Minix. Contributions by many thousands of people

over the years

Linux Continued Linux changed the “rules” of software

development Linus was an “average” coder, but a visionary

in terms of the open source design methodology Understood the psychology of modern day

programmers/hackers Recognized good design and itegrated it into Linux

Other Open Source Odds and Ends Bazaar style works if you already have

something to work with, rarely for something you want to build from the ground up

Licensing: The GPL Google’s Summer of Code

(http://code.google.com/soc/) Making money using open source software

(manuals, technical assistance) Making money by charging for commercial

use (e.g. MySQL)

Individual Presentations Prepare quick (5-10 minute) presentations for next

week on a particular agile method SCRUM Lean Software Development Extreme Programming (XP) Open Unified Process Getting Real etc.

Use google (or you other favorite way to obtain information) to teach us and convince us why a particular model is good.

Make slides, but not too many (generally, < 5) Aim for clarity!!!! Don’t put up anything in a slide that

you do not understand.