Succession Plans & Mycelium Life Cycles
This section is still a work in progress.
While self-hosting has many technical challenges, in some ways the technical challenge of getting things running is just half of the story.
Backup plans and succession plans are two important aspects of resilient infrastructure that are often overlooked in self-hosting, if you want to offer a service with more than zero reliability guarantees. Zero reliability guarantees can also be fine for things where its communicated that "it is there as long as its there and that's it" — but if someone is depending on something, that's often not sufficient. It's good to be clear about this.
For example, with this wiki, I've put a lot of work into daily automated encrypted backups, because I and others are putting a lot of work into content in this wiki, and if the computer it was running on unexpectedly crashed, losing this work would be a huge pain.
However, I'm actually not currently totally happy with the succession plan for this wiki and the class materials. If SFPC had a community infrastructure working group, or a tech coop they worked with, that might be a more reliable option, but as it stands, there isn't currently an enduring group of people with an interest in maintaining the infrastructure the class depends on or for archiving the class materials.
A "succession plan" is the plan for what happens when the maintainer(s) of a piece of a software become unavailable to continue maintaining it — because of injury, emergency, illness, death, a change of life circumstances, or a change of priorities.
A short tangent: for open source software, succession plans are also a potential computer security threat vector — there have been cases where a piece of previously trusted open source software has been handed over to a new maintainer who introduces malware into the code. How software dependencies are to be trusted is an open question, with many different approaches (rabbit hole: https://socket.dev/).
Currently this wiki has no clear succession plan, and if I dropped dead tomorrow, it would probably continue to run for a few months, and then at some point, domain names would expire, the server would crash, or something else would happen which would make the information inaccessible.
Its one of my goals to get more clarity about the succession plan during this season of the class, and I'm open to ideas from students.
I currently have two main ideas:
- Spore/Mycelium Succession Plan
Most living organisms have multiple phases of their life cycle, that are suited to different seasons and periods. For example the way deciduous trees lose their leaves in the winter, and re-grow in the spring. Many mushrooms have even more complicated life cycles that involve multiple different stages, that don't even necessarily happen in the same repeating order (one of their many forms of queerness).
With this as inspiration, the idea behind the Spore/Mycelium Success Plan, is to think of the class infrastructure in terms of life cycle phases. During the active period of a class time, a server comes online which hosts the class materials (Outline, Nextcloud). During the dormant period of class, the services are taken offline, and stored into easier-to-archive static forms, such as PDFs and HTML. In this vein, I've worked on a script which converts an export from Outline, into a static HTML artifact, using a tool called mdbook. This is still a work in progress, and requires some manual steps, but it was how this mdbook was generated.
To further increase the resilience and clarity of this succession plan, I would like to document what the different life cycle phases are, and see if there are volunteers who would like to steward redundant copies of the static artifacts. A balance needs to be found here, to source additional help, but not be unrealistic about the levels of maintenance or stewardship that would burden people. For example, automated systems could be made that distribute backups from the class server, to backup stewards, who then learn how to re-activate the backup into a "living organism" if they need to. More clarity and discussion is needed here.
- SFPC Community Infra Working Group
If SFPC had a community infra working group, this would be a natural group to keep track of class documents and archives, that would be more resilient than the maintenance capacities of individual teachers. Alternatively, a "Solidarity Infrastructures Community Infra Working Group" which is specific to Solidarity Infrastructures, but not general to SFPC, could also be possible, but I think we also need to be realistic about the capacities and commitments of different participants of the class. For most people, a class is a temporary thing, and not something they want to have an active long-lasting stewardship relationship with — this is totally fine — but to come up with a real plan for resilience, we need to be realistic about people's actual capacities and stake in the project. More clarity and discussion is also needed here. Maybe SFPC would be open to a proposal for a community infra working group, or something like that, at some point.