Great to see this

now you guys are the experts so I don't want to go barging into things, but in the longer term, we at Network are very keen to keep a long term 'distributed' model in mind, with distributions and mirrors around the world (possibly on local servers running on local energy, swapping info back ups). This would be a more resilient model technically and socially - if we're centrally hosted in one place we're much more vulnerable to all sorts of things...

(hope you don't mind me barging in!)

Really interesting discussion. It reminds me of our initiative's discussions when we first decided to try to build a system which not just our own but any new initiative could use. We wanted to save them from having to repeat the same work we were doing, seeing that as hugely wasteful of time and resources. So, while I can see both sides of the debate, perhaps if we examine the requirements and what is already happening out in the field (perhaps via the survey), we can look at where centralisation might be necessary or enormously beneficial as well as where a distributed model is clearly better.

I'm still a newbie on infrastructure but from where I sit, I can see at least three areas this impacts:

• Content provisioning - it stands to reason that each town should write their own content. Each town's content needs will likely be different enough that somehow providing a base level of content in the installation could be unhelpful. It might feel presumptuous, could cause SEO issues and would take a long time to agree upon. On the flipside, busy transition initiative coordinators who are already struggling with a global recession might benefit from being handed a set of base level pages which do some of the grunt work for them.
• Site structure - Having explored the structure of quite a number of TT sites from around the world now, there's an interesting commonality of navigation and content which leads me to think at least some centralised Information Architecture is definitely possible.
• Site installation, hosting & management

As to Site Installation, Hosting and Management (which with Drupal is a significant challenge) it seems we have three basic options:

1. Total decentralisation where we simply give everyone a ZIP file containing the installation profile with an instruction manual and let them get on with it, managing and hosting locally. I don't favour this idea since, if a town does not already have a Drupal expert on-hand, it would take them a long time to get up to speed with learning the system to a high enough degree and leaves a dozens of small local teams wasting time on web site maintenance when they could be out doing useful work.
2. Total centralisation where a new initiative would submit a request to set up a new site, give a central coordinating team at the global or national level a name and address for the site and it would then be set up for them and hosted and managed centrally (with them managing content and basic admin). I also worry about this approach since it will involve potentially huge amounts of work for the central group and could present other problems which Ed mentions.
3. A managed decentralised solution where we offer a flexible package so the larger initiatives (those confident with IT and with expert in-house knowledge of Drupal) get a ZIPped profile package to install on a local ecohosting provider along with Andre's ET Phone Home support module for remote feature upgrades and security admin. Meanwhile smaller towns with no local expertise could host their site with us centrally for a nominal hosting fee. They would have content admin and some admin rights but would delegate maintenance to a core team. Could this solve some or all of the issues you all identified?

I suspect you're right about the proportion of towns who'd find a centrally-managed infrastructure offering attractive but, having some experience of working with a global, federated but devolved organisation of national-level autonomous groups, it might perhaps be worth doing a quick-and-dirty marketing survey to check our assumptions are correct... Ed's points about the human factors of these questions are valid (and seem to be drawn from personal Transition experience).

;-D

Having had a quick scan of the documentation for Aegir, it's clearly awesome. So, assuming we're right and hundreds of initiatives take up our offer of TD1.0, do you have any thoughts/research on Ed's other point about sustainability of hosting providers, along with my point about workload of managing multiple sites? I note from this DevSeed post from March 2010 that it's now even possible for Aegir to manage multi-server site provisioning so would this answer both sets of requirements?

Less obvious is whether an Aegir-managed cluster of sites is relatively simple to maintain if all the sites have non-identical functionality. Does it get more complex if one town wanted a different IA, a different set of functions or some other variation from the standard install profile? Do we simply say to people, "Sorry about this, but in order to install and use TD for your site and get ongoing free support, you're going to have to rename your 'Teams' as 'Groups' and no, 'Projects' get a wiki but you can't also have a photo library."

Or can Aegir work around varied components/features/installations/IA labels etc?

For instance, we've identified some areas where we think the TT Belsize group will want a slightly different site configuration to ours. We think they might want a different emphasis on their home page by using a different View config to ours, or they might want a Project wiki instead of a more CCK-based structure to their Project reference section, or a different array of panels. But if every town wants to vary these types of components, would Aegir still be able to cope with managing all those varying configurations successfully?

Hi Chuck (and all):
Glad to see Transition Houston is getting started. If you're working through the process of getting a site / communications infrastructure up and running, I would invite you to join in the discussion about starting a (possibly Drupal-based) Transition Initiatives web platform "package", so that new initiatives don't have to figure all this out from the ground up.

I've started a thread on the subject, and if you're interested in helping to brainstorm on this I think we can make it into something that will really help accelerate the Transition movement's growth through better communication, and facilitate these new initiatives in solving the web / comm startup problem. (Not to mention helping older initiatives to solve some existing needs and problems!)

If you're interested in joining the discussion, please sign on with a comment at the forums thread:
http://groups.drupal.org/node/80714

Sincerely,