Decisions and diversity

Matthew Arnison - Sydney Indymedia volunteer

Version 0.2 June 2001

http://www.cat.org.au/maffew/decisions.html
maffew@cat.org.au

Abstract:

A rant about how to collaborate as a network of autonomous and diverse local
indymedia collectives. I go through various parts of the project and try and
identify how we might work together and make decisions.

Indymedia has always had a global consciousness. Yet the first Indymedia Centres
were in specific places: Seattle and Washington DC. As the number of centres
grows, we need to figure out how best to collaborate - to use our collective
strength while encouraging local diversity.

The first step in a healthy collaboration is to work on a project together.
There's been plenty of that going on since the beginning within the indymedia
network. One of the joys of Seattle was a glorious collaboration between media
producers on the ground; and between geeks in cyberspace.

Part of working together involves making decisions together. This works well
if the decisions are made within the working group on issues to do with their
specific project.

The next logical step is to share resources between groups. This is where the
decisions get more complicated. Who makes the decisions, and how?

I think a good place to start is to identify the different sorts of issues that
affect the network, and then figure out how best to organise so that decision
making is practical and fair.

an energetic group of people to co-ordinate the project
within their city, including story production, editorial, design, publicity,
technical, funding

standards:

a set of definitions of what indymedia means to the network, e.g.
open publishing, sharing of stories

*.indymedia.org:

a web address ending in indymedia.org

cities.inc:

an entry in the list of indymedia centre links on all existing
IMCs

mailing lists:

where a lot of discussion and organising takes place. Having
our own mailing lists mean that we are free from ads.

web server:

space on an internet server to host their city

software:

automation so that users can read and contribute stories

loudeye.com:

a password to access the streaming media server. When multimedia
stories are published, the web software uses the loudeye password to copy the
multimedia file to loudeye so that it is available for viewing (streaming or
sometimes download).

training:

the skills to setup an indymedia and maintain it

workers:

almost all indymedia workers are volunteers, but there are examples
of paid workers

funding:

money to support media production, publicity, and other local activities;
preferably some money to send to support other parts of the network

www.indymedia.org:

the global front page for the indymedia network. Aims to
highlight stories from local indymedia sites (using the centre features column)
and also carries a thriving newswire for stories that posters consider of global
relevance, or for places which have no local or regional indymedia centre.

Some of the decisions in these different areas should be made locally, some
could be made regionally, and some have to be made across the network.

Fair global decisions are slow and take a lot of work to organise. If they are
taken too far I feel they will lead to suppression of diversity and grim power
struggles. After all, the global corporate and government monopolies on power
and culture are at the heart of the globalisation debate that indymedia thrives
on. Let's make global decisions only if and when we really need to. That way,
hopefully, our global decisions will be truly inspiring ones that help keep
us together.

I think a crucial technique for supporting diversity is to decentralise, and
to keep decision making as local as possible. So far indymedia is largely in
English and in cultures with strong European origins. Diversity is going to
be an even bigger issue if indymedia finds itself useful in cultures with Asian
or African roots.

I think it's important that the people working on a project have a say in decisions
about that project. Keeping decision making local, or within specific projects,
helps a lot with that.

I also think it's important to think about how we collaborate within regions
or between regions.

Mutual aid is an important idea here: as I understand it that means ensuring
both sides gain something from an exchange, and that the motivation is working
together to solve a common problem.

I think it's quite possible for a strong group in one region to offer support
to groups in other regions, without necessarily involving the whole network.

Because the support being offered depends on the resources of the group offering
it, that group should have the ultimate say in decisions about resources they
are sharing. This still leaves room for the groups receiving those resources
to be closely involved in decision making, as well as to share some of their
resources in return.

Some resources simply have to managed across a network, for technical reasons.
And some decisions only make sense for a network as a whole.

Obviously most decisions about each IMC are made in the local collective. This
includes decisions to offer their resources or to otherwise collaborate with
other groups and projects; proposals and responses to network issues (below);
editorial decisions for the local site; approaches to publicity and local decision
making, etc.

Many indymedia stories are produced by media collectives who work independently
of indymedia and then contribute their story to an indymedia website. Bringing
diverse stories together in one place is a strength of indymedia, and local
indymedia centres often play a crucial role in creating and maintaining links
with local media collectives.

These are an attempt to document what being a member of the indymedia network
means. So all members of the network need to be able to participate in developing
and agreeing to standards. However, it is possible that sub-networks might form
which agree to certain standards that other parts of the network do not. Some
standards might be political, and some might be technical. E.g. for sharing
stories between sites (syndication) there could be a political standard describing
copyright and licensing options (copyleft, free for non-profit reuse, a possible
new indymedia license), and a technical standard describing the mechanics of
how the web servers exchange stories (such as RSS over http for those who know
what that means).

Technically these are controlled in a single place. It is a minor (although
skilled) technical job to add or modify cities in these lists. Each city creates
a relatively minor drain on time and resources, after initial setup. Most of
the decision is political: is the new member really an indymedia collective?
Do we want o give them our name and link to them from our front page? And as
long as we stay a global network, these questions should be decided globally.

An important alternative is to consider creating regional or other networks
within indymedia. Each would then be in control of their own web addresses and
city links. And they would presumably link to other networks within indymedia
that they supported. This removes the need to centralise decision making on
the web address and cities list, and has been happening already to a certain
extent with *.indymedia.org.au (Australian indymedia) and some IMCs have an
independent cities link list. And some mailing lists are hosted on different
servers, e.g. imc-sydney@cat.org.au, webcoders@cat.org.au

This is an important and valuable resource that every indymedia centre uses.
There is relatively little technical or political work to maintain it, because
it is being donated, and it is very reliable (almost all of the problems we
have are with the software running on indymedia web servers) and can carry a
lot of cities. So deciding to give access to loudeye seems to be a global political
decision at the moment.

However it is possible that we might setup additional streaming media servers.
Although it would be substantial technical work, it would be good insurance
against losing loudeye.com, and having multimedia servers in different regions
would help people in those regions to view our stories. It could then be up
to the people working on those servers to determine if and how to share their
resources and associated decision making.

I think this is a natural place to work on decentralisation. It makes sense
to have several cities sharing the same web server, because there is some technical
overhead in running one at all. And some cities would like to start without
first gaining the skills needed to setup their own web server. So if an existing
web server can take on extra cities, that's a very useful thing.

But each additional city is a substantial technical load. So it seems fair that
the people doing that technical work should get some credit for what they do,
and should have some say in the decision making about which cities to offer
the resource to. Adding new cities to a server does create room for things to
become more efficient by automating the management. And it does allow for pooling
of available technical volunteers and other resources. However, it is not clear
that continuing to add new cities will always lead to an overall increase in
the capabilities of that team. There are certain tasks that take an amount of
time per city hosted, e.g. technical assistance for editorial and design volunteers.
The strain of putting too many cities on a particular server could lead to other
things that we want to avoid. The need to increase efficiency could start to
erode the autonomy of each city. The technical volunteers could start to burn
out with unreasonable amounts of responsibility. Communication within a large
technical team could break down, affecting its ability to introduce new volunteers
and to share skills. To avoid such cases it makes sense to me to encourage the
creation of new web server collectives.

So hopefully each collective can achieve a balance. Big enough to have critical
mass. Enough growth and change to keep things fresh. But not so big and not
changing so fast that it starts to cave in.

We currently have at least 6 web servers running indymedia sites, but most of
the cities are on a single server, which is based in Seattle USA, and is called
"stallman". Stallman also hosts www.indymedia.org. It has
inherited these roles from earlier servers based in Boulder, Colorado (USA)
and Boston (USA), although for a time during the Seattle WTO actions, the server
was actually in the Seattle Indymedia Centre itself.

Because so may cities are on the one server, and because we talk about it as
the "global" server, I think that is creating a false sense
that centralisation is natural.

While a web server may have a global audience, and a global technical crew,
there are substantial parts of running a server that are very much local. I
know this from a community internet server I volunteer with in Sydney (www.cat.org.au)
but Seattle is also a good example.

In my experience a community internet server has a small core of people
who take a lot of responsibility, and a wider group of people who help out occasionally.
The core group is likely to be local because it makes it easier to communicate,
and because certain vital technical jobs such as replacing disk drives, recovering
from crashes, and certain system upgrades have to be done locally. Local negotiation
also helps with getting a good internet link. And some money is needed, which
is generally easier if it stays within the country.

Some important web server decisions need to be made urgently. For example, how
to respond to censorship attempts by government or corporations - such as a
court order for the list of visitors and contributors to sites on a web server
(this is also an example of the effect of local laws on a web server). Or what
to do in the case of a possible break in attempt, or where a technical volunteer
appears to be dangerously untrustworthy. Such important decisions are fastest
in smaller groups who work closely together and have established trust.

stallman: a case study

The largest indymedia web server has been locally grounded since it began. However,
the local group responsible has switched three times.

When it was in Boulder, there were key technical people in Boulder looking after
it.

Then it moved to a server looked after by people in Boston (even though the
server was physically somewhere else in the USA - using something called "managed
hosting" where you pay extra money for a company to do tasks like replacing
hard disks for you).

The Boston technical people moved onto other things and now those indymedia
web sites are hosted on stallman, after some people based in Seattle consulted
with the network, proposed and spent some money from a network technical fund,
and then did a lot of work setting stallman up. It is now managed by an international
collective, but Seattle volunteers play key roles.

If there were no American indymedia centres, and especially if there were no
American technical volunteers, it would be much more difficult to have a large
indymedia server in the USA. This is a crucial test - a resource cannot be
truly global if its existence depends so heavily on volunteers from a particular
place.

Indymedia volunteers should be able to work on whichever part of the project
they want to. As long as they can find affinity and trust. So if a volunteer
is from a city that is hosted on another city or region's server, that volunteer
should be able to get involved in all levels of software or web server system
administration (except of course things like disk replacement that depend on
where the server is based). Most stallman volunteers are there because their
city is hosted on stallman.

Of course, trust needs to be developed before a volunteer would be given full
access, but there should be a process by which they can gain that trust. As
well as good communication methods and opportunities for training, so that opportunities
are open for the technically interested, as well as the technically skilled.

So it is very much possible for a local group to share its resources and associated
decision making with projects in the wider region or across the world. And that
has been one of the big success stories of indymedia.

But we need to be careful not to create unreasonable pressure on a particular
project to provide more resources than they are able to. And we need to keep
space open for new projects to form and offer their resources to groups within
the network. Some web servers, of course, will stay dedicated to their city
only, and they should not be criticised, because it is their choice. And some
will choose to open up to others, and that is an exciting thing and we have
figured out a lot of stuff about how to do that.

So I would suggest that we clearly identify the group of people working on a
server, and encourage their autonomy in sharing their resources and decision
making with other groups in their region or around the globe. This means instead
of calling stallman the global server, we think of it as an important server
based in Seattle that hosts a lot of American and global indymedia sites.

When an indymedia centre starts up, they can ask around for a web server that
is willing to host them, or choose to setup their own server.

This then removes the need for the network to make global decisions about stallman,
or any web server.

The software running nearly all indymedia sites is free software, usually a
particular package called "active" which originated in Sydney.
Because it is free software, skilled people can copy it and set it up on different
web servers, change it, and redistribute it (as long as they keep the condition
of it being free). The internet means that making a copies of free software
is very cheap. Programming collectives can naturally grow internationally; this
is a strong factor in the rapid growth and success of GNU/Linux and other free
software. People with programming skills are likely to be able to adapt more
quickly to collaborating together using online technology.

An important example, is how active has been translated into at least a dozen
languages, despite the original authors knowing only English.

Another example is the second installation of the active calendar, in Melbourne,
Australia. It was copied, setup and installed without any help or even awareness
of the original writers of active. This shows clearly how the sharing of software
does not need to take any energy or resources from the programming team.

Each city can choose which software they want to run. Each software programming
volunteer can choose which software project to work on. Cities can also make
requests to add features or fix bugs, which the software programming collectives
usually feel it is part of their goals to cater to. Skilled people can also
study the design of existing software and decide to start from scratch, as several
cities have done.

Programming collectives which are unresponsive to their users are likely to
find another software project that does listen will become more popular and
be chosen by more cities.

Each additional city using a particular set of software is an overall boost
to that software project. The increase in the number of users provides important
feedback and energy to continue to improve the software. And within the audience
of each site is a pool of potential new programming volunteers. This is a key
difference between a web server project and a software programming project.
Each new city on a web server takes additional resources and energy from the
team. Whereas each new city using a software package is a boost to that project.

There is plenty room for healthy autonomy and collaboration in the software.
Note, however, that this autonomy depends on the use of free software, and that
the software projects and the indymedia network never assumes that a single
software package should be used by all cities.

What might be shared between cities is a set of standards. Such standards might
specify the most important features of open publishing, or how to exchange story
headlines between cities. Those standards are evolved from running code and
distilled into something that is agreed to by the network. There is a great
history to this approach. It is how the internet itself has been built. On the
internet, the standards are mostly technical, and are called Request for Comments
(RFCs). The first one was written overnight in a bathroom.

There are a lot of skills involved in doing indymedia. So training is a very
important part of being accessible and bringing in new volunteers. Training
is much better face to face, so it is best done locally, or sometimes regionally.

Some methods might be written up, and thereby useful to people across the network
who are fluent in that language. Translations can be made. The text can be changed
to adapt to local cultural conditions. Sharing such ideas is a very important
part of how we collaborate. The documentation (the "blueprints")
about the indymedia centres in Seattle and DC were crucial in helping so many
new centres start so quickly in the 15 months since DC.

A lot of brainstorming and discussion happens globally online. This is great,
but it's most useful when it's tied to a specific project with a focused working
group.

I think we are far from consensus that we want to start paying people to work
on indymedia network projects. Some indymedia centres seem keen to stay 100%
volunteer. And other indymedia centres have already paid people to do things
in their local work. I suggest the decision on whether to employ people, or
stay 100% volunteer, should belong to local collectives and regional projects.

This supports the strong diversity of approaches to this issue. Relationships
with paid employees require good communication and sometimes rapid decision
making, which is far easier in a local or possibly regional context. Living
expenses and local laws on paying people can vary widely. Finally, if there
is no network fund, as recommended below, then there is no way for the network
to employ people.

I see this as quite similar to web servers: best kept local or regional. For
funding, there are some strong logistical restrictions on globally sharing the
management of money.

The choice of location of the money has strong effects on how easy it is for
people to donate or receive money, due to the costs and hassle in transferring
money overseas, and changes in laws such as tax exemption status (e.g. someone
donating from Australia to a fund based in the USA cannot claim a tax deduction).

So people making donations might choose to give their money to a local IMC,
or to a specific IMC further afield. They might do that because they support
the activities of that IMC in their local area, or because a specific IMC commits
a lot of resources to effectively helping other indymedia centres (such as an
indymedia centre that runs a shared web server).

There might be some efficiency gains in pooling money within a region, because
there are some overheads in setting up the infrastructure to receive online
donations, or to share the work of creating and maintaining a tax exempt organisation.

Such infrastructure is usually only useful for money movements within a country,
so I can see little benefit in setting up a fund for donations on behalf the
whole network. Avoiding a global fund means we neatly avoid a lot of potentially
very messy, slow and divisive global decisions about possibly large amounts
of money.

But there is nothing to stop local or regional funds choosing to donate their
money to IMCs outside their area. And funds might wish to invite people from
outside their area to help manage the fund and make decisions.

The people doing the work of raising the money should have a substantial say
in how it is managed. They might decide to apply the money to their local indymedia
centre, e.g. for media production equipment. They might contribute funds to
a project that helps cities in their region or elsewhere, such as technical
resources for a web server. Or they might simply send the money to an indymedia
centre overseas.

In all cases, once the money is received by a group, it is a donation, so it
is up to the recipient to decide how to spend it. Giving money to another group
and saying they must spend it on travel or a digital camera reduces the autonomy
of the recipient. If people giving money want to have some influence on what
the money is spent on, they could look for groups who are asking for money for
projects they are interested in supporting. Or they could suggest a good way
to spend it, without attaching it as a condition.

Independent media centres need to stay independent of large concentrations
of money and power. This is a major motivation for our existance, and could
easily become one of the standards that define our network.

Keeping our decisions isolated from the opinions of people who might want to
donate to us can be tricky. One way to insulate us from the power of money is
to work on projects that require only small amounts of money. Another is to
be extremely careful of the conditions that might be attached to funding, especially
from the criteria and spending rules of organisations that give out grants.

Because the indymeda network has a lot of power, I think it is especially important
to keep large amounts of money away from our network decision making. This is
a big advantage in not having a network fund - we do not need to make network
funding decisions if the network has no money.

There is a bank account in the USA with $11,000 in it. This has been donated
by people wanting to help with global indymedia.

To move to a network without a global fund, we could stop inviting money for
that fund, and instead direct donors to a list of projects and indymedia centres
working to support global indymedia, as well as point out that each indymedia
centres will have a page explaining how to donate to that centre. We might choose
to highlight the donation information for indymedia centres in the global South.
Or we could highlight regional funds setup to support global indymedia.

After making a one-off decision on how to use the $11,000, this ``global indymedia''
fund could be closed down or renamed as the ``North American fund supporting
global indymedia''.

I think there are a lot of advantages in having a global front page for the
network. I believe it should stay global, as that is what a lot of our audience
is looking for. But there are various ways we could decentralise parts of the
management.

editorial:

we already have an autonomous editorial working group for www.indymedia.org;
people from any indymedia centre are welcome to join the work and therefore
help make decisions.

syndication:

we have some of the technology almost ready to display the headlines
from one indymedia site on another. We could use this to rotate headlines from
different local indymedia sites in a section on the global front page.

regional:

if the indymedia network starts forming regions, each with their
own front page, we could use the global front page to highlight the different
regions and display syndicated headlines. The regions would then in turn manage
the process of sharing stories between the local indymedia centres and the regional
site. A similar model might work for topic areas, such as migration or ecology.

language:

currently www.indymedia.org can carry newswire stories in many languages,
but the centre features column is in English (as are most of the newswire stories).
Global collaborations might be formed to create alternative front pages in major
global languages other than English.

random:

visiting the front page could take you to a random local page. Or to
a simple list of all the local IMCs. I don't think we're ready for this, because
it is difficult to get a sense of the global from many local sites, and it would
encourage story contributors to post to all sites instead of to their local,
regional, and global one.

As far as technical resources to run the global front page, they can be substantial,
because it gets a lot more visitors than local indymedia centres do (except
during large direct action events in a specific city). However, some of the
methods above will spread the visitors among the other sites. And we can rotate
the hosting of the global front page among the indymedia shared web servers
that are willing to take it on.

Each network would be formed on the basis of some common ground. The affinity
might be regional location (Europe, North America, South East Asia), a particular
subject (such as labour, gender, forestry, human rights) or a set of standards.
Indymedia centres might choose to join a number of networks.

There are a lot of details that would need to be sorted out for us to take on
some of the ideas above. But what I mainly wanted to do was give an impression
of how we could think about the network.

Our strength is being local, loud, and diverse. Let's use that as much as we
can. We should only centralise across the network when we absolutely must, and
the best time to do that is the work we do to figure out what goals and methods
we have in common. That will help us to encourage diverse parts of indymedia
to grow and prosper, and yet still to lend strength and support to each other
as they are able. It's an ecosystem, where each part has its place, its independence,
and its links with the entire network.