unMon in-a-box / IT Infrastructure

Workspaces unMonastery
, ,
1

Okay I’m posting this here as a stub, taken from a document that @Marc sent me yesterday. Made some decent headway conceptually for unMonastery in-a-box in the past week, when there’s a moment I’ll post up an overview and time/date for the first remote working group. Also would like to do a hackathon at the end of June to put this all together.

unMonastery IT infrastructure

All unMonastery units

Equipment

• Remote server

• Host all unMonastery projects

• Host main unMonastery website and websites of each unMonastery units

• Act as a VPN for unMonastery units

Software

• Project management software like Redmine (wiki, tracker, integration with

VCS…)

• Software to manage the websites

unMonastery unit

This is part of “unMonastery in a box”

Equipment

• Media center

• Raspberry Pi or equivalent

• Video projector

• Sound system

• Open Energy Monitor

• Raspberry Pi

• Power consumption module

• Temperature / humidity module

• External USB hard drive to log data

• Internal low power consumption server to host internal software

• External hard drive

• To store media (videos, music) : used by the media center

• To make backups (for example of the internal server data)

• VPN access point : can be either a router or we could configure the Raspberry

Media center to act as an access point

Software

• “Customized version” of an ERP -Enterprise Resource Planning- (like

OpenERP) to :

• Manage all common contacts

• Manage invoices / accounting

• Have a shared calendar

• …

• Internal mailing-list (like mailman)

• Wiki (like Dokuwiki) : to store all the internal documentation (how to use

equipments of the building, manuals,…)

• Software to manage accounts and passwords of equipments, software or

online services

1 Like
2

Librarybox

Not sure it’s helpful / what you have in mind, but you might also be interested to take a look at: http://jasongriffey.net/librarybox/

3

This is an art

I think this is a really important project, as someone who has been involved in lots of community projects that had really unpleasant and proprietary internal comm systems. It’s a great adventure! A few resources that might be helpful:

ownCloud. A super scalable and adaptable libre cloud system that can be self-hosted. It keeps getting better and better. I’ve found the document storage (i.e. Dropbox) to be fairly functional, the calendar to be excellent (synched with Thunderbird), and the contacts to be fine, though the Thunderbird side of the interface is screwy. There are lots of other features, including a rudimentary replacement for Google Docs and more. But this is a very worthwhile project to work with and contribute to, as it could be very powerful in enabling communities to detach themselves from evil Goog dependency.

Occupy. During its various iterations the Occupy movement developed some interesting tools to manage collaborations across the movement. It could provide something of a model. Here are some examples:

  • BuddyPress is a sophisticated social network plugin for WordPress that was often used for the internal websites for various occupations. Here's the one for the ill-fated New York General Assembly. For a while it functioned very, very well as a way of keeping track of events, working groups, and discussion about proposals in the assemblies. It was eventually overrun with trolls, but there are probably ways of dealing with that via moderation of a kind that wasn't possible for a movement that was, at the time, at the center of world media attention while trying to remain open.
  • The Occupy Network was a later attempt to create an Occupy-in-a-box framework full of libre tools. It kind of ran aground, but the idea was great: a suite of stuff like Etherpad, classifieds, a directory, forums, wiki, etc.
  • InterOccupy started as a really well-moderated conference calling network and then developed into a more extensive set of services. You can fill out a form to set up a "hub," which means being listed in their directory and calendar. I think it used to also get you a GNU mailing list and other open tools maintained by fairly competent folks. It was the network created by these folks that became the basis of the hugely successful Occupy Sandy relief effort.

Riseup. This is a suite of tools that are useful to lots of activists in the US, maintained by supposedly competent folks. For users who agree to a statement of principles (which is as specific as not privileging class politics above identity politics), they offer stuff like Tor, Email, Mailing Lists, VPN, chat, and etherpad.

Vanilla. These forums simple and wonderful. An old idea that keeps being great.

There’s so much more. Maybe every unMonastery should have its own unCurrency. The challenge, I think, is to figure out how to have everything you need and absolutely nothing else, so it doesn’t overwhelm the folks who don’t like to deal with lots of do-dads like some of us do. In one collective I’m part of, I made the very luddite team very happy (and ended internal emails almost for good) with just a simple HTML page with a Vanilla forum and plain text and chat via etherpad side by side. This is an art.

1 Like
4

The Artefact Fallacy

Guys, let me say this bluntly: you run the risk of crashing into what I have decided to call the Artefact Fallacy.

It works like this:

  1. All social systems have a "human" part (tacit knowledge, orientation, values of the people manning them) and a technology part (you seem to be very clear on this, no need for me to delve on it).  In online social systems the two parts are particularly easy to distinguish. A fancy and formally precise way of saying this is that they exist in agent-artefact space.
  2. They need to be designed (or evolved, if you, like me, take a complex systems perspective) very interdependently from each other. 

Almost no one disagrees with the above. But in practice almost everyone ends up focusing on the technology part and ignoring the social part, hence falling prey to the Artefact Fallacy. The result is fundamentally crippled systems, that can’t help living in agent-artefact space but, having been designed as “empty” technologies with some idealized user  in mind, don’t work. Hence: lots of empty platforms.

At the risk of bringing back painful memories, the unMonastery founders ran into the Artefact Fallacy once already (I write this for @nathanairplane who did not participate in that discussion). unMonasterians elected to build their own tech stack over using this platform, mostly on user experience considerations. I pointed out that a larger and more vibrant community with worse (but improvable) software was likely a better situation than fragmented subcommunities on better (largely NOT improvable) software. We ended up having a passionate conversation with sleepless nights (in the comments) – which, of course, solved nothing.

This was OK, though. There was no need to solve anything, because in due time the problem solved itself. The Edgeryders platform got better. The unMonastery website, as I write this, seems not to be updated all that often: maintaining tech, even at the level of updating the content, is hard. The last news on the unMon website dates April 4th, 42 days ago; meanwhile, Edgeryders collected on average 20 comments a day. This platform, for all its shortcomings, has emerged as an essential way for unMonasterians in Matera can stay close to the Edgeryders community, recruit new people, build alliances. This is not because of anything magic in Drupal Commons, but because this particular instance of Drupal Commons as customized by @Matthias and all of us lives in symbiosis with enough smart and dedicated people to make it worth it to hang on to.

The Artefact Fallacy does not kill the unMonastery-in-a-box project, but it does constrain it. For example, moving from Drupal to BuddyPress (very similar functionalities, if memory serves) would be a spectacularly bad idea from a social standpoint. Taking the Artefact Fallacy seriously means that it makes way more sense to replicate on Edgeryders whatever it is that people like about BuddyPress, so that the community can be kept together and disrupted as little as possible. And taking it really seriously means that even introducing new functionalities should only happen after making sure that there is a dedicated group of early adopters.

5

Technical Point.

Just wanted to flag that this post was intended to be accompanied by another, which is slightly more demanding cognitively (and which I haven’t had time to write yet) - this one is unMon in-a-box / IT Infrastructure - the next will be unMon in-a-box / Human Infrastructure. In many ways the tech part is the easiest (and is more about operational effectiveness on the ground and less about approaching the requirements of replication). At this point we have much of the raw data needed for the replication of unMonastery - what we don’t have is the entry point, the top level access point, or a means of organising and rationalising the data.

What I’ve been veering towards in thinking and conversation with @Ola is a methodkit iteration for unMonastery, cards that signal the baseline requirements of an unMonastery, with a corresponding wiki that uses the same taxonomy, so that anyone can take the pack of cards plan their model and easily reference the history and patterns of what’s gone before. Simple and friendly, with an online hub

One thing in respect to this that I’ve been meaning to ask @Matthias;  is that the wiki set up on EdgeRyders isn’t adequate for this - I wondered if you/anyone was aware of a drupal plugin of some kind that’s more akin to docuwiki or mediawiki. I have some funding from a fellowship that I’m currently participating in that could go towards getting something built for this purpose, if needed and given how much wikis have begun to be used on ER, it makes sense to me that we improve that side of the platform.

6

A lot of misunderstanding…

We didn’t work on ‘community platform’ but on a decoupled frontend backend with intention to create reference variant of clear presentation for data coming from trello, google drive, vimeo, blog, edgeryders group etc. By keeping it all decoupled everyone can have more flexibility with using different tools as well as creating different frontends mashing all this data together. At some point everyone should have freedom to choose one favorite tool to work with and preferred interface to interact with it (just as one can send emails using thunderbird, mutt, gmail, mailpile etc. while others can read it with their favorite mobile, desktop, CLI apps)

Edgeryders platform has monolithic and highly coupled architecture, even that Drupal already has certain capacities to make it bit more flexible and aggregate feeds from other services. It also has different focus and set of priorities!

I got side tracked with various things once we got the first version online, in next two weeks I would like to start plugging in data from trello, vimeo and google drive to get start with. Mostly feeds of activities so people and projects can show on their profiles what happens in all those online spaces relevant to them.

I would suggest everyone working on online spaces - dataspaces + interfaces (plural!) to interact with them - to keep this video in mind

please also check out slides we’ve made together with @alexwhitcroft

i hope we’ll manage to have chance to hack some code to run it in next weeks, maybe even in unMonatery:Matera :slight_smile:

1 Like
7

But Elf…

Is it not the case that Alberto has a very good point – and that we traded one endless frustration of an introverted ER site that could never provide ready access for the unMo MAT perceived user, for another that was so intricately balanced as to deny access to even sophisticated users —  to end up on (or halfway on) FaceBook for our community interfac and on ER for internal /broader community commentary ?

The attempt to start from scratch has not only not provided for its intended functions, but it has drained many people’s attention during key weeks.  According to at least one of the house brothers we would have been better off using a tried and tested open source solution that could have been up and running in two days.

This is classic Book of Errors material – but even more important the need for a solution is still intense…