commarch

Humanitarian Free and Open Source Software

• Spring 2018 – D. Joe Anderson
• Original Design – Professor David Shein
• Refinements – Remy DeCausemaker

Commarch -- Community Architecture

Open Source Community Characterization Assignment

Working in small groups (formed during class), you are going to look at FOSS community/project and analyze how that community is organized. You may also use some of these techniques to assess pre-existing FOSS projects you wish to contribute to for additional bugfixes, or components of the Sugar software stack.

0. Propose candidate projects

Propose 2 or 3 projects you'd like to look at.

1. Choose your team.

We'll be doing this in class, and teams must be approved by your instructor. We'll use proposed projects as an organizing tool.

2. Choose a FOSS Project.

You can draw upon the same collections of software introduced prior to the bugfix assignment.

Select one active software project to analyze. Have an alternative handy if you find that you cannot get much information about your first choice. Project choices must be approved by your instructor.

3. Write a project proposal blog post

Write a blog post to present the project(s) you propose to analyze. Discuss what other projects you considered and why you chose what you chose. Include links at least to the projects you've chosen. Make some attempt to assign roles to team members, and otherwise address the items from teamproposal

4. Run Git By A Bus analysis on your project

Follow the instructions included in the "Git By A Bus" repository on Github to generate a report on your selected project, available here:

https://github.com/tomheon/git_by_a_bus/tree/v2 (More powerful but output is raw. Run it as gbab.py)

or, alternately:

https://github.com/ryansb/gitbyatruck

or any newer forks of the above.

You may wish first to run GBAB on itself, or on another small trial project like https://github.com/FOSSRIT/sugar-quickstart

5. Calculate your project's "Callaway Coefficient of Fail"

Calculate your project's "Callaway Coefficient of Fail" using the rubric available here: http://hfoss17s-ritjoe.rhcloud.com/static/books/tomspotcallaway-howtotellifyourfossprojectisdoomedtofail.pdf

See also: https://www.theopensourceway.org/wiki/How_to_tell_if_a_FLOSS_project_is_doomed_to_FAIL

5a. (Alternate analysis tool) Use some other method to attempt to quantify the quality of the project

This will entail making a sort of mini-proposal to get the method approved by the instructor before using it.

6. Dig deeper. Provide answers to the following questions:

If applicable, list or provide links to:

• I. The project's IRC Channel

• II Source Code repository

• III. Mail list archive

• IV. Documentation

• V. Other communication channels

• VI. Project Website and/or Blog

• A. Describe software project, its purpose and goals.

• B. Give brief history of the project. When was the Initial Commit? The latest commit?

• C. Who approves patches? How many people?

• D. Who has commit access, or has had patches accepted? How many total?

• E. Who has the highest amounts of "Unique Knowledge?" (As per your "Git-by-a-bus" report. If there is a tie, list each contributor, with links if possible)

• F. What is your project's "Calloway Coefficient of Fail?"

• G. Has there been any turnover in the Core Team? (i.e. has the same top 20% of contributors stayed the same over time? If not, how has it changed?)

• H. Does the project have a BDFL, or Lead Developer? (BDFL == Benevolent Dictator for Life) If not, what is the structure of its leadership, and how is it chosen?

• I. Are the front and back end developers the same people? What is the proportion of each?

• J. What have been some of the major bugs/problems/issues that have arisen during development? Who is responsible for quality control and bug repair?

• K. How is the project's participation trending and why?

• L. In your opinion, does the project pass "The Raptor Test?" (i.e. Would the project survive if the BDFL, or most active contributor were eaten by a Velociraptor?) Why or why not?

• M. In your opinion, would the project survive if the core team, or most active 20% of contributors, were hit by a bus? Why or why not?

• N. Does the project have an official "on-boarding" process in place? (new contributor guides, quickstarts, communication leads who focus specifically on newbies, etc...)

• O. Does the project have Documentation available? How extensive is it? Does it include code examples?

• P. If you were going to contribute to this project, but ran into trouble or hit blockers, who would you contact, and how?

• Q. Based on these answers, how would you describe the decision making structure/process of this group? Is it hierarchical, consensus building, ruled by a small group, barely contained chaos, or ruled by a single or pair of individuals?

• R. Is this the kind of structure you would enjoy working in? Why, or why not?

7. Publish your analysis as a blog post 40 pts

Write up a set of answers to these questions including how you arrived at your conclusions (links, convo quotes, irc logs, email threads, etc.) to be posted to your blogs individually. Each member can link to the same analysis, but should give a personal account "in your own voice."

8. Present your analysis to the class 30 pts

Prepare in a brief slide-deck to present as a group to the class based on your research.

9. Review your teammates' work 30 pts

For more on 8 and 9, see CommArch evaluation and presentation