This page is to explain the issues that arise around dependencies on resources run/maintained by others, and to propose solutions.

problem detection through practice

SocialTools development/testing server Valter was offline for a month. We used it rarely lately, and forgot to check on it for a while. Valter and newt (shared server which hosts open-org website) are both hosted at our friends office. One weekend all servers became unavailable. Friends were out of town for the weekend, and we couldn't find out what's going on. Over a year ago, same friends were using another office, for which we had the keys, and which we used to visit from time to time. This time, nor we visited office, nor we had keys to access it. Their office and internet connectivity are resources we, our servers, use i.e. they are shared. Still, we let this dependecy slip, from our side, into totally passive one. Whether is it the case in general, that when one does no implementation work on some shared resource one's relationship to it by default slips into passivity, or it happened to us for other reasons, is less relevant. Is stands that it did happen and that we ought to do something to prevent it from happening again in future.

generic problem description

Often, as part of sharing of the scarce resources, there are relationships of dependency with others (organizations, groups/collectives, individuals) which after the initial agreement, when not dealt with on regular basis, can become passive. If that is the case, such default passive state is most likely to be the result of all implementation work (including regular maintenance tasks that shared resource requires) being carried out by one side.

The premise we start from is:

   ALL RESOURCES REQUIRE CONTINUOUS IMPLEMENTATION WORK
   at least in the form of maintenance and monitoring.

Although such work can not be always shared due to unsolvable obstacles (geographical distance, for example), side which does no implementation work in a shared resource should not count on such imbalance to be continuos by default.

implementation tasks and examples

Minimal implementation tasks are:

1. monitoring
2. maintenance (regular + reacting on monitoring data)

To simplify examples, we will call the side the runs/maintaines a resource X and one that shares its use Y.

Physical space (rent or ownerhsip of room/house)

Tasks that X has to regularly carry out:

• pay utility and rent (when not owned) bills
• maintain it by doing it, or, when specialist is needed (plumber,electrician), organize it and pay for it
• often, organize some form of schedule for use of the space

Computer servers hosting

Subset of previous example, since it involves physical space in which computer servers are kept. Additional tasks that X has to regularly carry out:

• pay bills and monitor and maintain contract for internet connectivity
• monitor and maintain local network on which servers are hosted, with many subtasks

proposed solution

1. discuss monitoring and maintenance implementation work in advance
2. share it, if anyhow possible
3. discuss it (re-negotiate implementation work split) on some, agreed, regular basis

By communicating on regular basis (depending on the kind of resource shared and work involved) with the side that does all the implementation work, an opportunity is presented to both re-negotiate the relationship and find out about possible changes of anything concerning the monitoring and maintaineance of the resource. In order to make early detection of possible problems more likely to happen, described communication should be a regular process.