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:
- monitoring
- 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
- discuss monitoring and maintenance implementation work in advance
- share it, if anyhow possible
- 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.