DOC PREVIEW
CU-Boulder CSCI 5828 - Comments on The Cathedral and the Bazaar

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Lecture 29Comments onThe Cathedral and the BazaarKenneth M. AndersonFoundations of Software EngineeringCSCI 5828 - Spring Semester, 2000May 2, 2000 © Kenneth M. Anderson, 2000 2Today’s Lecture• Discuss other papers that resulted from theCathedral and the BazaarMay 2, 2000 © Kenneth M. Anderson, 2000 3The size of a Bazaar Project• Forrest J. Cavalier, III (What a Name)– Defines the terms• total size– actual number of participants• effective size– number of participants contributing to a particular activity• effective power– effective size * average contribution (person hours/week)May 2, 2000 © Kenneth M. Anderson, 2000 4Size implications on Debugging• In order for a bug to be reported– it must be reachable– it must be triggered– it must be noticed (!)– it must be reported• Cavalier claims that the effective size of a bazaarproject decreases for each condition• This is important since it implies that bazaarprojects may require large “effective sizes”May 2, 2000 © Kenneth M. Anderson, 2000 5Debugging Alternatives• Cavalier suggests open-source versions of– code review• Of course, open source always had informal codereview, Cavalier is asking that it be formalized– unit testing• Cavalier is asking that open source projects tochoose code structures that lend themselves to unittesting (which is a first step towards integrationtesting)May 2, 2000 © Kenneth M. Anderson, 2000 6Evolvable Systems• Raymond points to a paper on evolvable systemsas one aspect relevant to the bazaar style ofdevelopment• A paper by Clay Shirky– describes Web protocols as a “practical joke”• Ignored almost all existing hypertext research• Inefficient use of the network• No support for load balancing, security risks everywhere, etc.• Inconsistent client implementations– yet it “won”, why?May 2, 2000 © Kenneth M. Anderson, 2000 7Evolvable vs. Centrally Controlled• Shirky describes the early 90’s– Three major ways of indexing/accessing information• anonymous ftp, gopher, wais– Homogeneous network services• AOL, Compuserve, Prodigy, etc.• None of these things could interoperate• When I first started using the Web, the “big win”in my eyes was that it presented a uniforminterface to the InternetMay 2, 2000 © Kenneth M. Anderson, 2000 8Evolvable vs. Centrally-Controlled,continued• It was more difficult for the “centrally-controlled”standards to evolve– They had a high entry barrier to use• At least higher than the Webs– There designs made assumptions that hinderedevolution• The Web in contrast had something that partiallyworked and could be evolved in several areassimultaneouslyMay 2, 2000 © Kenneth M. Anderson, 2000 9Shirky’s definition of evolvable• Those that proceed not under the sole direction ofone centralized design authority but by beingadapted and extended in a thousand small ways ina thousand places at once.May 2, 2000 © Kenneth M. Anderson, 2000 10Three rules for Evolvable Systems• Only solutions that produce partial results whenpartially implemented can succeed.– They have room to grow• What is, is wrong– Evolvable systems are currently addressing past needsbut are quickly evolving to address current needs (fasterthan non-evolvable systems)• Evolution is cleverer than you are– Systems that evolve are better able to adapt to newrequirementsMay 2, 2000 © Kenneth M. Anderson, 2000 11Capacity for Change• Centrally designed protocols start out strong and improvelogarithmically. Evolvable protocols start out weak andimprove exponentially. It's dinosaurs vs. mammals, and themammals win every time. The Web is not the perfecthypertext protocol, just the best one that's also currentlypractical. Infrastructure built on evolvable protocols willalways be partially incomplete, partially wrong andultimately better designed than its competition.May 2, 2000 © Kenneth M. Anderson, 2000 12Web Success via Open Source• Shirky (in a separate paper) asserts– The “View Source” command of Web browsersplaces the Web in the realm of open sourcetechniques– He attributes this as one factor in the Web’soverall successMay 2, 2000 © Kenneth M. Anderson, 2000 13Homesteading the Noosphere• Raymond’s second paper on open-source– Examines the hacker culture and itsimplications on open source– The paper was written because Raymondperceived a contradiction in what hackersbelieve and what they do– He characterized this as the difference betweenopen source ideology and its actual practiceMay 2, 2000 © Kenneth M. Anderson, 2000 14Zealotry and AntiCommercialism• High Zealotry– “open source is mylife”• Medium– “open source is a goodthing”• Low– “open source is ok,sometimes”• High AC– “Commercial softwareis evil”• Medium– Commercial softwareis good and bad• Low– Commercial softwareis OKMay 2, 2000 © Kenneth M. Anderson, 2000 15Types continued• Nine combinations are possible– and represented in the open-source community• Free Software Foundation– Characterized as High Zealotry and High AC• Other communities– Perl, tcl, BSD Unix, Python, Linux– Didn’t quite buy into the FSF philosophyMay 2, 2000 © Kenneth M. Anderson, 2000 16Open Source Definition• <http://www.opensource.org/>• Defines guidelines for open source licenses– An open-source license must protect an unconditionalright of any party to modify (and redistribute modifiedversions of) open-source software.• In theory, this allows projects to be split into manydifferent directions– But this rarely happens… why?May 2, 2000 © Kenneth M. Anderson, 2000 17Ownership in Open Source• In fact (and in contradiction to the anyone-can-hack-anything consensus theory) the open-sourceculture has an elaborate but largely unadmitted setof ownership customs. These customs regulatewho can modify software, the circumstances underwhich it can be modified, and (especially) who hasthe right to redistribute modified versions back tothe community.• [Quoted from Homesteading…]May 2, 2000 © Kenneth M. Anderson, 2000 18Open Source Taboos• There is strong social pressure against forking projects. Itdoes not happen except under plea of dire necessity,withmuch public self-justification, and with a renaming.• Distributing changes to a project without the cooperationof the moderators is frowned upon, except in special caseslike essentially trivial porting fixes.• Removing a person’s name


View Full Document

CU-Boulder CSCI 5828 - Comments on The Cathedral and the Bazaar

Documents in this Course
Drupal

Drupal

31 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

23 pages

Deadlock

Deadlock

22 pages

Load more
Download Comments on The Cathedral and the Bazaar
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Comments on The Cathedral and the Bazaar and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Comments on The Cathedral and the Bazaar 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?