Matthew Arnison - Sydney Indymedia volunteer
Version 0.2 June 2001
Local decisions: autonomous local indymedia collectives
Network decisions: standards, *.indymedia.org, cities.inc, loudeye.com
Locally or regionally based (with possible global collaboration): mailing lists, web servers, training, workers, funding
Global collaborations: software programming, www.indymedia.org
This is my writing but it's based on many discussions and ideas from others.
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.
These are some of the things that affect all indymedia centres:
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.
Looking at the issues again (see above[*]), these are my thoughts on where decisions might best be made.
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.
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.
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.
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.