1. Open Source Software Development (Adapted from Dr. Kostadin Damevski) Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 23, 2012

2. Outline  Mythical Man Month  Open Source Software Development

3. 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

4. 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

5. 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).

6. 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 http://en.wikipedia.org/wiki/The_Mythical_Man-Month

7. 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!!!

8. 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

9. 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.

10. 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.

11. 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

12. 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.

13. 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.

14. 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.

15. 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

16. 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

17. 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)

18. 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.