A7SocioTechnicalEnvironmentsforDistributedCommunities
A7SocioTechnicalEnvironmentsforDistributedCommunities
To-Do
Please Document the Following Sections:
- title for your course project
- members of your team
- abstract
- expected final outcome
- brief description of work done so far on the project
- brief description of work to be done in the next few weeks (e.g.: before spring break)
- describe specific research emphasis of every member of your team
- list of relevant references investigated
- list any specific problems you have encountered and need feedback/guidance on
- GerhardComments
- suggestions and feedback:
- for your discussion about "dictator" versus grass roots approach -- take a look at:
- for distributed communities you can
- take a look at the article and the slides which we discussed in class on March 18
- interactions with other projects in the class:
- migrations paths: talk to story telling people in their analysis of the pint system
- about altruism: talk to the SketchUp people
- Members
- Todd Mytkowicz, Nicholas Embree, Adam Mork, Michael Minerva
- Title
- Socio-Technical Environments for Distributed Communities
- Abstract
- In many projects that arise from a diverse group of people there is usually a balance between a central control dictating an overarching design vs a free-form process whereby a design is grown organically from the users / builders of that system. Both design paradigms (the "central dictator" vs a more "grass-roots" process) take different approach to design. The dictator approach builds contracts and guidelines for an implementer to follow; it is then up th those that implement a design to follow those guidelines. On the other hand, the more grass roots based approach uses a kind of Darwinian model, a survival of the fittest feature so to speak, that pushes implementation choice based upon their perceived use. These are two very different approaches to design and one would expect that system implementations based upon each approach to have very different characteristics. In this project, I would like to see if we can verify this claim. To be specific, I would like to study the idea of the intention of a design construct vs how that construct is actually used in practice. I would like to investigate a few open-source projects that vary in the amount of central control and organization that each project employs in its social contracts (e.g. openjdk vs Linux vs apache tomcat) and see how these choices impact the ultimate software implementation. To be concrete, consider an example. In the Java programming language I have many "tools" that aid in me in my organization of source code (e.g. objects / classes or packages). When I build a package I have a particular idea for how that package is going to be used (intention). For instance, I expect that classes within the package to be largely related in their usage patterns while conversely those classes would likely be unrelated to classes outside the package. In this way, packages are an organization construct that embodies a top-down, "dictator" type approach to project design. This project is interested in understanding, however, whether the way in which packages are used in an implementation matches the intention of designers of the package system.
- ExpectedOutcome
- By examining different projects some with a "grass roots" approach and some with a "dictator approach", will be able to compare and contrast the different techniques and look at the repercussions that each approach caused for their respective projects.
- WorkSoFar
- So far we have each picked a specific open source project that has a wide and distributed level of participation. Each member has began to research the structure of the community and the way that members interact.
April 1st: We have made progress on collecting data for the Mozilla project. We downloaded and created a database of their bug repository as a means to understand the role distributions in Firefox. We have done a bit of data analysis (shown in slides) in order to investigate (i) how roles are distributed in this environment and (ii) how work is distributed amongst those roles. We have found that there is a huge discrepancy between bug submitters and bug fixers and that the bug fixers are having a hard time keeping up with the demand. Many of the prior work we have read argues for co-evolution of the project and its participants. We have found that there seems to be little migration between roles, calling this into question (at least for this project).
- WorkToBeDone
- In the weeks before spring break we will come together and share what we all have learned and use this information to plan the direction for future project for our project. After all members have researched their domain in depth we will be able to see the similarities and differences of these communities and this will inform the future progress of our research.
April 1st: We would like to work on three different areas. First, we would like to mine the Firefox data a bit more to understand the few people that migrate from bug submitter to bug fixer. We also would like to break down the bug fixers into more defined roles (e.g. core member vs cursory member) and see if there is more migration between these roles. Second, we would like to see if we can understand the social aspects of the Mozilla project (Its an open source project that makes money so its a bit of an outlier) and see if those social aspects can explain any of the data we have. This may entail actually contacting the members of the Firefox project with a survey of sorts. Third, we would like to see if we can re-create these data for another open source project. At this point, we expect we can do Thunderbird (email client) as the data are similar. However, we have yet to see if other projects allow us access to their data.
- describe specific research emphasis of every member of your team
- Michael Minerva is be analyzing the Linux project, Nick Embree is examining Wikipedia. Todd is looking at the Firefox project. Adam Mork is working on phpMyAdmin.
- References
- http://freshmeat.net/ http://opensource.sys-con.com/node/318776 http://download.wikimedia.org/enwiki/
- list any specific problems you have encountered and need feedback/guidance on
- At the start of the project our team had some trouble finding time to meet to discuss our project because we are all very busy and have somewhat different schedules, but we have been able to meet before and after class and have been able to correspond through electronic media so we do not see this as a serious impediment. We have also had trouble analyzing the data dumps taken from wikipedia. There is such a large amount of data inside of these dumps that it is extremely difficult to draw conclusions from it all.