COSA Clinics

# Some thoughts from the 2019 Clinics

COSA’s ‘Preliminary Diagnosis’ of some Vital Questions

We hosted three clinics in 2019 that brought together about twenty discussants: at UCLA in Los Angeles, and at Babycastles and NYU in New York. In those first three clinics, we spent ten hours talking with leading open source software toolmakers, contributors, community organizers, and thinkers. Below, we share some of the key insights that emerged during these conversations. These questions came up again and again in our initial clinics, and are at the heart of our project.

What is a healthy open source software project?

Conventional wisdom suggests that a ‘healthy’ open source software project is one with a growing user/contributor base, has good documentation, and is well maintained. A project could tick all those initial boxes and have a completely homogeneous (i.e. overwhelmingly white male) user and/or contributor base — that is not healthy. Another problem with headcounts is they do not capture the difference between indifferent users and empowered ones. The best tools create impassioned advocates who, transformed by their experiences, are motivated to give back to the community.

One software project that has been central within our initial clinics was p5.js — a native JavaScript alternative to Processing.js that lives in the browser and appeals to folks that are comfortable coding for the web. Quite notably, p5.js built diversity ‘into’ their mandate rather than addressing it as an afterthought. By rethinking what a ‘contributor’ was, and providing an abundance of generous on-ramps to welcome curious, novice users early in their community growth, they have nurtured an incredibly diverse and enthusiastic user base — and reaped the benefits of that foresight. In the 2nd COSA clinic at Babycastles, Irene Alvarado (a Creative Technologist at Google Creative Lab) pointed out that “the healthiest communities I participate in have a very rich offline community — it’s still about like that one-to-one connection.” We agree!

How can open source software projects develop resilience?

There is a glib joke about measuring the resilience of a piece of open source software: would development continue if the lead developer was hit by a bus? It’s a grim analogy but these concerns are very real in niche software, small projects that are maintained by one, two, or a handful of contributors. Health and wellness are one factor, and so is financial sustainability; with commercial software a source of revenue is clear — sales — but the economics get fuzzy in the world of open source passion projects.

“I think if a tool doesn’t have a business model — p5.js and Processing don’t really have one apart from institutional support — then I think these issues emerge in a way that’s much more apparent, because their development requires voluntary labour.”

Tega Brain (Assistant Professor of Integrated Digital Media, NYU)

COSA will develop a guide of practices for the teams making tools, to bolster their resiliency.

How do we empower the next generation of creators?

This is an important question and one our discussants (many of whom are educators) were extra passionate about. Consensus was that toolmakers, educators, and institutions, need to provide ‘on ramps’ that invite new users to the world of open source software. Some examples: fellowships (that help build and sustain careers), classes centred on contributing to and interrogating open source software (versus being trained in vocational ‘industry standard’ tools), community (meetups, slacks, discords, etc.) and mentorship programs.

“Sometimes in my classrooms there’s this vibe where I feel like I’m giving my students a trail of breadcrumbs to follow — really half baked references — and they’re looking up tutorials and kind of panicking, and second guessing if they are running the right version of Python. And sometimes I see the look in their eyes while this is happening and think to myself ‘oh my God, this looks like a complete mess to them!”

Saber Khan (Processing Foundation, Education Community Director)

The above quote identities a significant hurdle: the chaos of documentation. Over time — with considerable headaches — open source veterans learn to navigate myriad sources including Github, user forums, and out-of-date documentation to debug, troubleshoot, and solve issues — a routine that is super alienating for newcomers. Keeping tutorials and documentation up-to-date (across multiple languages) needs to be prioritized within open source software, to help novices get their bearings. We believe when communities prioritize documentation that investment will pay dividends (more engaged users!) over time.

How do we educate institutions?

Ironically it’s not just students that need ‘on ramps’ as both public school systems and higher education require coaxing to recognize the value of using open source tools in the classroom. The burden of advocacy falls on teachers, directors, and administrators to communicate that there is a difference between building digital learning around (e.g.) Adobe’s monolithic creative suite and open source tools; with the former, valuable tuition dollars go into expensive seat licenses, while the latter introduces students to an entirely different learning paradigm. Granted, working in open source requires a lot more code literacy and engagement, but we believe reciprocity and stewardship are exactly the kind of values we want to be promoting in education.

Another issue: we need to help institutions understand that using open source tools is not just a cheap alternative to pricey corporate offerings. Educational institutions need to be ‘good citizens’ and provide financial support (or resources) to ensure the open source software being used in their classrooms will be around a decade from now.

How do we educate the art world?

Like higher education, the art world moves slowly. While we are not super concerned if gatekeepers think the digital renderings a twenty year old is making with Blender are ‘art’ or not, the lack of software (and hardware) literacy in the art world impacts creators. Dated ideas about where aesthetics begin and end can freeze creators working in emerging mediums out of funding, and when new media art does end up in art collections — it brings preservation issues along with it. What kind of liberties can a digital preservationist take in translating a code-based artwork into a contemporary programming language? Likewise, when software is discontinued it affects work created with it (one only need look as far as the open source translators people are making to play work built in Adobe’s discontinued Flash environment). We believe more literacy is needed around these issues, to support the increasing flow of new media art into collections.

“The digital arts has such a short genealogy compared to the rest of the art world, and the language being used to describe that work can be alienating or misunderstood. It can take a lot of work to just get a public onboard to approach software-based work with an open mind. It’s almost as if this type of work needs to be explained before it can be appreciated … you just don’t have to do that work to describe a painting or a textile design.”

Dorothy Santos (Processing Foundation, Program Manager)

Who can COSA learn from?

A number of great initiatives came up during the clinics — exemplars of resilient communities around open source tools. Generally speaking, there is considerable excitement around open data in municipal use (to promote civic engagement and transparency) and citizen science. In terms of specific projects, the amazing communities around the livecoding language TidalCycles and the children’s programming language Scratch was duly noted. Clinic participants also pointed to Google Summer of Code and Mozilla Open Leaders as great initiatives, whose models could perhaps be emulated in other communities. The New Museum’s cultural incubator NEW INC also warrants mention for its commitment to exploring the entrepreneurial side of arts and culture production. Finally the Internet Archive, WC3, and Rhizome, were all recognized for their work in preserving and sustaining the web.

There are lots of folks out there doing great work, and part of our excitement around COSA is learn from the strategy and tactics employed across the entire gamut of the tech sector.

Did we miss anything?

We know our initial conversations were not all encompassing, and perhaps skewed by the fact that so many of our participants are working in or adjacent to higher education. We want to be clear that the above purview is very much a work-in-progress — and we are open to feedback. If after browsing this summary you feel we’ve overlooked a critical issue, or that you could contribute to or support COSA somehow, please get in touch.

(Thanks to Greg J Smith for his work on this text, drawn from COSA documents and the Clinic transcripts.)