[Imc-oceania] Fwd: [Imc-aotearoa] Log of Oceania IRC meeting held 2007-06-17

smush capitalism smushcapitalism at gmail.com
Tue Jun 19 08:46:07 UTC 2007


hey,
here are some comments from strypey (Aotearoa IMC)

---------- Forwarded message ----------
From: Danyl Strype <strypey at riseup.net>
Date: Jun 18, 2007 3:46 PM
Subject: Re: [Imc-aotearoa] Log of Oceania IRC meeting held 2007-06-17
To: imc-aotearoa at lists.indymedia.org


Kia ora koutou

Just looking through the log from the Oceania IRC on Sunday. A bit of
feedback.

It's logical to me that building Indy software on top of a regularly
updated CMS like Drupal with lots of non-Indy geeks supporting it
would significantly reduce the workload of Indy geeks, both the
programming work of fixing bugs and security and providing technical
support to individual IMCs. Andrew has been part of the CMS
evalutation discussion and believes that Drupal has majority, although
not unanimous support.

Shayne and others may not like Drupal and if they have the skills and
time to support Mir, or something else, that's fine. It's not a
question of whether Indy geeks can force individual IMCs to use this
or that software. It's a question of whether there is enough Indy geek
energy to keep updating Indy software to keep it secure, spam-free and
upgrading it to add features like video-integration that IMCistas are
wanting.

The proposal of a single back-end and multiple front-ends came out of
a discussion between Sebastian and I late in the evening. To use a
baking analogy, the back-end engine would be like a bowl of cookie
dough. Each IMC front-end site would use the same dough but they could
choose the shape of their cookie cutter, what kind of icing to put on
top etc

The advantage of only having to improve the dough recipe by upgrading
one working piece of software is obvious. For example, spammers find a
new way to spam any PHP-based CMS (including most IMC codebases except
Mir, which is Java). At the moment codebase upgrades to prevent such
spam require days of work for each tech team supporting each site.

With one IndyDrupal engine driving multiple Oceania IMC sites, the
process would go something like this:
- the first person in the Drupal community to fix the problem submits
their patch to the Drupal maintainers
- the IndyDrupal maintainers are notified and release an upgrade
- Whoever is maintaining the IndyDrupal engine for Oceania upgrades the engine
- voila the spam stops on all Oceania sites

Potentially while the version on the usual server is upgraded, the
working sites could be temporarily shifted to an engine running the
upgraded IndyDrupal on another server, meaning *NO downtime* during
the upgrade!

Sebastian seems to think the one back-end approach is technically
feasible for the same reason that its feasible for more than one
website to run on one server, or for more than one server to run in
one physical computer box.

<geek> Basically object-orientated programming means that when you run
a piece of software it can create multiple objects based on one
template (or 'class'). So the back-end engine would provide a class
'IMC' and each front-end site would be an IMC object with access to
all the properties and functions of that class </geek>

Shayne's desire to use something other than Drupal for the engine is
worth considering. But again, the reason why the majority of Indy
geeks now seem to be favouring Drupal is that if we want to be able to
spread the load and survive turnover of tech volunteers as their
availability changes we need to use something easy to learn and
support, preferably something that lots of people already use.

As well as ignoring the proven benefits of open source-style
collaboration, the demands for fewer techs putting in more time, with
some guarantee of continuity, is quite simply unrealistic. It's like
expecting a couple of organic farmers to provide you with all the free
food you need just because you are running a carey-sharey food co-op
rather than a supermarket. In reality IT skills are in high demand and
the people who have them and spend significant effort acquiring and
increasing them need to eat. Unless we are willing to pay them (or
somehow provide them with free housing, clothing, food and internet
access), we will never have techs doing more than casual work for
Indymedia. As I see it we need to either change the PoU and start
paying people for tech work or actively pursue strategies of tech
skill-sharing and load-balancing - some sort of apprentice system?

Shayne's point about the autonomy of each site/ collective is
important but personally if I was worried about loss of autonomy I
would be proposing hosting Aotearoa IMC on a server in this country
rather than on Axxs. Again the question is do we have enough geek
energy to maintain separate installations, separate servers, for each
site?

Surely a certain amount of infrastructural centralization provides for
more autonomy than sites having to shut down completely like Melbourne
is doing? Or having all cities and countries assimilated into one Oz/
Oceania site which seemed to be the proposal that initiated the
meeting. Ultimately whether an IMC in the Oceania region wanted to be
part of that infrastructure of organise their own hosting and tech
support would still be up to their collective. But potentially it
could mean that collectives in small but distinct areas with net
access but no geeks likely to volunteer, could have their own site.
Under the current situation this would be difficult if not impossible.

As for Smush's comments about the Pasifica situation, I guess the
question is does an IMC exist to circulate news within a community or
get that community's news out to the world? If an area doesn't need an
open-publishing site, what does it need Indymedia for? Maybe physical
spaces like the original IMC in Seattle, with fundraising for gear and
training done by Oz/ Aotearoa/ US groups or sought from imc-finance?
This could provide space and equipment for a range of media-making and
distribution projects like the print and radio that Smush mentioned,
as well as access to an open-publishing website.

As for the login system Nigel mentions, we've seen what the login
system on the new Dada has done to AotearoaIMC. It sucks. We've lost
much of the personalization of posting because logging in is a hassle.
Even I can't be bothered! If we took away the ability to post
anonymously even fewer people would bother, which would likely leave a
loyal clique of Indy-fans talking mostly to themselves. Also it would
remove one of the few distinct things about Indymedia sites as a space
for resistence - the ability to safely post whistle-blowing material
anonymously - things like ALF communiques for example.

I do like Nigels' proposal for an activist social networking system. I
hate the fact activists use Murdoch-owned MySpace and other privately
owned, proprietary systems like FaceBook. But I think to be effective
it would have to be geo-located (so people can meet and work together
in person as well as online) and broader than just Indymedia. There
was a meeting recently in the US, with folks from a number of radical
tech collectives, about developing a decentralized, open source social
networking platform. Hopefully this will bear fruit.

Anyway great to see there is still a hard core of people committed to
keeping *something* running under the name of Indymedia/ IMC into the
future.

RnB
Strypes

BTW Smush, can you pass this on to the Oceania list of whatever?
_______________________________________________
imc-aotearoa mailing list
imc-aotearoa at lists.indymedia.org
http://lists.indymedia.org/mailman/listinfo/imc-aotearoa



More information about the Imc-oceania mailing list