Agile Methods and Open Source Software Development

Transcription

1 Agile Methods and Open Source Software Development Prof. Dr. Dirk Riehle Lecture 9/15 of Winter Semester Winter Semester 2009/ /2010 Lecture Lecture Agile Methods Agile and Open Source Software Development Copyright 2009 Dirk Dirk Riehle Open Source Research Group Friedrich Alexander University of of Erlangen Nuremberg Erlangen Nürnberg

2 Table of Contents # Content 1 Classic open source software development 2 Three examples: Linux Kernel, PostgreSQL, TikiWiki 3 Conceptual and practical differences 4 Open source best practices 5 6 2

3 Community vs. Commercial Open Source 9.1 Classic Open Source Community owned Single proprietor Single product or product line Community Open Source (e.g. Linux, TikiWiki) Commercial Open Source (e.g. MySQL, Jasper) Multi product assembly ( stack ) Community Distribution (e.g. Debian) Commercial Distribution (e.g. RHEL, SLES) 3

4 Open Source Time Line 1991: Linux project started 1998: Open Source Initiative founded Classic Community Open Source 1999: Apache Software Foundation founded Managed Community Open Source 2004: Eclipse Foundation founded 1995: MySQL AB founded 2001: MySQL AB funded Single Vendor ( Commercial ) Open Source 4

5 Three Very Different Examples Linux Kernel 9.2 Three Examples An operating system kernel Hierarchical: Linus and his trusted lieutenants PostgreSQL A relational database system Core peer group of committers and evangelists TikiWiki A web content management system Anarchic: (Almost) everything goes 5

6 Roles in Traditional Processes (Recap) Product Management Research and Development Quality Assurance Product Manager Development Manager Tester Developer... Developer 6

7 Artifacts in Traditional Processes (Recap) PM R&D QA Product Manager Development Manager Developer Tester Requirements Document Time Table Developer Program Code Reports and Test Code 7

8 Committers, Contributors, Community Committers Main developers (User) community ( ) With access rights Contributors Casual developers Submit patches (User) community Provide bug reports Provide feedback Contributors (10 100) Committers (1 10) 8

9 Linux Kernel Product Management Who defines features? Patches Scratching one's itch Individual maintainer initiatives Company driven contributions Product management practices No overall product manager Practices vary by sub project E.g. brain, wiki, todo list 9

10 Linux Kernel Development Linux Thorvalds Linux Kernel Anon B. Coder David S. Miller Greg Kroah Hartman... Balbir Singh Some Fix Networking Device Driver Memory Management Dario Ballabio Li Yang SCSI Driver USB Driver 10

11 Linux Kernel Quality Assurance Linux Kernel Random B. Hacker Friendly C. Tester Winky too much time Warner Big T. Distributor Big T. Distribution Alma B. User Cedric D. User... Erich F. Admin Always latest greatest ADDer Groucho M. 11

12 PostgreSQL Product Management Who defines features? [1] Patches Scratching one's itch Individual developer initiatives Company driven contributions User polls on project home page Product management practices Leadership by core team Maintenance of a todo list [2] No prioritization: Pick your feature [1] [2] 12

13 PostgreSQL Development PostgreSQL Official releases Versions 8.x, 7.4 Core Team [1] Major Contributors Anon B. Coder S Some Fix EnterpriseDB Command Prompt ACME /1+0/1 Product Product Product [1] 13

14 PostgreSQL Quality Assurance PostgreSQL Official releases Versions 8.x, 7.4 Core Team Major Contributors Patch Review Round Robin CommitFest Anon B. Customer Anon B. Company Anon B. Coder Developer Developer Developer Project Product Project 14

15 TikiWiki Product Management Who defines features? Patches Scratching one's itch Individual developer initiatives Product management practices Maintenance of a todo list No prioritization: Pick your feature The wiki process applied to software 15

16 TikiWiki Development Development process Equal rights for 200 contributors Recruit early, recruit often D D D Smart people, highly collaborative Strong feature ownership Software architecture D TikiWiki D Monolithic application Everything is optional Don't break anything Avoids dependency hell D D D 16

17 TikiWiki Quality Assurance Large user base, more than downloads Given enough eyeballs, all bugs are shallow. bug count frequency of feature use At any given point in time, it is just good enough 17

18 Conceptual and Practical Differences Underlying philosophies 9.3 Conceptual and Practical Differences Cathedral vs. bazaar style Open collaboration Do ocracy Actual practical differences Non monetary motivation Volunteer and community process Two tier committer/contributor structure Highly distributed process Written communication culture 18

19 The Cathedral and the Bazaar [1] History of an influential paper Conceived 1997, revised over the next years Influenced Netscape to release the Communicator source code In the Netscape aftermath, motivated the Open Source Initiative Strong on metaphor and specific observations as well as aphorisms [1] Eric S. Raymond. The Cathedral and the Bazaar. O'Reilly, [2] Fred Brooks. The Mythical Man Month. Chapter 11. [3] Attributed to Antoine de Saint Exupery. 19

20 Raymond's Aphorisms Every good work of software starts by scratching a developer's personal itch. Good programmers know what to write. Great ones know what to rewrite (and reuse). Plan to throw one away; you will, anyhow. [1] 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. Treating your users as co developers is your least hassle route to rapid code improvement and effective debugging. Release early. Release often. And listen to your customers. Given a large enough beta tester and co developer base, almost every problem will be characterized quickly and the fix obvious to someone. Smart data structures and dumb code works a lot better than the other way around. If you treat your beta testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. [2] Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. When writing gateway software of any kind, take pains to disturb the data stream as little as possible and never throw away information unless the recipient forces you to! When your language is nowhere near Turing complete, syntactic sugar can be your friend. A security system is only as secure as its secret. Beware of pseudo secrets. To solve an interesting problem, start by finding a problem that is interesting to you. 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. [1] Fred Brooks. The Mythical Man Month. Chapter 11. [2] Attributed to Antoine de Saint Exupery. 20

21 Cathedral vs. Bazaar The Cathedral Carefully crafted work by small group of experts Bugs and problems are tricky, requiring deep analysis Project is led by command and control approach No early releases nor beta The Bazaar Incremental rapidly evolving work by large group of people Given enough eyeballs, all bugs are shallow Project leader needs people skills, know how to work a crowd Release early, release often 21

22 Open Collaboration [1] Egalitarian Meritocratic Self-organizing [1] Dirk Riehle et al. Open Collaboration. IEEE Software 26 (2) 22

23 Traditional vs. Open Collaboration Traditional Work Hierarchical Open Collaboration Egalitarian Closed and hidden silos Open for contribution Assigned to project Everyone can contribute Status driven Meritocratic Public and private discussions Public discussion process Hierarchical status decides Decisions based on merit Assigned tasks Self organizing Prescribed process People find their own process Prescribed jobs People find their best project 23

24 Do ocracy Definition of do ocracy An organizational setup in which people choose their own tasks and roles A term used in the context of open source but not much beyond Neither democracy nor meritocracy Slightly derogatory as in those who do, rule 24

25 (Some) Open Source Best Practices Project marketing 9.4 Open Source Best Practices Volunteer acquisition Code submission Decision making Project documentation 25

26 Lecture Outlook Next lecture: Managed community open source Exercises: Classic open source best practices 26

27 Excercises Winter Semester Winter Semester 2009/ /2010 Lecture Lecture Agile Methods Agile and Open Source Software Development Copyright 2009 Dirk Dirk Riehle Open Source Research Group Friedrich Alexander University of of Erlangen Nuremberg Erlangen Nürnberg

28 Exercise Questions Lecture 9 Review Google Code license policy Practice diff/patch code submission 28

29 Questions? Feedback! Winter Semester Winter Semester 2009/ /2010 Lecture Lecture Agile Methods Agile and Open Source Software Development Copyright 2009 Dirk Dirk Riehle Open Source Research Group Friedrich Alexander University of of Erlangen Nuremberg Erlangen Nürnberg