Skip to content

Latest commit

 

History

History
46 lines (29 loc) · 5.83 KB

notes-2019-11-10.md

File metadata and controls

46 lines (29 loc) · 5.83 KB
Raw

software attempts to encapsulate information and make it so people don't have to think about x or y or z. software that people have expectations about become infrastructure. so software infrastructure is encapsulated information or services that people don't have to think about.

it is the combination of EXPECTATION and ENCAPSULATION that are in tension because when expectations are violated people are encapsulated from learning about and fixing the problem. it's not a problem that expectations are violated necessarily but that they happen in a way where there's not support for fixing the violation.

FOSS is especially prone to problems because:

  • no contracts, even usually informal ones, that explicate what to do when expectations are violated; no particularly clear expectations in the first place

  • more generally, FOSS is not a diverse group and a more diverse group will have more diverse expectations, uncovering "mismatched" expectations earlier on in the process

  • without contracts or clear expectations, one of the first manifestations of violated expectations is negative emotions which FOSS is especially culturally predisposed to have a hard time to handle

  • additionally, FOSS selects for people who take infrastructure for granted, we're used to having our expectations met and are therefore not great at thinking intentionally about how to address violations of expectations. and this taking of infrastructure for granted can make it harder to attract people who do know/care about infrastructure.

Revisiting early analysis about FOSS vs non-FOSS infrastruture

Infrastructure is “magical plumbing.” FOSS infrastructure lets you look behind the curtain if you so choose; non-FOSS infrastructure likely does not.

  • "Looking behind the curtain" is one mechanism that FOSS culture has for creating verification-based #trust; even if you (individual reader) are unable to verify it, some theoretical person could, and no gatekeeping mechanism would block them from doing so.
  • For infrastructure, some things have heavier curtains than others; the code (features) may be viewable, whereas system configurations may not be. #tooling
  • Sometimes, when everyone can do something, nobody does something, because "oh, I'm sure someone has taken care of it." #fossroles
  • Infrastructure is relied upon by a community. There are necessarily questions of authority about how to manage it. FOSS communities avoid thinking about authority and therefore struggle to manage infrastructure. #conflictaversion is a tension, especially in relation to potentially permanent authority.

Infrastructure requires technical effort for operations (as well as development). FOSS infrastructure may begin as a pet project and then “accidentally” go into production; non-FOSS infrastructure is more likely to be deliberately planned as a product launch.

  • This is not unique to FOSS (when FOSS is defined in terms of licensing); it may be more common with FOSS projects (because of cultural tendencies). Corporate project equivalents are "the demo that becomes a product."
  • Corporate structures might have more blockers that prevent this dynamic from going quite as far.
  • Discomfort with this statement: there's frequently an unofficial "shadow IT" inside an institution.
  • While this may not be a strict FOSS vs. non-FOSS difference, this is a thing that FOSS projects have to contend with.

Infrastructure requires development capacity (people-time). FOSS infrastructure is likely to have some or all of this development capacity come from self-directed volunteers, but that effort is also more likely to fade out during the “last mile.” Non-FOSS infrastructure is more likely to have its development resources known, managed, and allocated in advance.

  • The #selfdirected nature of FOSS culture influences this heavily.
  • Infrastructure implies permanence and sustained commitment. Grants and other resourcing mechanisms that are project-based are necessarily limited in time.
  • Most resources (financial or otherwise) are directed towards product, not maintenance. There is a parallel issue in academic research projects, and some of this has been addressed by a "tradition" of grants budgeting money to contribute towards maintenance of infrastructure they depend on. Some of this empathy may come from those researchers running infrastructure projects of their own - i.e. "I don't know what's under that hood, but I have hoods like that myself, so I will contribute what I want others to contribute to me."

Infrastructure requires bureaucratic/organizational work. FOSS infrastructure is likely to have this set up late, during the “last mile” or the “sticking point.” Non-FOSS infrastructure is more likely to have this infrastructure (legal, organizational, financial, managerial, marketing, etc.) be set up early.

  • Is this really a re-statement of the second item? (No, the second item is about product progress.)
  • Maybe not "set up early," but "be more ready to go when needed" because organizations tend to have money and other resources of this sort for things already.
  • By "FOSS" and "non-FOSS" here, we probably mean "organizationally driven" vs. not. In general, this list started as a FOSS/non-FOSS distinction, but each item means different things by that, so we should probably reword it to reflect that.

Infrastructure user data and usage patterns are important for determining future resource needs. FOSS infrastructure maintainers are less likely than non-FOSS infrastructure ones to have complete and reliable access to that data because of intentional cultural choices to prioritize user freedom and access over it.

  • This was the first #tension spotted, not necessarily the most important one.
  • Is there an implicit norm being imposed here saying that users of infrastructure should not want personal relationships with regards to it? (And how do convenings go against that "norm"?)