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, Retrieved on August 23,

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 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 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 (  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.