December 5, 2018 From rOpenSci (https://deploy-preview-121--ropensci.netlify.app/blog/2018/12/05/commcall-dec2018/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
rOpenSci postdoctoral fellow, Dan Sholler has been researching governance, engagement, and resistance in the open science movement. In this Community Call he will share some of his findings to date.
🎤 Dan Sholler, rOpenSci Postdoctoral Fellow
🕘 Tuesday, December 18, 2018, 10-11AM PST; 7-8PM CET (find your timezone)
☎️ Details for joining the Community Call. Everyone is welcome. No RSVP needed.
Researchers use open source software for the capabilities it provides, such as streamlined data access and analysis and interoperability with other pieces of the scientific computing ecosystem. For most complex software, generating these technical capabilities requires building and governing a community via sound management practices, activities that are often less visible than code contributions and other software development work. And unless the initial developers commit to doing all the needed work for a long time, a community needs to develop to sustain the software, and in many cases, to determine where the software should go. In this call, we’ll pull back the cover on some of the non-technical work that goes into building and sustaining a software project by highlighting the governance challenges projects face and the strategies they use to overcome them.
In this call, we’ll pull back the cover on some of the non-technical work that goes into building and sustaining a software project by highlighting the governance challenges projects face and the strategies they use to overcome them.
In growing and maintaining a project, people such as core contributors/maintainers, leaders, and community managers must develop guidelines for writing and documenting code, implement rules about licensing and distribution, determine methods for evaluating contributions to the project (e.g., onboarding processes), and provide venues for like-minded users to communicate and build working, trust-based relationships (e.g., Slack channels and discussion forums). These management practices sometimes work in a project’s favor by providing clear expectations and helplines for contributors and users; in other cases, they serve as a source of contention because they require researchers to change long-held behaviors due to conflicting definitions of software development best-practices. In this call, we’ll discuss these issues through the lens of governance. If you lead or hope to lead an open source research software project, are in charge of building a community for a project, or just want to know more about how projects are managed, please read on and join us on the call.
Governance refers to the processes involved in developing and enforcing policies and norms for a given community or organization with the aim of structuring some set of activities (in this case, software development and use).
Governance refers to the processes involved in developing and enforcing policies and norms for a given community or organization with the aim of structuring some set of activities (in this case, software development and use). We can, for simplicity’s sake, think of governance strategies as falling on a spectrum from “tight” to “loose.” Tight governance requires members of the organization or community to follow strict rules for carrying out their work, often by formalizing the work in the way of an assembly line. Loose governance encourages members to follow some agreed upon practices in certain aspects of their work and allows flexibility in others. A balance between routinization/standardization and flexibility is key for keeping members engaged and fostering innovation while moving a project in the desired direction (e.g., toward a larger number of users or use cases). Striking such a balance is especially difficult for open source research software projects because contributors and users come from various organizations, disciplines, and backgrounds, where norms of software practice may differ.
A balance between routinization/standardization and flexibility is key for keeping members engaged and fostering innovation while moving a project in the desired direction
So what are some of the different governance strategies used by robust, sustainable open source projects? We’ll discuss some examples in the call, based on qualitative, ethnographic research on several open source projects. Topics will include:
- How a project makes newcomers aware of their expectations and policies
- How a project evaluates potential contributions, reaches decisions about including the contributions in the project’s codebase or repositories, and engages with contributors in discussing such decisions
- What a project does to encourage and reward sound practices and contributions
- What the internal, day-to-day minutiae look like in an open source project, including which management activities tend to be “open” (i.e., visible to the public) and which tend to be “closed” (i.e., held in private meetings or repositories)
Do you have a question or comment about this topic? Add it to the discussion thread. See a question you’d like to have answered? Give it a ❤️. We’re looking forward to a lively discussion on December 18.
Agenda
- Welcome from Stefanie Butland, rOpenSci Community Manager, (5 min)
- Governance strategies for open source research software projects (Dan Sholler, 35 min)
- Q & A (20 min)
Speaker
Dan Sholler is a Postdoctoral Fellow with rOpenSci at UC Berkeley
Dan on Twitter, Dan’s introduction and research plan on the rOpenSci blog
