Gav's Blog

Hi all,

It has been some time since I have been in touch, and I apologise for that. I’ll keep this email relatively brief, and had I made the time sooner, I should have sent it a couple of months back.

In short, I am struggling to keep up with my ‘official’ Sahana commitments – although most of you have picked this up already. The main purpose of this email is to just make it official – I need to stand down from all my official Sahana roles – Board, PMCs, GSOC, admin and other relevant committees I am on. This absolutely doesn’t preclude me returning to some roles later, but I do need to make a clean break for the time being.

You shouldn’t read anything more into this other than I’m struggling to put time into SSF activities currently, and I shouldn’t be occupying slots that may be able to be filled by more active people. I quite simply am not in a position to meet any required expectations placed upon me for the foreseeable future.

I’m still absolutely behind Sahana, and as time permits, I’ll be starting on small hands-on projects from the ground up based on observations, experiences and discussions I’ve had as a result of the ongoing run of Christchurch earthquakes. Most of these will be with Sahana Eden, and working on detailed applications such as building information management, managing map production requests within GIS departments, rostering of volunteers, managing radio assets, and managing vehicle logistics.

A related aside – I’ve been interviewed and invited to be ‘under training’ to be a member of the New Zealand Red Cross Information Technology and Telecommunications (IT&T) Emergency Response Unit (ERU). This is one of five worldwide Red Cross IT&T ERU’s than can be deployed to support Red Cross operations to disasters and complex emergencies, and deployments can be up to five weeks in length.

Cheers Gav

Over the years I’ve had a few ideas how we could improve the gathering of intelligence for an emergency, and how this could be linked into both situation reporting and as an action tracking tool for operations and other general management tasks.

Most of this thought has been directed at how to implement it in a Sahana product, but it could conceivably be applied to any product for emergency management, or even broader business/organisation management. Aspects of this solution already exist across both Ushahidi and Sahana – but neither provide the comprehensive solution yet.

This need was also something that I saw during my involvement in Building Safety Evaluation during the Canterbury Earthquake in 2010. It is also potentially a far more robust means of managing the collection of intelligence associated with an emergency.

I’ll talk about this using a modular approach – making the assumption that different groups of users will have different types of access, to ensure the protection of submitted information (see here for a reason why).

Capturing the Information
The first module would be the Intelligence Gathering module. It is where information from other sources is collected from other sources.

In the CrisisCommons context, this might allow an anonymous volunteer to submit cut-and-paste text from a news article on a website or from a situation report. For the purpose of this concept, I’m going to ignore the copyright issue – but do want to flag that this may be an issue with the collection of information from the media where a lot of information is copyright.

For Building Safety Evaluation, this may be the unstructured reports that we received that ‘the wall on this building looks like it is about to fall on a neighbouring building’.

So this module basically allows for the entry and recording of what is mostly unstructured information – it may be from a website, a phone call, SMS, even a scribbled piece of paper that someone passes you in the EOC.

Such a system could be easily configured to allow members of the public, or crowdsourcing volunteers to enter such information without having to register or have an account – thereby keeping the barrier to collecting raw information low.

Adding Structure and Metadata
Having this information in digital form is just the start however, the next step is to get a team of trusted individuals to then review the submitted information and critique it for quality, actionability, and credibility. At they same time they would ideally try and add other metadata to the record.

Does it currently contain a freeform address? Then the reviewer would then associate an address with the record, and this would properly structure the address information. If a geocoder is available then latitude and longitude records would also be entered.

We had some issues in Christchurch whereby some addresses that were reported are not official addresses recognised by the council property system – this usually happens with ‘vanity’ address. Our Kestrel office in Kestrel has a common/vanity address of 35 Riccarton Road, but for council and utility purposes, our building is actually 39 Riccarton Road. I spent a bit of time in September, and again following the Boxing Day aftershock checking some of the incoming addresses that were provided, and then record a Council GIS identifier once we had correctly identified the address. Again, this would be another means of tagging the raw data with something that adds valuable metadata to incoming information.

Does it have a phone number? Associate a structured phone number.

What does the record refer to? Add tags from a controlled taxonomy so that the record can be filtered – e.g. if the record refers to building damage, it may be tagged with ‘building evaluation’. If it is a report of a missing person, it should be tagged with ‘missing person’.

This is perhaps the most time-consuming part, but it is also most required, as it opens up a lot more potential for actually managing and sharing the information.

Wrapping it all in Management Tools and Reporting
Now we can finally get down to the crux of what we’re trying to achieve – take raw unstructured information and provide it in a form that information systems can understand it, present it, and search it in far more valuable ways.

If we assume that all incoming information about building safety is tagged with ‘building evaluation’ then we can provide a web page that allows someone in the building safety evaluation team to review all the incoming reports that are relevant to them.

At this point we go the final step, as we start allowing people in these focused teams to start associating actions and history to the original record. You may have a small team with Build Evaluation reviewing incoming records for ‘building evaluation’ when they see it, because the address (and potentially lat/long and council identifiers), it should be trivial to see if other records have been entered that refer to the same building, or nearby buildings. Without adding this metadata previously, it would be a lot harder to automated some of this information management.

We can then link multiple records that refer to the same building – such as different reports over time, or a neighbouring property that may refer to the building.

The best part though, is when we start adding actions – for example, if an Urban Search and Rescue Team is tasked to a building, then that action (Sending a team to perform an intial rapid building assessment) can be associated to that building and the team, and of course the original record that reported it. This means that if someone enquires if anything is being done, we have the history of who was tasked where and when.

When the team returns, we can mark the action as completed – we have a record that it has been completed. Not only that, but any quick comments from the team could be added as a new record associated with that building. Likewise, any digital photos, or even scanned copies of the rapid building damage assessment forms could be attached.

Scanned forms are of course interesting, as you could scan them initially and add them to the system as images, but also flag those to be reviewed to create metadata so that the form data is now accessible via metadata – such as the building status as determined by the assessment Safe/Green, Restricted/Yellow or No Access/Red. Whilst Optical Character Recognition (OCR) could speed this process, after seeing the handwriting of engineers, I’d suggest that human review and triage of key information on the forms would get more usable information into the system sooner. And yes – the idea is of course a tablet application that digitises the information in the field and uses an Emergency Data eXchange Language (EDXL) extension to submit the information via EDXL-DE back to a server.

Of course, with all this structured metadata now wrapped around the original unstructured reports – this opens up so much potential for reporting and where appropriate sharing this information using standards such as the EDXL for achieving true information interoperability.

This is something that both Ushahidi and Sahana have been working since the response to the Haiti earthquake when we were trying to provide management tools in Sahana Eden to wrap around the crowdsourced information that was being collected by Ushahidi.

Recently discussion on the CrisisCommons email list raised an issue about security pertaining to crowdsourced data – and the ease with which the information can be deleted by an anonymous malicious individual when using tools such as etherpad or Google Docs with open editing rights.

In this case an anonymous user was deleting data as quickly as it was entered in a shared public document. What is a more concerning risk is perhaps the subtle editing of crowdsourced information, where the edits are not obvious enough to be detected – such as the subtle and malicious modification of facts and figures.

For tech volunteers, there is a careful balance to be struck between protecting information (in this particular case its availability and integrity) and not creating significant barriers to entry.

The first obvious solution is that access on the document be restricted to authorised users. This means that only those individuals that are trusted can be expected to contribute to the collection and management of unstructured crowdsourced information.

This is less than ideal as it means that new users that volunteer immediately following an emergency haven’t developed a trust relationship with, for example, the CrisisCommons community, and are unable to immediately contribute.

I believe that with the simple use of a two-tier approach, one can easily protect the quality of the final document(s), whilst still making it easy for new volunteers to contribute.

You effectively create two types of document:

1. Public and open documents – which are open to all to edit, and are effectively a rough scratchpad for collecting unstructured information.
2. Trusted documents – which are open for only a limited pool of trusted users to edit, but draw from the content provided in the public and open documents.

The trusted editors effectively become the curators of the information, and once content has been copied and edited from the open documents, malicious anonymous users won’t be able to waste other volunteers time through deletion or editing.

There are other process benefits to this approach. For example, you may create a public document particular topics of the emergency – such as infrastructure, health/medical and background information (e.g. weather forecasts, population demographics etc) and these multiple individual documents may map to a single section within the trusted document to produce an edited and trusted version of crowdsourced information.

Still, from an operational perspective, this is a far from ideal approach, and there are certainly more robust approaches available to turn this into a process that can be used for intelligence gathering and situation reporting.

So, before I kick into writing about what we did, I need to provide a little background.

A very good friend and business partner of mine, Dave Brunsdon, has been heavily involved in earthquake engineering in New Zealand for a good 20-25 years now. I’ve had the pleasure to be mentored by him, and work alongside him with Kestrel client projects. One of his many hats is that of the Past President of the New Zealand Society for Earthquake Engineering (NZSEE).

Over the past few years, Dave has led a combined project between the NZSEE, the Department of Building and Housing, and the Ministry of Civil Defence and Emergency Management. This has resulted in the creation of the Building Safety Evaluation in a State of Emergency: Guidelines for Territorial Authorities. To provide a brief summary here:

The NZSEE Building Safety Evaluation Guidelines provide guidance for Territorial Authority Building Control Managers to prepare for, implement and manage building structural safety evaluation activities after major earthquakes or other disaster events, and for engineers and others assisting with the process in the field. The document was produced with support from the Department of Building and Housing (DBH) and the Ministry of Civil Defence & Emergency Management (MCDEM).

The original version was a 1998 document, that had its roots in the US-based Applied Technology Council’s Postearthquake Damage and Safety Evaluation of Buildings (ATC 20) that were initially developed in 1995. Over the past five years, the NZSEE guidelines have seen a number of improvements and refinements.

On the 20th of December 2007, Gisborne, in the north-east of the North Island of New Zealand experienced a 6.8 M_L earthquake that caused 1 fatality, a number of injuries, and damage a lot of structures in Gisborne, including heavily impacting the central business district. I believe this was one of the first events where the updated building safety evaluation guidelines were utilised.

Naturally there was a draft update in August 2008 incorporating learnings from Gisborne, and then a full August 2009 update.

On the 30th of September, 2009, a 7.6 M_w earthquake occurred just offshore from the Indonesian city of Padang. This earthquake caused the deaths of over 1100 people. Within a week, New Zealand had committed to sending a 10 person project team of structural engineers under the banner of the NZSEE. It was at this point I became involved at very short notice (Saturday evening, engineers departing Sunday morning) to purchase and kit out the team with suitable GPS units to be used in the assessment process. I’ll write more about this decision in another post – I recommended, and purchased 6 Garmin Oregon 550 handheld GPS units with an inbuilt 3.2MP geotagging camera.

The NZSEE team spent around 10 days in Padang initially, and during this time assessed around 200-250 structures – mostly government facilities, hospitals, schools and the like. It was during this trip that the information management issue first became apparent to the project team. Dr Clark Hyland developed a spreadsheet to capture the assessment information whilst in Indonesia, and continued development of this solution upon his return.

As a result of Padang, and indeed Chile (another NZSEE team was sent, although the Chile team was more a research team) the NZSEE guidelines were undergoing further revision in New Zealand in the months leading up to the September 4 Darfield Earthquake.

I am aware of at least two other similar building safety evaluation frameworks.

• ATC-20 – the original US framework (first edition 1989, second edition 2005). Please note that this is a paid-for framework – it currently costs USD$24.
• An Italian framework (that I need to find more links and information about)

Since I had heard about the spreadsheet used in Padang, I became interested in implementing the NZSEE framework (and indeed also being able to support ATC-20, and the Italian frameworks and others) in a Sahana product. Whilst over at the Sahana Forum held in Taiwan on 30 July, and the SahanaCamp from Saturday 31 July to Tuesday 3 July, I started playing around with an implementation in Sahana Eden. Unfortunately my programming skills, and other activities meant I was nowhere near having a working implementation ready for use immediately following the 4th of September earthquake.

Note – as per Flickr’s linking requirements, the image goes to Flickr not directly to the NZSEE website. The other links in the text do.

It is great to see our Sahana products being used more widely, and we’ve taken a big step recently to go beyond just being used as a tool for Response and Recovery.

The Asian Disaster Preparedness Center and partners have released their Disaster Risk Reduction Project Portal for Asia and the Pacific which is built upon the Sahana Eden platform. This is designed as a means of sharing who is doing what and where. As well as listing proposed, active and complete projects, it also provides a list of relevant frameworks. At time of writing it lists 414 projects, and 90 frameworks.

Big congratulations to Michael, Fran, and the others involved in delivering this solution.

Something that has concerned me for some time, is that a lot of information systems used for emergency management tend to focus on just one or two phases, rather than providing a comprehensive system. This is important as often the information used in one phase, e.g. risk reduction, can be useful to have available during response and recovery. I’m hopeful that this deployment will be the first of many that extends Sahana into a useful to for both reduction and readiness, and will eventually become an EM system that can be used right across the Four R’s.

Note – image links to Flick photo page due to Flickr terms and conditions. I’ve put an additional link in the description that takes you to the website.

One question that I’ve had about building a solution for Building Safety Evaluation (BSE) is whether it should be built into an existing council system, or indeed implemented on existing council systems, or perhaps a standalone solution should be used. Clearly there are pros and cons both ways, but I’m definitely tending towards a standalone solution – at least initially. I certainly gained some insights in the 7 days that I had working within CCC’s BSE team.

There are certainly benefits to be gained from integrating a BSE into existing council systems. These include:

• Information as it is captured goes directly into the business-as-usual systems.
• Building information is tightly linked to existing council data structures e.g. building records, ids etc.

But there are problems associated with systems implemented on a per-council basis:

• It requires each and every council to build and integrate a BSE system into their existing systems – something which most don’t have the time or budget to do, especially for relatively infrequent events.
• It is harder to bring in staff from other councils to provide surge capacity for the data entry tasks (data entry is another problem I’ll get to as well) – they would be more likely to be trained in a different system that their council uses.
• As an inhouse solution would be limited by existing council IT systems – don’t underestimate some of the issues associated with getting large organisations IT systems working following a disaster of this magnitude.

I will admit to being slightly biased, but I believe a more sustainable solution is to create a free and open source software tool that can be used in a standalone manner for the first few weeks, and then council IT staff can find a means to import the information back into the council system. This would likely become easier if the BSE data was able to be implemented in a standard XML format. I’d like to see an OASIS Emergency Data eXchange Language (EDXL) extension created for representing BSE information.

Why do I think an open source source solution would be best?

• The system will be relatively infrequently used, so it is easier to justify a consortium approach to development. This will be far cheaper than multiple councils thinking about building their own bespoke solution, that probably won’t be compatible with neighbouring councils. This means multiple councils, and indeed governments worldwide may be able to contribute relatively small amounts each to build a better system than any one single organisation could build.
• Being free, it is also likely to be widely deployed, and this means that rather than just having one councils staff trained in their systems use, there are likely to be an order of magnitude more people trained in its use if it is open source. This greatly increases the ability to have surge capacity for data entry.
• An open source solution is also likely to implement open standards, whereas a bespoke council system is likely to forgo the additional cost associated with implementing a recognised data interoperability standard. This means that bespoke council BSE systems will be inherently closed, and potentially incompatible with their neighbouring councils. An open source application with open standards automatically means that neighbouring councils can either share the one system, or at least use the same software on separate instances, and use the interoperability standards to allow easy aggregation of the BSE data for reporting.
• Open source would also allow the creation of what is effectively a BSE kit in a box. A wireless hub, a handful of netbooks etc and it would be quite easy to have a portable, redeployable and standalone kit for implementing BSE without having to depend upon any existing organisational IT infrastructure.

So, for the time being, I’ve convinced myself that a standalone open source BSE application is probably preferable to councils implementing their own system in house.

This is a followup email that went out today to prompt new leadership of the Sahana PHP project.

In my long email nearly a week ago, I suggested that we dissolve the existing PMC. I would now like to start community discussion about forming a new PMC to provide the leadership that the PHP project requires, and has not received for a long time.

A brief reminder why I think the PMC should be dissolved
No, actually, it is the leadership of the PHP project’s fault, and as one of the members of the PMC, I have to shoulder some of that blame like many other people here. Fran et al raised many issues in 2008 about not only the core framework of Sahana PHP, but also infrastructure. He and others tried to work within the PHP project, BUT NOTHING EVER HAPPENED. He tried to work within the rules but the PHP PMC failed him completely. In the end, Fran et al did exactly the right thing to do with open source software and fork/recode. The PHP PMC never ever made any decisions to modernise or improve the core framework. We never responded to Fran’s issues, and now, nearly a whole year later, we still have not made much progress on project infrastructure. It is entirely the PHP PMC’s fault for showing a lack of leadership, and not getting things done. I am honestly at the point where I believe the current PHP PMC is dysfunctional, and I would like to see a brand new leadership team form by those that want to take the reigns of Sahana (PHP). The only thing that Fran et al did wrong was to use the Sahana brand without permission.
Likewise, there have been many stunning contributions to Sahana (PHP) both in bug fixing and adding new features. These developers have also been caught up in the complete lack of leadership provided by the Sahana (PHP) PMC.

Tearing the old PMC down
If I had been off the mark in my original comments, I would have expected a lot of replies in the negative. I received none – neither publicly or privately. So, I can only assume that you agree with what I said, or you didn’t read my email

I would like to put forward the following proposals to the community – this would effectively close down the existing PMC.
1. That the existing pmc@ email alias be closed down.
2. That we capture for historical and recognition purposes all the members of the PMC and record this on sahanafoundation.org

Do we need a new PMC? Can’t we just do it on maindev?
I would like to think that we can do everything in the open this time, e.g. the new PMC shouldn’t have a separate and private email list. Most of the reasons that the PMC was private originally are now being managed by the Board anyway. We need people to stand up and put their names behind the project, set direction, and lead. Being a part of the new PMC is about taking responsibility and publicly stating that you’re prepared to step up and lead the PHP project, and putting your name behind it.

Standing up a new PMC
I would also like discussion about how we could create a new PMC structure for the PHP project. I believe the membership of the PMC should follow a very different model to the old PMC. The old PMC was based around committership – which this is appropriate in a developer-led project (e.g. Apache HTTPD) with traditional CVS. I don’t believe it is an appropriate model where we are producing a domain-specific application. At the same time, as we move to a distributed CVS, the concept of commitership becomes far less important, and it all becomes about responsibility for merges back into the main repository.

I see there are two key areas that a new PMC needs:
1. It needs domain leadership – I would like to see people from the likes of CUNY and NIH be a part of leading the project from a domain perspective. They have some of our best end-user interaction, and having them on the PMC will be a key means of getting end-user feedback incorporated at a strategic level in the project.
2. It needs technical leadership – to act quickly and responsively to ideas and requests from the community around the likes of PHP framework choice, infrastructure, merges, and release management process (recognising that releases also need to be linked to the domain and end-user needs).

I think there are two simple membership rules (in concept) required for the new PMC.
1. Anyone that is prepared to take a leadership role in the project can join.
2. Anyone that becomes inactive or fails to ‘get things done’ is removed from the PMC (e.g. lack of participation in voting)

The PMC has to be about ‘getting things done’ and should no longer be a part of a coder>committer>PMC pathway. As this is not a developer-led project, but rather a domain-led project, the traditional developer pathway makes no sense.

First Actions for the new PMC
There are some urgent actions required by members of a new PHP PMC.
* Developing project and mentor capacity for GSOC 2010
* Consider tagging 0.6.2 as a dead branch (in terms of focusing volunteers at least)
* Identify the trunk for future development focus (I believe we should adopt the RELIEF branch)
* Future direction
* Oversee the PHP framework discussion
* Can PHP be differentiated from Python
* Is it an effective use of volunteer resource to move Sahana PHP to a modern PHP framework, or is it more effective to adopt Sahana Python (given they are already a solid 15 months ahead)

Implications for GSOC
If the Sahana Software Foundation is announced as a GSOC mentoring organisation later this week, and we don’t have an active leadership team for the PHP project, then it will be a lot harder to justify GSOC slots going to the PHP project. Remember that this year each project is going to be responsible for managing project selection, mentors etc. As a GSOC Admin for the Sahana Software Foundation – I (and David) need to see strong leadership and support available within the project to be able to make slots available to the project.

Want PHP to succeed? Then it’s time to step up?
Who is prepared to take responsibility and lead the PHP project forward? There are many names that come to mind given recent discussions – Kethees, Chad, Greg, Glenn, Chamindra. Please consider forming a new and active PMC this week as there is a lot that needs to happen. It is critically important that a leadership team is formed quickly and able to start coordinating some of the actions outlined above.

The future of the PHP project is in your hands – if you want it to succeed, now is the time to step up and play your part.

Cheers Gavin

This is an email I mailed to the Sahana developer community and the Sahana Software Foundation Board on the 10th of March following recent discussions about branding and the perceived competition between Sahana (PHP) and Sahana (Python).

Sigh. So much for getting on top of my inbox.

/me takes all official role hats off, stores them in the soapbox and steps up

I’m intending to lay down a challenge to many preconceived ideas and current thinking. I believe little will be achieved unless we can collectively – as a community – come to some agreements, and get more things done. So I’m going to be brutally honest – it is time we discussed some of the failings, accept them, and look at where we should go from here.

What is Sahana?
Sahana is not software. Sahana is an ideal to use free and open source software to improve information management before, during and after emergencies, disasters, and providing humanitarian aid. The ideal of Sahana will live long beyond any software project we currently have. The ideal itself was around before[1][2] Sahana and will likely outlive anything we do. I am still committed to this even if all our software projects and the foundation were to turn to dust.

Sahana (PHP) was the original Sahana.
No it wasn’t. The original Sahana was Mambo. And PHP. And Perl. And Java. And probably some other languages that I can’t remember. Sahana (PHP) was not the first, it was phase 2 and that was rewritten from the ground up. Perhaps one of our biggest mistakes in hindsight was not coming up with a clearer name then other than Sahana phase 1 and phase 2.

Our existing contributions will be lost.
No they won’t. This is open source, and once a contribution has been made the contribution is there until someone updates or modifies your original contribution. The code is always accessible from repositories. This isn’t a closed-source proprietary project. The only contributions that will be lost will be future contributions of those that opt out of the community. As long as you hold to the ideal of free and open source software for emergencies, disasters and humanitarian aid – then you’re in the right place.

It’s Sahana (Pythons)’s fault. Or the Board’s.
No, actually, it is the leadership of the PHP project’s fault, and as one of the members of the PMC, I have to shoulder some of that blame like many other people here. Fran et al raised many issues in 2008 about not only the core framework of Sahana PHP, but also infrastructure. He and others tried to work within the PHP project, BUT NOTHING EVER HAPPENED. He tried to work within the rules but the PHP PMC failed him completely. In the end, Fran et al did exactly the right thing to do with open source software and fork/recode. The PHP PMC never ever made any decisions to modernise or improve the core framework. We never responded to Fran’s issues, and now, nearly a whole year later, we still have not made much progress on project infrastructure. It is entirely the PHP PMC’s fault for showing a lack of leadership, and not getting things done. I am honestly at the point where I believe the current PHP PMC is dysfunctional, and I would like to see a brand new leadership team form by those that want to take the reigns of Sahana (PHP). The only thing that Fran et al did wrong was to use the Sahana brand without permission.

Personally, I have become increasingly unwilling to contribute my time to the PHP project because it takes a long time to get things done. If they are done at all. Fran et al have demonstrated that they are prepared to do the hard yards, and focus on development. I applaud their attitude, and when it comes to where I’m willing to put my volunteer time, it is increasingly coming down on the Sahana (Python) side. Honestly, I should have just shut up and learnt to code (again) many years ago.

Likewise, there have been many stunning contributions to Sahana (PHP) both in bug fixing and adding new features. These developers have also been caught up in the complete lack of leadership provided by the Sahana (PHP) PMC.

Why hasn’t Sahana (PHP) adopted modern frameworks and technologies?
Don’t blame this on the PMC or Board. I don’t recall seeing formal proposals come to either for approval. Again, like many other things, plenty of discussion, but no-one ever appeared to pick it up and run with it. There was talk of an experimental Zend branch, but I haven’t heard further discussion on this, or a call for other PHP developers to join in and support the experiment. Again – I assume that the talk has gone nowhere.

On Branding.
Quite simply, both projects (PHP and Python), have fallen into the same trap of branding based on a developer worldview, rather than thinking about how we communicate in 5 words or less what our products do to end users, and how we differentiate them. We need a complete and utter rethink of branding, and I am increasingly favouring the Apache approach whereby Sahana becomes an umbrella brand and as Sanjiva highlighted, the various projects become Sahana {project}.

Disaster Management System will probably need to go too. Increasingly, the international approach is towards Comprehensive Emergency Management[3]. We have to fit in with our end users, and for the increasing majority of them, this is Emergency Management. The concept of Humanitarian Aid is only used in countries without well developed EM systems, and many development projects are working towards helping countries develop more robust EM arrangements e.g. WorldBank and/or Asian Development Bank projects are building local emergency management capacity and capability. So from a domain perspective, Emergency Management is probably the key phrase to focus on for branding purposes for potential end users.

Should the Sahana name be earned?
In due course, yes it should. We are not at the point now where it is workable, but I would like to believe that in a few years, we could define minimum standards for interoperability, and any software application (as opposed to library, or other project) would have to meet some minimum standards of interoperability to be entitled to be called Sahana {project}. Sahana must become a quality standard, and any application that wears its badge should meet some minimum requirements. As well as standards, there are other aspects that should be considered including testing/quality, and the capacity to support remote deployments for extended periods.

Where to from here for Sahana (PHP)?
Personally, I think Sahana (PHP) has a lot of work to do to recapture momentum and accept that big change is needed. Some next steps would probably be:
* accept that 0.6.2 is a dead branch and archive it
* accept that Camp Roberts RELIEF 10-1 is the active branch and treat this as trunk
* dissolve the existing PMC
* let a new leadership team form from whoever is interested in leading the project forward – this should not be developer-only, but should include developers, users and anyone that has a stake in Sahana (PHP) and is prepared to lead it onwards and upwards.
* immediately start work on a new framework (someone suggested moving to Zend a while back – don’t forget this is open source software and you can create an unofficial branch, and just do it).
* or, and this is potentially a very difficult decision, consider whether there is too much work to update Sahana (PHP) and consider moving to support Sahana (Python). If it doesn’t take much work to modernise Sahana (PHP), then great, but if it involves a massive amount of work, then it is better for us all that we build upon the work that has already been done by Sahana (Python).

Shouldn’t businesses be driving Sahana?
There is a mixture of approaches to development of open source software, including anarchy, business-supported and non-profit. Which is the right one? Depends on the solution(s) being developed. I think that long-term, we’ll need both non-profit and business. There are situations when a non-profit e.g. Foundation is a better vehicle for development and attracting funding for developers. At other times businesses are much better for managing contractual development, deployment and support. At this point, I think the Foundation is filling much of the vacuum, but I hope that this year, we will see much more active leadership and support from both Respere and AidIQ. I actively welcome these two companies to step up and push the development of their respective projects. In all honesty, they have better interaction with end users than many of us, and are best placed to close the feedback loop to improving our software applications.

Is it time for a tough decision?
I believe it is.

It is time for me to fully lay my cards on the table. I’ve been involved with Sahana phase 2 since mid-2005. Like many others here, I have invested not only hundreds of volunteer hours in Sahana (probably over a thousand now, but I gave up counting a long time ago) but also a few thousand dollars in airfares, and have probably lost a great many dollars in terms of opportunity cost. I’m as much the volunteer contributor as anyone here, and I haven’t even managed to contribute something tangible such as code

That said, I care little for the past, because we can’t change it. I care everything about the future and where we should head to from here – the future is everything, it is the only thing we can change, and we must focus on that.

I think we would be doing a significant disservice to our potential end users by continuing the confusion of having two software application products that we have not managed to clearly differentiate.

Following the initial Sri Lankan deployment in early 2005, the decision was made that what was effectively Sahana phase 1, was not a good foundation to build upon, and that a ground up rewrite was needed. Sahana phase 2 was born. But we are now continually running up against leadership and fundamental framework issues in phase 2. I believe we are now at the point where it is becoming fairly clear that Sahana phase 2 is not providing a platform that is going to take us well into the decade we have just started. It has given us 5 great years, but I don’t believe it can take us another five. We definitely do not have a leadership team within the current PMC to accomplish that.

I would like to suggest, again personally and with no role hats on, that we accept that it is perhaps best that we wrap up new development on Sahana phase 2. This of course does not mean it is the end or that contributions are wasted. I believe we should encourage any end user interested in Sahana phase 2 to approach Respere and obtain development and support from them. No code will ever be wasted, and it would quite likely have better project leadership than we are currently seeing. The only code that would be wasted would be if we were to now attempt to migrate Sahana (PHP) to a modern framework when the majority of that work has already been completed with Sahana (Python).

I, personally, believe it is time for the volunteer development community to move on. I believe that it is now more appropriate than ever to encourage volunteer developers to focus on Sahana (Python) and to actively promote this as Sahana phase 3 – which fits with the ongoing approach since 2005. The Haiti deployment in early 2010 of Sahana (Python) clearly indicates that it is a modern and workable system. It has a team with strong leadership and the ability to make decisions and move the project forward. It has responded to many of the issues raised against Sahana (PHP). With the surge of development that is occurring since the Haiti earthquake, it now has a solid 18 months of development behind it, a significant real-world deployment, and has been seen by a lot of potential end users. It is probably easier now to port modules from PHP to Python than it will be to implement a new framework in PHP.

We need a modern and attractive focal point for volunteer developers to focus on. I don’t believe that we can provide that using Sahana (PHP) but we can with Sahana (Python).

Please consider what I have presented carefully. If we continue to divide the volunteer development community I think we will all fail – most of us know this, but few have been prepared to air it until recently. Better that we now make a clear decision, within the public community, to end serious volunteer development on Sahana (PHP) and try to rally as many developers as possible around Python as the phase 3 successor to phase 2.

A number of developers have indicated that they don’t mind PHP or Python, but you don’t like having to choose or having resources divided. I have been mulling this for a long time, and more recently discussing it with individuals, but I think the choice has at last become fairly obvious.

The time has come for Sahana phase 2 to move to maintenance-only (and of course paid support and further development is always available from Respere), and for the volunteer community, as a whole, to accept Sahana (Python) as the main development version for volunteer developers. Naturally, if volunteers want to continue support and development of PHP there is nothing stopping them, it is after all open source software.

Sahana (PHP) has done a fantastic job over the past five years, but I think it is time we seriously consider handing the baton over to Sahana (Python) to take us the next five. This is essential not because of the technology, but for community stability and providing a united front to the world at large.

Respectfully yours,

Gavin

[1] http://sourceforge.net/projects/osveoc/ (registered 2003-08-08)
[2] http://www.rediguana.co.nz/gav/2004/02/01/emergency-management-and-open-source-software/
[3] http://www.iaem.com/publications/documents/PrinciplesofEmergencyManagement.pdf

This is the presentation I gave this evening to the Canterbury Branch of the New Zealand Computer Society.

This is the original text I submitted to The Box feature on Disaster Tech on Tuesday the 2nd of June, 2009. It is archived here for my records. It also includes some additional content that didn’t make it to the print edition.

On December 26, 2004, the Boxing Day tsunami killed over 35 thousand people and displaced over half a million people in Sri Lanka alone. A massive humanitarian crisis played out in numerous other countries also affected by the magnitude 9+ Great Sumatra-Andaman earthquake and resulting tsunami. Within days it became apparent that an information system was needed to manage the massive amounts of information being generated about who was doing what, and where – at one point there were approximately 1,100 registered NGO’s operating in Sri Lanka.

It was decided by a group of Sri Lankan IT professionals that a system needed to be built to better manage the information as they couldn’t find any existing free solutions that could be quickly deployed. Free, was critical, as they couldn’t afford any commercial solutions.

Sahana was implemented within a week by around four hundred IT volunteers, and it was named after the Sinhalese word for relief. Initially it provided tools for tracking missing persons, organisations involved in response, locations and details of camps set up in response to the tsunami, and a means of accepting requests for resources such as food, water and medicine.

Following the tsunami, the Swedish International Development Agency provided funding to take the lessons learnt from writing and deploying software during a disaster, and to rebuild Sahana from the ground up, and release it as free and open source software to the world. After all, Sri Lanka had needed an open and available system to manage disaster information, surely other countries should benefit from their experience?

Since 2005, Sahana has been officially deployed to earthquakes in Pakistan, Indonesia, China and Peru; a mudslide in the Philippines; and has been deployed in New York City as a preparedness measure to help manage storm evacuations.

Being free and open source software has been critical to Sahana’s success. The more accessible a system is, the more likely it is to be adopted, used and improved. Even in developed countries, many disaster agencies are poorly funded and often cannot justify significant expenditure on systems – commercial systems are too expensive. With pressure being applied to many public budgets, the significance of this is even greater now. Perhaps the greatest benefit of applying open source approaches is that it encourages a collaborative and communal approach to improving the system. As more countries with experience in disaster management contribute to its development, this will also act as a form of expertise transfer to countries that may not have as much experience with disasters.

Following Hurricane Katrina, there were nearly 50 websites created to track missing and displaced persons – all using different systems, all collecting duplicate information, and few of them sharing. Many of the potential benefits of the technology were lost due to a lack of co-ordination and massive replication of data. Access to tools such as Sahana will be more efficient as they can be deployed faster than solutions developed after an event occurs.

Normally, management involves a ‘leisurely’ process to collect as much information as possible, to then decide what actions should be taken. This is completely the opposite immediately following a disaster whereby decisions have to be made, sometimes with little or no information and no time to gather it.

A key benefit that IT can provide is in linking silos of information held by different organisations – everyone has a better shared picture of what has happened, what is occurring now, and what is planned.

Software, however, is just one aspect. There is a need for open data (such as maps and statistics) and standards to ensure that the multitude of systems can connect to each other and share information.

The most important aspect is having the relationships between organisations set up in advance of a disaster. This results in organisations having the confidence to connect their systems and share information. Without shared information the rest of the system will lose many potential benefits that IT can bring to disaster management.

Often, little or no information is available to support decision-making – emergency managers are forced to make complex decisions without having the luxury of all the required information.

A disaster can produce a massive number of tasks requiring hundreds of organisations and thousands of people to co-ordinate activity – meaning that there will always be some prioritisation needed. What should be done first? What can wait until later? How should an impacted community prioritise response and recovery with limited resources?

The benefits are not just limited to agencies and NGO’s. The next evolutionary step will be to adopt an approach called ‘crowd sourcing’ whereby members of the community are provided with tools to interact with each other and emergency managers.

This may be achieved with applications that run on mobile phones linking people and even submitting information from the field directly to Sahana servers. Imagine the situation where a passerby can take a georeferenced photo of some disaster damage, and if communications networks are working, send that directly to the system emergency managers are using to manage the event. There are a numberof efforts underway looking at how social networks and websites such as Facebook and Twitter can be utilised during a disaster.

Disaster IT is really a force multiplier. It won’t usually save lives, but it will allow a better shared understanding of the problems, and will lead to more effective and co-ordinated response. It allows those responding to an event, whether an organisation or individual, to quickly access information and better inform decision-making. This can lead to less suffering and a quicker recovery for affected communities.

Design for Disaster
Computer systems can often be fragile by their design – they are especially reliant upon power and communications. If any of these are lost during a disaster, the value of a system can quickly be lost if it has not been designed to operate in adverse environments. Here are some design decisions that are very important for disaster applications:

• Low bandwidth – we’ve all become accustomed to sucking bandwidth through massive broadband pipes, but during a disaster network connectivity for emergency managers may be limited to dialup speeds over satellite or digital radio connections. Disaster software needs to be designed for very efficient transfer of information, and should never assume vast quantities of bandwidth are available. At at extreme, some information may even be transferred by SMS or USB memory stick.
• Intermittent connectivity – during a disaster communications will likely fail multiple times before they are finally restored. This means that most ‘software as a service’ or web applications on the Internet will be of little use to emergency managers. Disaster software needs to be stored and run locally, and be able to work without a connection to the Internet.
• Synchronisation – one of the best techniques for designing around low bandwidth and intermittent connectivity, is to design a system to be able to synchronise information between two systems when communications are available. When communications later fail, both systems will have a copy of the same data, and can access it locally until communications are restored.
• Low power – power can, and will fail during a disaster, so disaster software needs to be designed to run on low power devices. Laptops and notebooks are good targets as they are self-contained, have built-in batteries, and can be charged from solar cells or generators. Large, power hungry servers can be difficult to move and support in a disaster environment.

How I became involved

One might ask how a Kiwi became involved in Sahana. Ever since training as a Civil Defence volunteer in the late 90′s, I had an interest in how information technology could be used to improve disaster management. The tsunami in 2004 acted as the catalyst for Sri Lankan computer programmers to produce Sahana. I have been volunteering with the project since 2005. In September 2005, he helped facilitate a workshop in Colombo that formed the basis for the current version of Sahana. In March this year he attended a Sahana conference and Board meeting in Sri Lanka. At the Board meeting the existing ‘owner’ of Sahana – the Lanka Software Foundation – agreed to hand the project over to the open source community. Gavin is a member of the transition Board that is in the process of forming an international non-profit foundation that can accept financial donations, and act as the ‘custodian’ of Sahana.

How you can help

There are numerous ways Sahana is looking for help. Once registered, we will be able to accept financial donations that will be used to fund development. In the meantime, we are looking for open source programmers with web development skills (including mapping). If you’re not a programmer, we are always looking for translators that can convert the english text and documentation into many different languages. Perhaps most importantly, we are looking for experienced emergency managers to help provide design advice to the Sahana community and guide the developers.