User:Cbrooks
Name: Chris Brooks
Position: Professor, Computer Science and Associate Dean for Academic Operations, University of San Francisco
email: cbrooks@usfca.edu
I'm new to POSSE and HFOSS, but have been involved with or used free and open-source software for over 20 years. I'm very interested in ways that computing and technology can be used to address problems of social justice and inequality. Previously, I was the director of Community Connections, a technology-oriented community-engaged learning project here at USF where students used their skills in direct service of community needs. We worked with local computer labs to provide job training and support and tutoring, and led a yearly immersion trip to Tacna, Peru to partner with K-12 schools there to bridge the digital divide.
My research areas include artificial intelligence, machine learning, computational economics, and multiagent systems.
Outside of work, I love hiking, running, the Grateful Dead, science fiction, and playing dungeons and dragons with my 10-year-old son.
Intro to FOSS notes.
Sugarlabs: The most obvious places for my students to get involved would be as Developers or perhaps Designers. There's a wide variety of roles, and necessary skillsets, but all participants will need an understanding of Sugar and its goals, as well as the FOSS approach to software development more broadly.
Sugar uses github to post bugs. Issue tags are bug, design, errata, feature, needs SLOBS, needs work. The last commit in the core sugar branch was April 30.
Sahana: Sahana is looking for developers, testers, translators, designers, sysadmin, and GIS specialists. Unlike Sugar, they don't request educators or communications support.
Sahana's repository uses a much richer labeling system. The last commit here was May 2. I wasn't able to view the Sahana roadmap. For both projects, I was a little suprised that they were still using versioning, rather than continuous improvement. Sahana seems more mature in that respect.
FOSS Field trip notes:
pt 1: GitHub
searching for 'education':
Education: 27,840 repositories, with 3455 Javascript
Most recent: Ebook Foundation
Least recent: timjacobi/angularjs-education
Most stars: freeCodeCamp (303k)
228 open issues
13,336 closed issues
Pull requests: 1781 open 20332 closed
Insights: stats describing the project history
HTBox/crisischeckin - 178 stars, uses C#, last updated 10/24/18
other search terms:
Disaster management: 473 repos.
Refugees: 1352 repos
pt 2: OpenHub:
2270 education projects
I recognize Moodle, Sakai, gnu plot, Wireshark, and groovy
I don’t see any KDE Education repos on GitHub
Similar projects include kStars, Step, KmPlot and Kig
Humanitarian: 23 projects
Disaster management: 30 projects
Refugee: 3 projects
Activity Not Available indicates that the activity tracking data cannot be captured - perhaps the code location is down or the project is configured incorrectly.
Organizations shows orgs such as Apache Foundation and Wikimedia Foundation that have many projects.
Clicking on the OpenMRS organization shows the 46 projects overseen by OpenMRS.
OpenMRSCore has an activity not available icon. On GitHub we can see that there have been two commits this week. It would seem that there are some projects that are hosted in locations visible to GitHub, but not too OpenHub.
GitHub has a slicker search interface, but I like the Organizations feature of OpenHub.
Project Evaluation: OpenMRS
Evaluation Factor | Level (0-2) |
Evaluation Data |
---|---|---|
Licensing | 2 | OpenMRS uses the Mozilla License, which OSI deems 'open' and FSF deems 'free' |
Language | 1 | OpenMRS uses Java. I know Java, but do not particularly like working in it, and am rusty. |
Level of Activity | 2 | OpenMRS is certainly active, with commits almost every week. |
Number of Contributors | 2 | There are 323 contributors |
Product Size | 1 | OpenMRS is 332MB of code, which is pretty big. |
Issue Tracker | 2 | There are 485 'ready for work' issues, and 4027 closed issues. The third curated issue (regarding TODO tickets) was opened 5-21-08. In general, OpenMRS seems to be quite active. |
New Contributor | 2 | OpenMRS looks quite friendly to newcomers - there are detailed instructions for downloading and building, and also for getting involved. |
Community Norms | 2 | OpenMRS has a very explicit and detailed Code of Conduct. Some specific things I like: Instructions about how to disagree respectfully, encouraging people to speak out if they feel uncomfortable, and to be collaborative. Setting a proper tone of collaboration and working together in a positive way to address problems is very important. The interaction I see in the TALK page is quite positive - people are either providing help, discussing the details of different problems, or complimenting each other. |
User Base | 2 | OpenMRS seems to have an active user base. As mentioned above, there are detailed descriptions about how to download and run the system (very important with Java, which can have weird dependencies at times) |
Total Score | 16 |
Intro to Copyright and Licensing
OpenMRS uses the Mozilla Public License, and Fineract uses (surprise!) the Apache license. I wasn't able to find a license for regulately.
I would be fine with using the Mozilla and Apache licenses. For regulately, I would want to find out from the maintainer what their expectations were before going too far down that path.
FOSS in courses
I used to teach a class called Computers and Society, which I'm hoping to revive with a HFOSS flavor. It's part social and ethical issues in computing, part community-engaged learning, and part software development. In the past, we've looked at case studies of different computing scenarios (e.g. Diebold voting machines), engaged in direct service (e.g. setting up computer labs for SF nonprofits) and worked as a team on large software projects, such as a web-based tool for inventorying computer labs.
I'd like to have students in my class engage with HFOSS in a number of ways: 1. discussing the philosophical and social issues around openness. This includes open source, open data, and the open web more generally. What are the pros and cons of an open vs walled garden approach? Where can they see this in current projects? How can transparency and openness support fundamental values of freedom and privacy?
2. Evaluating an HFOSS community - both the developers and ideally the end users. What is the core problem they are trying to address? Why does that problem exist? Why is this sort of community structure effective? They should get comfotable downloading the code, browsing the forums, following IRC< and explaining the goals of the project.
3. Contributing to an HFOSS project. This will likely be very modest - identifying fixed bugs, contributing to documentation, maybe even patching a bug if they're lucky. I would love to engage folks from places like Mozilla in this, given that they're our neighbors.
There's a lot of great material here to start with in terms of reading about the philosophy of FOSS, licensing, copyright, etc. I'd like to find some more current writings about FOSS design philosophy - how have people's thinking evolved since _Cathedral and the Bazaar_? What lessons have been learned? I'd also like to include some material on the Open Web -I've been following the projects at the Internet Archive and am very interested in their idea of applying a FOSS approach to the architecture of the Web as a whole.
Intro to Bug Trackers
GNOME's issue tracker has quite a few different projects associated with it: gimp, libxml, geary, gnome-shell-extension, epiphany, fractal, evince and mutter are just some of the projects on the first two pages.
Each bug notes the comment or bug - most are just opened, but a few have comments.
Labels include: Bug, RFC, Needs Diagnosis, Needs Design, Component: Printers, Component: Region & Language, Crash, User Interface, and OS X.
- 2 labels classify the potential solution or category of bug, #3 labels seem to be indicators to send the ticket back to the user. #4 labels call out for someone to take this on. #8 labels refer to documentation - useful tasks for non-programmers to take on. #9 labels refer to management of the repo.
The Board has four columns. Open refers to issues that are awaiting triage and assignment, Stretch are issues that are part of the long-term vision, Deliverable are intended for the next release, and Closed are completed.
GNOME seems to use milestones to group together related features and fixes for new versions. Some packages include large numbers (> 100) of issues, while others have only a few.
Merge requests are requests to do just that - add a fix or extension back into the main codebase.
FOSS in courses, pt 2.
In the past, I've had students keep a blog - I would give them weekly readings and writing prompts and require them to link to and comment on each other. I'd love to use readings on open source and open data as part of this. It would also be interesting to have the students learn about open-source as a business model.
Preparation for this would involve identifying articles, and preparing some discussion prompts.
I expect students by this point will have had some experience using git. I would like to so a lab to reinforce their git skills and have them engage with a real HFOSS project. This would be similar to what we've seen here - do a project evaluation, check out the code, identify project workflow, and learn about the community.
The one I'm most excited about, but that's hardest to conceptualize, is having them participate in coding for a FOSS project. I think there's two pieces here - making the incremental fixes needed for a FOSS project, and doing a larger team project. For the latter, it might be simpler to create a branch that we never expect to fold back in and ask them to augment it in some way.