Organized by the Clinic for Open Source Arts (COSA) and the Processing Foundation, the first Open Source Arts Contributor’s Conference (OSACC) was held April 13–16th, bringing together 70 open source software contributors, artists, and educators to convene at the University of Denver. For three days representatives from the Open Source Software (OSS) coding frameworks including Hydra, Netnet, New Art City, openFrameworks, OPENRNDR, p5.js, Processing, Shaderpark, and Sonic Pi gathered for development and roadmap sprints. In between the work sessions, attendees broke into ‘unconference’ style groups for guided discussions about what more accessible and sustainable software development and maintenance could look like, and reflected on best practices for teaching and education.

The convergence of teams and communities at OSACC was important because software focused on art and design faces some distinct challenges, but also has unique opportunities. The art and design space is a little more open to experimentation, and many of the invited teams lead by example (compared to the broader OSS milieu) by enacting bold equity and accessibility mandates. The invitees were carefully curated to assemble many of the best and brightest — creators of tools used by hundreds of thousands worldwide — to parse the challenges of making open and free creative software.

The atmosphere was electric — everyone was clearly excited to be in the same room. A world of sharing happened outside the formal schedule. The group ate big communal meals, folks gave impromptu demos, and a series of speed talks took place during breaks, where anyone could share work or provocations. Sometimes a veteran software developer or tenured professor who runs a well-funded lab presented and was followed by an undergrad student, who earnestly shared their latest project. That everyone was received equally speaks volumes about the lack of hierarchy and community of support at OSACC.

For three days, the assembled teams worked steadily to advance their projects, and generously exchanged ideas with other attendees. What follows are summaries of the two major scheduled activities: the working sessions (several of the teams have provided summaries of what they accomplished at the conference) and the guided discussions (represented as a series of key questions that bubbled up in discussions around three major themes).

WORKING SESSIONS

Bringing teams together was a key goal of OSACC. Beyond the expected socializing and exchange of ideas, time was provided for teams to engage in face-to-face planning and development. Here is a brief team-by-team recap of what invited platforms accomplished.

Jennifer Jacobs and graduate student Devon Frost represented UCSB’s Expressive Computation Lab (ECB). A bit of an outlier, they came to engage and learn from OSS teams to “develop sustainable open-source platforms for digital fabrication,” bringing along an early prototype of CoilCAM, a toolpath programming system for 3D printing with clay (which they demoed in an impromptu workshop).

Olivia Jack of the browser-based live coding video synth Hydra worked on updating documentation, and “reflected on growing slowly and intentionally” and accessibility in conversations with other teams. “We learned about experiences the Processing and openFrameworks teams had supporting user libraries and plugins, and discussed tradeoffs between adding features to the core source code versus a small and extensible base,” shares Jack.

After primarily collaborating online for the last few months, netnet contributors Nick Briz, Sarah Rooney, Jon Chambers, and Chloe Thompson were thrilled to work together IRL during OSACC. In their working session they efficiently advanced development work on their HTML and CSS education platform, as well as brainstorming “a new game plan for our third refactor.” Briz shares that the team benefitted not only from working face-to-face “but maybe more importantly because we were sharing that space with like-minded folks.”

Theodore Watson of openFrameworks arrived at OSACC with sustainability and the platform’s roadmap top of mind. Watson convened with the p5.js team to discuss how they have “created space for others to take the lead,” actively recruited from underrepresented groups, and experimented with leadership rotation. During education-related guided discussions he engaged new OSS users“ to see what tools they are gravitating towards and what needs they have” to inform how future users are onboarded into openFrameworks; conference attendee Chloe Thompson has subsequently joined the team to help with those onboarding initiatives (and the platform’s website).

Edwin Jakobs and the OPENRNDR team attended OSACC to connect with Processing and openFrameworks leadership to get their input on “workload, leadership, funding, and organic growth.“ They also led several demos of their framework, and were reminded that “even onboarding new users in such a casual environment is still incredibly hard.“

Virtual exhibition toolkit New Art City were unique participants in the conference: a commercial project built with the open source three.js framework. Sammie Veeler notes it was “interesting to attend as a beneficiary of open source, and think of ways the models of contributing a code base could be applied to contributing to a collective purpose in other ways.“ Since OSACC, New Art City has accelerated initiatives to nurture preservation and accessibility, and launched the Virtual Access Lab, an independent nonprofit research unit sponsored by Gray Area.

“I started leading p5.js during the pandemic, and I’ve been really craving face-to-face meetings with its community,” writes P5.js Project Lead Qianqian Ye of the enthusiasm she brought to OSACC. Project contributors moved forward on several initiatives at the conference: Evelyn Masso led a discussion to update the framework’s access and community statements, and code of conduct; and Alm Chung, Kenneth Lim, and Dave Pagurek reflected on GitHub issue accessibility and software and documentation translation. “We even had a meet and greet session for mentors taking part in this year’s Google Summer of Code program, which p5.js is a part of,” says Ye.

OSACC co-presenters Processing Foundation arrived in Denver with over 20 project contributors including project team leads, fellowship recipients, foundation staff, and board members. “OSACC provided a rare and precious opportunity for the globally dispersed Processing Foundation team to come together in a single location, allowing many of us to meet face-to-face for the very first time,” shares and Processing Community Lead Raphaël de Courville. The team used their working sessions to “enhance the user journey” of the Processing.org examples page, and also conducted a heartfelt first public reading of the Processing Community Catalog, a compendium of “two decades of the Processing community’s achievements and creativity.”

Shader Park, a JavaScript library for creating interactive procedural shaders, was represented at OSACC by Torin Blankensmith and Peter Whidden. The duo used their time at the conference to work with Dave Pagurek and Olivia Jack to develop and refine p5.js and Hydra Shader Park plug-ins, to create documentation for potential core contributors, and discuss WebGPU’s potential as a new standard. “We got to meet with a number of people that helped get us into creative coding. It was a really incredible meetup and we came away from it feeling very inspired,” shares Blankensmith.

“Software projects often appear faceless, concealing the individuals behind them. However, behind every open source project, there are real people who may be feeling burned out, lost, or anxious. That’s why events like OSACC, where we can all come together in person, feel like warm hugs that last a long time.” — Qianqian Ye, p5.js

GUIDED DISCUSSIONS

Below are nine of the key questions asked during the OSACC guided discussions. These are not presented as a definitive summary of the discussions but a ‘core sample’ of issues covered. And they are organized around key questions, because there are no easy answers here. OSS development is a chronically underfunded, stressful-but-amazingly-rewarding labour of love — hopefully the passion and resilience of the attendees shines through.

ACCESS

“Accessibility is often viewed through the lens of compliance, as an annoyance after the fact rather than as a foundational principle.” — Sammie Veeler, New Art City

The word on the tongue of every community builder is access. Access reduces the burden of entry into an organization and helps it grow both its numbers and capacity. When referring to a physical venue, ‘access’ might imply physical accessibility — a first-floor venue free of physical obstructions, etc. In the world of software development access speaks to legibility and vibe. Code structure and repos, documentation, tutorials, websites, discord structure, social media presence — these all send signals to potential users. They can make them feel welcome, excited to learn more, and put them on the road to becoming a contributor if executed correctly, or make them feel confused or alienated — scare them off — on the undesirable end of the spectrum.

“You can’t always make tools for everyone. Designers must accept that they can’t capture everyone’s lived experience. Leaving agency for users, participants, and community members is part of the design process.” — Nat Decker

Key Questions

What’s an accessible first contribution?

Within OSS communities where survival requires developing a community of interest, care, and contribution, this is a ‘first principles’ question. The Accessible Open Source Software guided discussion focused on removing barriers of access so a greater number OSS users could make the leap and make their first contribution to a project. Traditionally this benchmark of ‘a contribution’ was a code commit on a repo like GitHub, but that benchmark is a quite high bar of entry. The conversation focused on expanding ‘contribution’ to consider smaller (less technical) benevolent acts: correcting typos in documentation, answering questions on Discord, logging ‘this doesn’t work well for me’ UX issues (compared to the traditional bug report). Basically, rethinking the nomenclature of ‘contribution’ to be less about code and more about care.

How can resources be funnelled towards making educational content more accessible?

More often than not, making course material accessible is a burden that individual teachers take on. This is a problem given teachers are generally overextended, and ensures slow progress towards making classrooms more accessible. Thinking about funding, support, and training that higher education (and all educational environments) could provide to help nurture more accessible educational content as a default was a primary concern of the Access and Education guided discussion. This question of resource allocation is particularly vexing within postsecondary education, where policy makers and administrators are all too often focused on the bottom line and there is no economic incentive to make content more accessible.

What are best practices and useful resources for creating open source projects when being too open or legible could be dangerous, problematic, or counter-productive?

Focused on nuanced cases where providing unfettered access to stakeholders is not desirable, the Data Sovereignty & Community Access group ruminated on best practices for handling sensitive data related to oppressed, surveilled, or vulnerable populations. Discussing how to seek consent, protect anonymity, and assess the needs and perspectives of underserved communities, the group challenged many of the assumptions that designers and researchers bring to projects (e.g. a data visualization, map, or survey) where the desire may to provide an omniscient view of the subjects being represented. Designers have responsibility when deciding what data is presented and anonymized — the scope of that responsibility can only be determined by consulting with the communities being represented.

SUSTAINABILITY

“There are so many people in the community that want to help out, it’s just a matter of connecting with them.” — Qianqian Ye, p5.js

One of the primary benefits of bringing together OSS contributors is to provide space, time, and sympathetic ears for sharing the stress, fatigue, and burnout that is endemic within open source software development. At times, OSACC felt like group therapy with teams opening up about their difficulties and also brainstorming new strategies to ease the burden of making software with limited (or no) resources. The sustainability-focused guided discussions parsed issues including the toll leading an OSS project takes on founders and directors, the strain of leadership succession and onboarding new team members, and the less pleasant aspects of managing community.

“Leading a project shouldn’t create situations where sequential people get burnt out.” — Theodore Watson, openFrameworks

Key Questions

How does OSS leadership make the plans for fundamental design decisions and meeting action items legible so that it is easier to onboard future core contributors?

Project management is difficult on any team but exponentially more for a team of unpaid volunteers juggling other obligations spread across multiple time zones. Lacking the funding for dedicated project managers that would shepherd a commercial software release towards completion, OSS project leads and core contributors often double as project managers on top of their other duties. This was just one of the pain points discussed in the Sustainable Maintenance guided discussion that considered the nuances of how governance, delegation, and documentation contribute to how effectively (or ineffectively) new contributors are onboarded.

How do you deal with active contributors who don’t follow the values of the community?

This touchy issue was explored within the Sustaining Community group, who discussed how to manage and maintain a growing developer base with different personalities and communication styles. While the expectation in OSS is benevolence, occasionally community members might act or communicate in ways that do not align with a (formal or informal) code of conduct — they need to be nudged in the right direction. If they aren’t, inaction can undermine core values and alienate and discourage community members from stepping forward to get more involved. These kinds of issues need to be dealt with as they arise regardless of the discomfort and emotional labour involved.

When your OSS is used to make income, how do you collect a ‘tax’ to compensate for all the work that happens behind the scenes?

This perennial OSS question was discussed within the Sustaining Funding guided discussion. Frequently, commercial entities (e.g. an ad agency) derive much more financial value from an OSS than the team making it. If the OSS is struggling financially, this disparity is an existential threat. So through what process or protocol can some of the revenue generated through an OSS flow back to the community maintaining it? This question also appears in education (not just in higher-ed, code bootcamps and artist-run centers as well), where revenue is not necessarily directed back to the community maintaining the tool being taught. OSS communities need to create a sense of urgency, collective responsibility, and calls to action to cultivate symbiotic relationships with industry and the academy.

“Teaching the correct ethos — of sharing, reciprocity and inclusivity — is just as much part of teaching open source as the technical aspects. It’s important to acknowledge and celebrate the time, effort, and labor that goes into being part of these projects and communities” — Roopa Vasudevan, University of Massachusetts Amherst

EDUCATION

Sharing and knowledge transfer is at the heart of the open source ethos. And so is an altruistic vision about what education can and should entail. But teaching OSS requires a lot of nimbleness and there is no one-size-fits-all approach. Conversations about teaching encompassed both the ‘how?’ (best tutorial writing and documentation practices) but also the ‘what?’ and the ‘where?’ Ironically, one of the biggest challenges of teaching OSS amongst the education guided discussions were the constraints imposed by postsecondary education (bureaucracy, class size, focus on ‘employability’ etc.).

“We’re trying to understand the ways in which the digital fabrication research community might build on approaches used in OSS creative coding communities to broaden participation in computational approaches to digital fabrication.” — Jennifer Jacobs, Expressive Computation Lab

Key Questions

How to manage a classroom with students of vastly different technical ability?

Managing a classroom where some students are fluent and others are struggling to get up to speed is extremely challenging — and this problem is exacerbated by large class size, which further erodes ‘facetime’ between individual students and their instructors. One innovative solution that bubbled up in the Teaching Students with Different Technical Backgrounds discussion was pairing up comfortable and less comfortable students, reducing pressure on the teacher and teaching assistants, and imbuing a sense of stewardship and responsibility in the more technically proficient student.

Is teaching a collaborative and noncommercial ethos part of teaching about open source?

Traditional computer science is tied to commercial software, market cycles, and profit. Teaching open source tools doesn’t have to be bound to the same capitalist frame of reference, but how much of the reciprocity and care that constitutes OSS culture should make it into the classroom? This was one of the thorny philosophical questions discussed within the Teaching What It Means to Be a Contributor guided discussion, where educators weighed in on what constitutes an ideal education — OSS principals wise — while also acknowledging a duty to ensure students have skills that make them employable.

How do you scaffold the process of moving between a tutorial and open-ended production?

Pressing run on a Processing sketch is fairly low stakes, the same does not apply to a $250,000 CNC milling machine. The Teaching Hardware guided discussion addressed the steep complexity jump that comes with moving from code editor to digital fabrication. At a base level the equipment involved is often expensive, fragile, or dangerous, so specialized training in materials and machines is needed, but students inevitably have to struggle in order to get comfortable in a production environment. How do we make that struggle as pain free (and safe) as possible? The discussion focused on identifying sufficient training, documentation, and protocols that strike a careful balance of ‘guiding but not overwhelming’ students.

Thanks to Greg J Smith of HOLO for his work on this article.