Upload
susanna-daniels
View
215
Download
3
Embed Size (px)
Citation preview
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.