This is an exercise we did during our analysis retreat based on the game “Snake Oil” (https://boardgamegeek.com/boardgame/113289/snake-oil) where players have to make up products based on cards they have in their hands. Similarly, we tried to come up with (preliminary) answers to our research questions based on the materials and insights we had generated during the retreat.
Explicit: [skipping for now, don’t have a lot of insight into common types of FOSS legal contracts]
Downstreamers expect infrastructure to “just work” but when upstreamers can’t fix problems they can’t ask for help from downstreamers without violating that expectation. Often, because communication between upstream and downstream has assumed no communication it’s very hard to open lines of communication.
Upstreamers often focus on engineering needs and because it’s a doocracy, they have the implicit authority to determine what gets asked for/worked on. Downstreamers/outsiders may be able to contribute vital non-engineering things but won’t because upstreamers don’t ask them or create space for them to do so.
Some downstreamers expect help and problem-solving from upstreamers beyond what the upstreamers can provide, which leads to anger from downstreamers and guilt from upstreamers. Because of the shared belief that downstreamers don’t owe anything to the project, it’s easy for demands from downstream to overwhelm capacity of upstream to handle them.
Well-maintained projects have: responsive maintainers (meets downstream expectation about getting help); high bus factor (eases impact of upstream expectation that if something goes wrong it’s my responsibility fo fix it); diverse community (avoids downstream expectation that only technical contributions are needed; avoids upstream expectation that maintainers should focus on engineering because a diverse group will have diverse skills to contribute).
In interviews, people talked about not realizing PyPI was having difficulties. PyPI maintainers more or less met the downstream expectation that it “just works”.
Interviewees talked about governance (Nick), project management (Sumana), design (Nicole), and other non-engineering ways of contributing to the project and how that made them more well-maintained and sustainable.
On implicit and explicit contracts/expectations:
On conceptions of well-maintained and sustainable FOSS digital infrastructure:
On how PyPI illustrates those:
1. What explicit/explicit contracts/expectations might there be there around FOSS digital infrastructure?
1a. What might some tensions be among those contracts and expectations?
FOSS digital infrastructure is and will continue to be “FOSS” in both a legal and cultural sense. The cultural sense varies according to whatever an individual’s definition of #whatisfoss. This may include assumptions about what ideal versions of #fossroles, #doocracy, #corpsupport, #corpdirection, #contribtypes, #externalobligations, etc. are in relation to FOSS projects. How important it is for a given project “to be FOSS” depends on both what requirements a person has for something to be a “real FOSS project” (i.e. is it just the licensing? Is it particular governance structures? The presence or absence of specific kinds of corporate relationships?) and the priorization and onerousness of fulfilling those requirements - i.e. these requirements don’t “cost” more to implement than their importance dictates. (For PyPI: Donald seems to have made many decisions because he believes that is the “FOSS way” of doing things. Similarly, Jackie talks about privacy tradeoffs being made because it’s a “FOSS value,” and Nick works within the network of communications and relationships that he sees as part of a “FOSS community.” Terri talks about refusing jobs that don’t fulfill certain kinds of requirements for being “FOSS work friendly” -- whatever people’s conceptions of FOSS are, they can be important enough to prevent folks from making certain decisions or tradeoffs because the FOSS culture of Python’s community, and PyPI by extension, is important to preserve.)
FOSS digital infrastructure, like all infrastructure, will be #magic to users. Specifically, users can #trust that a system will continue to run regardless of whether they pay attention to #linesofcommunication or not; #communitymanagement is an opt-in activity from the point of view of users. (For PyPI: Even highly-informed users didn’t think about PyPI sustainability - that knowledge didn’t activate because they assumed it would be taken care of.)
#Corpdirection and #financialinfrastructure can only accelerate or maintain FOSS digital infrastructure in a “community driven” direction it was already going in; it should not change that direction. (For PyPI: Discussions about hiring and funding.)
Users can be exempt from #communitymanagement outreach via #linesofcommunication for FOSS digital infrastructure. (For PyPI: Challenges maintainers had in getting in contact with users.)
Maintainers of FOSS digital infrastructure are beholden to even informal #contracts of expectations unless they are in dire danger of #burnout, regardless of #externalobligations or #emotions to the contrary. Maintainers are expected to have #motivation to do this sort of labor, because their #selfdirected decisions got them there in the first place. (For PyPI: Donald’s stories about burnout in particular.)
From a user point of view, FOSS digital infrastructure projects are already paying attention to their #busfactor and #tooling and #burnout - there is no need for users to attend to these things.
Broadly speaking, users are not responsible for the sustainability of FOSS digital infrastructure; contributing in any way is a nice bonus, but not an expected civic duty.
(I feel like I’ve written my responses above in ways that make possible tensions clear - imagine the opposite, and see how it is also pretty reasonable.)
2. What are various conceptions people might hold regarding what constitutes a well-maintained and sustainable FOSS digital infrastructure project?
See https://github.com/FOSSRIT/mismatches/blob/master/notes-2019-10-11.md, where I synthesized what participants said about this (I haven’t yet thought about how items on that list might be reverse-engineered from expectations/social contracts, though.)
3. How does PyPI illustrate the above things, and how does it fit into the larger context of other FOSS digital infrastructure projects with respect to doing so?
See the parenthetical statements at the ends of my responses for item 1 here.
#speedexpectations, #communitymanagement,#linesofcommunications,#trust,#fossroles,#contribtypes, #tooling
In infrastructure there’s an expectation of rapid turnaround of issues and little or no downtime. Within a theoretical well-managed community this is facilitated by clearly defined roles, contribution/contributor type, trust and clear lines of communication. A less well managed community might result in things falling to a small group or a single point of failure #busfactor #authority #do-ocracy. Depending on the project good tooling and piplines may be able to be developed to support this. Corporate support of an unrestricted gift can be usefull here, whether that gift is of an internal employees time or cash to an external foundation to support sustainability
How much of the mainteneance and upgrading is organic/structured, do the contributions and the contributors end up bing long term /short term, how much of the transparencyinherent in the community becomes an obligation to stay on top of things and how does it end up as a do-ocracy vs. and inclusive community of contributors?
What are a conceptions of a well maintained and sustainable FOSS program.
See #1 really.
How do the narratives collected aroundPyPI illustrate this?
The shows an effort to move from one that was initially not well maintained and sustainable to one that is moving closer to meeting the conceptions and expectations of a well maintained and sustainable project, due, in part to some forms of #corpsupport.
Engineering culture bias: if you’re a good engineer, you can fix it yourself without help - and thus do not need personal connections (“they’re for wimps.”) The #doocracy nature of FOSS culture allows this to be perpetuated.
In FOSS (and engineering) culture, #trust is given to things and/or to other engineers, not to nontechnical contributors. Personal connections are framed as a vulnerability; #trust in individuals is framed as a vulnerability (that’s the entire idea behind #busfactor).