In attendance: Ben and Leo as hosts, James, Vinay, Katalin, Elvia, Theresia, Matthias, David, Nadia, Noemi, Arthur, who else? Thanks to Ben and Kei who took notes, and may the rest of us fill in the blanks with insights from the session. Log in, then press Edit to make changes/additions to this wiki
The unMonastery-in-a-box is the resource tool for anyone wishing to build further upon our foundations. It contains:
- Methodkit Stack of Cards
- a Wiki that expands upon Cards (and is Capable of being printed with PediaPress]
- The Book of Mistakes
- The Protocol
- 1.0 Tech Stack [Software Installed on Raspberry Pi and OS image on USB]
- a Talking Piece
Bembo disturbed by the “conceptual imbalance” of the cards as the lead image on the website for the box. Original intention in unMonastery to create a replicable kit - based on design patterns from hackerspaces.
Will unMonasteries just happen, will people just pick them up? Original intention may not be true. Then — what is unMonastery in-a-Box for?
MethodKit: checklist for design patterns.
6 components: The last is the protocol — we have never developed this. We needed to develop new knowledge in parallel with the packages (the cards). This happened on the (incomplete) wikis. We have 7 documents on the kitchen.
Question for the session: Is unMonastery in-a-Box useful?
Vinay: If we imagine 5 adopters taking up this kit, these tools, what is their relationship to the originators? They will be looking for a central node to connect to – or at least a larger network.
Ben: Original conception of unMon-box was something like a GitHub repo, forkable, replicable, and in continual development.
A: The unMon is as of yet not fully specified, we can’t fully predict where those fork points will be. Currently missing the META structure / framing how other iterations are folded into the baseline structure - which guides the starting of
Leo: The Community decides what qualifies as a ‘fork’ and/or ‘instance’ - governed by consensus. In software this is easy to understand and recognise because you share a code repository. The community will have to decide what is different or too different.
L: If the tools don’t offer value in their use, then they won’t be used. Redhat trademark is owned by a Corporation - you need permission to call something Redhat but the entire code base is available for anyone to use. Who is the steward of the emblem of unMonastery?
A: It is your place to weigh in on who stewards the unMon emblem – because it is a community emblem, and it is a community decision.
L: unMon corporation would be a betrayal of the principles.
A: That’s not the methodology of enforcement, that’s the intent. There’s a responsibility we have to shoulder in this, it’s on our shoulders what those people do, and if they do harm.
Nadia: The cost of protecting the trademark is prohibitively expensive.
Leo: Open source licences are barely ever enforced, because they represent intent.
L: It’s important to avoid the emergence of cliques. … The beauty of having an emblem and a codebase is that you can do both – allow it to spread and avoid enclosure.
N: There might be situations in which “hyper capitalism is needed”
M: Please ‘fork me’
J: There’s a need for 2 labels, like Redhat and Santos.
Elvia: Can’t anyone decide what they’re 'un’ing.
The discussion then drifted into the question of who would be vested with a vote or be a member? Who makes the choice of how unMonastery would be replicated?
Nadia has a question – who in the unMonastery prototype, and currently working on deploying other ones, was involved in setting up the original one?
B: Isn’t that an act of enclosure?
Leo interrogates the point of the question – it’s very fair to ask what assumptions people’s opinions are based on.
David: I can set up an unMonastery with no experience. Or just an opinion. But the question is, do I set an unMonastery up with my heart, or?
---- digression, Elvia suggests we start with a case study of a request from an unMonastery - what are some examples of requirements and could they be listed on the website? —otherwise, are we on the correct path in this discussion?
B: We asked suggested locations to meet certain criteria - infrastructure, community base, etc. For example we already know we don’t want unMonasteries in big cities, there’s just not the right context. The people in question realised immediately that it is not feasible at the moment.
N: You need a strong community, working unpaid for a quite a long time; if it’s a public sector building, it needs strong ties to the local administration;
E: It seems clear this place [Matera] won’t be replicated exactly, the situation of the local administration giving a building. […] Perhaps there should be a deck of cards for before an unMonastery starts with these concerns?
D: You don’t get the collective wisdom when a conversation constantly points toward enclosure.
B: unMonastery doesn’t have the structure like github where community members can feed in. How do all members - those doing work around unMon - have properly voiced opinions?
Kei’s notes: My personal conclusion from this discussion — how can we communicate with each other in a generative way? What is it that forces discussions into combatative space, is it the fear of having things at stake? Something has been built and now we paradoxically run to enclosure to keep it open.
J: In the spirit of open source, release everything that can be used.
B: I do want to be able to exert some control: I don’t think unMonasteries should be in capital cities, used as development tool for local councils in gentrification.
Time is up. Thanks Bembo.
Noemi’s notes: Although the session started as an overview of unMonastery in a Box as legacy of unMon Matera for future unMonasteries, we seemed to get stuck in the question of what stewarding the uMonastery concept means even before starting an unMonastery (the card deck doesn’t cover the preconditions), and who is entitled to make that decision? Obviously those involved in the Matera prototype feel a responsibility towards future replications. Disagreement or miscommunication occurred potentially because the word trademark was used more than once and some in the room perceived it as enclosure… please correct this wiki if I misunderstood.