1 / 13

Toward a Simulation Model of Open Source Software Patrick Wagstrom

Toward a Simulation Model of Open Source Software Patrick Wagstrom Department of Engineering and Public Policy Center for the Computational Analysis of Social and Organizational Systems Carnegie Mellon University June 28, 2004 pwagstro@andrew.cmu.edu http://patrick.wagstrom.net/. Overview.

Download Presentation

Toward a Simulation Model of Open Source Software Patrick Wagstrom

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Toward a Simulation Model of Open Source Software Patrick Wagstrom Department of Engineering and Public Policy Center for the Computational Analysis of Social and Organizational Systems Carnegie Mellon University June 28, 2004 pwagstro@andrew.cmu.edu http://patrick.wagstrom.net/

  2. Overview • The Chaos that is Open Source • The NK Model and the edge of chaos • OSSim • Some interesting results • Moving on

  3. Open Source...Chaotic? Never! • Anyone can create a project • Anyone can use a project • Anyone can contribute to a project • Anyone can fork a project • Anyone can distribute a project • Diverging user requirements • No formal training for new community members • Usually lack specification and design documents

  4. Now With 100% Less Sarcasm • Not everyone has the skill/knowledge to create projects • Many projects are so poorly documented that they're nearly impossible to use • Often times patches are ignored or rejected • Forking a project takes time and is frequently frowned upon • Bandwidth costs money • Birds of a feather flock together • Communities have indoctrination processes • The process still makes software engineers cry

  5. N=15 011 111 110 100 001 011 110 101 011 111 110 101 011 110 101 K=2 0.15 + 0.19 + 0.20 + 0.46 + 0.34 + 0.85 + 0.67 + 0.12 + 0.77 + 0.91 + 0.85 + 0.55 + 0.72 + 0.06 + 0.59 15 0.4913 NK Model Agents have a genotype bit string of length N 0 1 1 1 0 0 1 1 0 1 1 1 0 1 1 Each bit is associated with K neighbors to create alleles Each allele has is evaluated against the randomly generated fitness landscape for that position. Overall fitness is the average of these values.

  6. 0 1 1 1 1 0 1 1 0 1 1 1 0 1 1 011 111 110 100 001 011 111 111 110 101 011 110 101 011 111 011 110 101 011 111 110 101 011 110 101 110 101 011 110 101 0.15 + 0.19 + 0.82 + 0.31 + 0.74 + 0.85 + 0.67 + 0.12 + 0.77 + 0.91 + 0.85 + 0.55 + 0.72 + 0.06 + 0.59 0.15 + 0.19 + 0.20 + 0.46 + 0.34 + 0.85 + 0.67 + 0.12 + 0.77 + 0.91 + 0.85 + 0.55 + 0.72 + 0.06 + 0.59 15 15 0.5493 Mutation in the NK Model Selects a bit at random, flip it, and evaluate new fitness 0 1 1 1 0 0 1 1 0 1 1 1 0 1 1 K=2 0.4913

  7. OSSim • Pronounced AWESOME!! • Make sure to say the exclamation points • Multi-agent simulation • Two classes of agents • People • Projects • People agents have a genotype string • Represents desired feature set • People may have ability to modify projects • Like real people, skill varies • Project agents have a fitness landscape

  8. OSSim • Initially, people associate with project that gives highest fitness • Each tick, agents that can modify the project, make some random modifications • Increase fitness of one phenotype and decrease fitness of another • Example: Emacs is great editor, but a lousy web browser • People vote on which modifications to accept • Cycle repeats per simulation parameters • If too long goes without improvement • Tolerance decreases • More likely to switch to another project

  9. Agents evaluate problem string against each project We'll focus on just two agents Associate with project that provides highest fitness Developer agents modify fitness landscape of projects People evaluate new fitness Vote to accept changes, ties settled by fitness Agent 1 Developer Skill 30 021211112220112 0.43 0.52 0.50 0.52 0.33 0.39 0.61 Agent 2 Non-Developer 120011222012121 0:010 +0.13 3:222 -0.05 12:121 +0.22 4:201 -0.08 . . . 0.57 0.67 0.61 Projects People The OSSim Process A pool of people and projects is initially created Cycle repeats until terminated

  10. Basic Results

  11. Abandon Ship!

  12. In The Future... • Validation, Validation, Validation • Face validity currently • Have data from OSS projects, need to code it • Improved social networks • Preliminary concept of friendship has been integrated • Knowledge obtained about new projects from friends • Integration with other CASOS tools • Export data in DyNetML • More realistic developers

More Related