POSSE homework: how to contribute to FOSS without coding

One of the assignments for the POSSE workshop is the question of how to contribute to FOSS when you aren’t a coder.

I find this an especially interesting topic because I think there’s a broader political significance to FOSS, but those that see FOSS as merely the domain of esoteric engineers can sometimes be a little freaked out by this idea. It also involves broader theoretical questions about whether or how open source jives with participatory design.

In fact, they have compiled a list of lists of ways to contribute to FOSS without coding: this, this, this, and this are provided in the POSSE syllabus.

Turning our attention from the question in the abstract, we’re meant to think about it in the context of our particular practices.

For our humanitarian FOSS project of choice, how are we interested in contributing? I’m fairly focused in my interests on open source participation these days: I’m very interested in the problem of community metrics and especially how innovation happens and diffuses within these communities. I would like to be able to build a system for evaluating that kind of thing that can be applied broadly to many projects. Ideally, it could do things like identify talented participants across multiple projects, or suggest interventions for making projects work better.

It’s an ambitious research project, but one for which there is plenty of data to investigate from the open source communities themselves.

What about teaching a course on such a thing? I anticipate that my students are likely to be interested in design as well as positioning their own projects within the larger open source ecosystem. Some of the people who I hope will take the class have been working on FuturePress, an open source e-book reading platform. As they grow the project and build the organization around it, they will want to be working with constituent technologies and devising a business model around their work. How can a course on Open Collaboration and Peer Production support that?

These concerns touch on so many issues outside of the consideration of software engineering narrowly (including industrial organization, communication, social network theory…) that it’s daunting to try to fit it all into one syllabus. But we’ve been working on one that has a significant hands-on component as well. Really I think the most valuable skill in the FOSS world is having the chutzpah to approach a digital community, propose what you are thinking, and take the criticism or responsibility that comes with that.

What concrete contribution a student uses to channel that energy should…well, I feel like it should be up to them. But is that enough direction? Maybe I’m not thinking concretely enough for this assignment myself.

POSSE and the FOSS field trip

I’m excited to be participating in POSSE — Professor’s Open Source Software Experience — this coming weekend in Philidelphia. It’s designed to train computer science professors how to use participation in open source communities to teach computer science. Somehow, they let me in as a grad student.

My goals are somewhat unusual for the program, I imagine. I’m not even in a computer science department. But I do have background in open source development, and this summer I’ll be co-teaching a course on Open Collaboration and Peer Production at Berkeley’s I School. We aren’t expecting all the students to be coders, so though there is a hands on component, it may be with other open collaborative projects like Wikipedia or OpenStreetMap. Though we aren’t filling a technical requirement (the class is aimed at Masters students), it will fulfill a management requirement. So you might say it’s a class on theory and practice of open collaborative community management.

My other education interest besides my own teaching is in the role of open source and computer science education in the larger economy. Lately there have been a lot of startups around programmer education. That makes sense, because demand for programming talent exceeds supply now, and so there’s an opportunity to train new developers. I’m curious whether it would be possible to build and market an on-line, MOOC-style programming course based on apprenticeship within open source communities.

One of our assignments to complete before the workshop is an open source community field trip. We’re suppose to check out a number of projects and get a sense of how to distinguish between strong and weak projects at a glance.

The first thing I noticed was that SourceForge is not keeping up with web user experience standards. That’s not so surprising, since as a FOSS practitioner I’m more used to projects hosted on GitHub and Google Code. Obviously, that hasn’t always been the case. But I’m beginning to think SourceForge’s role may now be mainly historic. Either that, or I have a heavy bias in my experience because I’ve been working with a not of newer, “webbier” code. Maybe desktop projects still have a strong SourceForge presence.

I was looking up mailing server software, because I’m curious about mining and modding mailing lists as a research area. Fundamentally, they seem like one of the lightest weight and most robust forms of on-line community out there, and the data is super rich.

Mailing lists on source Forge appear to be mainly in either Java, PHP, or some blend of Python and C. There are a couple Enterprise solutions. Several of the projects have moved their source code, hosted version control, and issue tracking off of SourceForge. Though the projects were ranked from “Inactive” through “Beta” to “Mature” and “Production/Stable”, usage of the tags was a little inconsistent across projects. Projects with a lot of weekly downloads tended to be either Mature or Production/Stable or both.

I investigated Mailman in particular. It’s an impressive piece of software; who knows how many people use Mailman mailing lists? I’m probably on at least ten myself. But it’s a fairly humble project in terms of its self-presentation and what people have done with it.

Turns out it has a lead developer, Barry Warsaw, who works at Canonical, and a couple other core committers, in addition to other contributors. There appears to be a v3.0 in production, which suddenly I’m pretty excited about.

POSSE has a focus on humanitarian FOSS projects. I’m not sure exactly how they define humanitarian, “that is, projects for which the primary purpose is to provide some social benefit such as economic development, disaster relief, health care, ecology. Examples include Mifos, Sahana and OpenMRS.”

For the purpose of this workshop I plan to look into Ushahaidi. I’ve heard so many good things about it, but frustratingly even after working four years on open source geospatial software, including a couple crowdsourced mapping apps, I never took a solid look at Ushahidi. Maybe because it was in PHP. I’m proud to say the project I put the most effort into, GeoNode, also has a humanitarian purpose. (GeoNode also now has a very pretty new website, and totally revamped user interface for its 2.0 release, now in alpha.) And though not precisely a software project, I’ve spent a lot of time admiring the intrepid Humanitarian OpenStreetMap Team for their use of open data as a humanitarian means and end.

But Ushahidi–there’s something you don’t see everyday.

We’re asked, on the POSSE field trip prompt, how we would decide whether our selected project was worth contributing to as an IT professional. The answer is: it depends on if I could do it for my job, but I’ve asked around about the project and community some and it seems like great people and usable software. I’d be proud to contribute to it, so at this point I expect my comparative advantage would be on the data analysis end (both of the community that builds it and data created by it) rather than to the core.

We were also asked to check out projects on Ohloh, which has also had a user interface revamp since I last looked carefully at it. Maybe significantly, we were asked to compare a number of different projects (two of them web browsers), but there was no feature on the website that provided a side-by-side comparison of the projects.

Also, one thing Ohloh doesn’t do yet is analytics on mailing lists. Which is odd, since that’s often where developers within a community get the most visceral sense of how large their community is (in my experience). Mailing lists wind up being the place where users can as participants affect software development, and where a lot of conflict resolution occurs. (Though there can be a lot of this on issue tracker discussions as well.)

This summer I hope to begin some more rigorous research into mailing list discussions and open source analytics. Seeing how Ohloh has moved forward reminds me I should be sharing my research with them. The focus of POSSE on project evaluation is encouraging–I’m curious to see where it goes next.