I had the opportunity to present Sahana to the CrisisCamp Ignite session on June 12, 2009. The presentation, with narration, can be found on my slideshare site. Download the entire powerpoint show rather than viewing it through slideshare to hear the voiceover.

About Crisis Camp: “CrisisCamp DC started with one idea: How can technology help people around the world during times and places of crisis? CrisisCamp DC is part of a global movement who is bringing together volunteers, academia, non-profits, companies and government officials to share best practices and lessons learned to advocate for further use of technology and telecommunications to assist citizens and communities during crisis.”

Sahana definitely has a large role to play in follow-up from Crisis Camp.

There are major opportunities and major object lessons for Sahana that came out of the weekend. The first is that there was a consensus that “Good tools do not require training; If you to train people on it, it’s not good enough.” Those interested in improving the user experience and front-end of Sahana take note; this should be a priority for post 1.0 development.

A second relates to the abundance of excellent new tools available - especially in GIS - and Sahana should not be competing with these systems, but integrating with them. Packaging Sahana with Open Street Map can provide a total downloadable open-source solution, but we should not abandon potential commercial partnerships – such as with ESRI, which offers a free viewer and sells a single server license for an affordable price for most organizations and jurisdictions.  Also take a look at Ushahidi and FrontlineSMS.

A number of potential opportunities were discussed to exercise, test, simulate disasters to road test tools, and especially interoperability, including a “hack-i-stan” exercise for such a purpose to discover requirements and task developers to come up with solutions. Sahana should also be an active participant in such an endeavor.

You can follow Crisis Camp activities in a number of ways. Twitter: @crisiscamp or search hashtag #crisiscamp; a ning site and a wiki have already been set up for follow-up activities.  Sign up and get involved.

“Please welcome CipCip (pronounce “TJEEP-TJEEP”, Italian for Twitter) to the DELIVER family”

So how does this differ from Twitter? This statement sheds some light:

“CipCip, is like Twitter, but internal to our organisation. Access is restricted, and new users are added by invite-only at this time.”

And it focuses solely on humanitarian relief messages etc. Restricts the message getting out to the masses, like what Twitter does, and rather makes sure the message stays within the organization - seems to be Twitter with user permissions. And it is being used, according to WFP:

“Already we have had our first user ‘Ciping’ from Maputo, Mozambique. We have live streamed meetings so that we could remain working our desks while one of our team ‘Cip’d’ updates.“

Yet another innovation for the humanitarian domain.

Suggested categories:

• Best Project
• Best Project for Developers
• Best Project for Government
• Best Project for Academia
• Most likely to change the way you do everything

Please click on the image above to nominate or follow this link.

Sometimes the best things in life are still free, and good news can come from surprising sources. On Tuesday, Rick DeLotto and I were briefed by the Sahana Project, an award winning, free and open source, web-based disaster relief management system designed to “Help alleviate human suffering and help save lives through the efficient use of IT during a disaster”. It was first developed by the open source community, and is maintained by volunteers, with support from IBM, Google, NSF and Sida. You should run right over to Sahana and get a look at it, tell your friends, and spread the word. It might be just what your home town needs to keep YOU safe.

It is my pleasure to announce the students who will be participating in this years Google Summer of Code for Sahana.  We received 45 applicants from eight different countries this year for only 10 spots. I would like to personally congratulate both those who we are able to bring into the GSoC program as well as all the other applicants as the field of candidates was truly outstanding.  We look forward to working with these students throughout the summer and hope to form relationships that last for years to come for Sahana and the Humanitarian ICT communities.  We thank all the students who have applied for this program and apologize that we were only able to accept such a limited number.

The following students have been accepted for this years program:
Kethees Selladurai
Ajay Kumar
Khushbu Mohta
Praneeth Bodduluri
Gihan Chamara
Hasanat Kazmi
Shree Kent Bohra
Nithin Dara
Iroshan Horathalge
Akshit Sharma

Descriptions of these projects can be found at http://socghop.appspot.com/org/home/google/gsoc2009/sahana.

Thank you,

David Bitner
Sahana PMC
Sahana Google Summer of Code Administrator

Before jetting off the Colombo this weekend for the first annual Sahana software for disaster management conference, I want to provide an update on the input and ideas collected for the Sahana 1.0 release. I am personally a bit behind schedule myself on managing this, and for that I apologize.

However, I would like as much as possible to try to keep to the schedule I posted on the wiki which allows through the end of April to make a technical and strategic plan for what’s going into the release and what’s not. So, I would welcome any additional suggestions and thoughts as to what should be included in the 1.0 release. Please continue to send them in to the sahana-user or sahana-maindev mailing lists. I have a feeling some other ideas and discussions on this may take place in Colombo next week, so I will keep the list open through next week. This is definitely on my personal agenda to discuss at the BarCamp.

Anyway, here’s the list of ideas – most are new and some are adjustments to others already noted in some form on the wiki already:

- Merging of bug-fixes and enhancements from China / Sichuan deployment (for 1.0)

- Staff deployment and other enhancements from NYC deployment (for 1.1+)

- Make an RC branch off of trunk past 0.6.2.2 branch to capture many enhancements made for the 1.0 release – let release team work on it to capture bug fixes for trunk from other branches.

- Review list of bug fixes required for proposed 1.0 branch and trunk, and update tracker accordingly, such that experimental development can continue towards features planned for 1.1+ releases (currently noted as 0.7 and 0.8 on the wiki – plus GSOC 2009 projects).

- Windows and other supported OS installers to include as much auto configuration as possible and easy to follow prompts where user input is needed to set-up Sahana

- Document the installation package creation process on the wiki such that future release teams can follow it.

- Complete third party library review

- include the LGPL license text in the base directory of the package

I think that was it. Let me know if you think I missed anything; and please do feel free to send additional suggestions through next week.

A full timeline of important dates for this summer is available.

We were selected as 1 of 150 out of about 400 groups who applied this year.  This is a strong testament to the reputation that Sahana has built up of the last few years and the great success that we have had as part of this program previously.  We still do not know how many students we will be able to involve this year, but it may likely be fewer than we have had in the past as there are fewer spots to go around.  Further information about student allocation can be found here: http://socghop.appspot.com/document/show/program/google/gsoc2009/studentallocations.

Students:
If you are a student who is interested in participating in the GSoC this year, I would encourage you to review our ideas page and our student guidelines on the Sahana Wiki.  Once you have reviewed that information, I would invite you to discuss any ideas that you may have on the Sahana maindev mailing list or via IRC .  Students who take the opportunity to discuss their ideas with the Sahana development team will definitely have an easier time pulling together quality proposals.

The conference is aptly named SAHANA, meaning Relief in Sinhala, an official language of Sri Lanka, and is named after the SAHANA Disaster Management System, which was created as a Free/Open Source software solution in response to the 2004 South Asian Tsunami.

Conference Site
Agenda

The background for it came from the realisation that there are a significant number of organisations in New Zealand that are responsible for the publication of alerts - whether to a secure group, or the general public. For example, there are 16 CDEMG Groups, 70 odd local authorities, GeoNet, MetService, Police and those responsible for infrastructure such as roads, and the Centre for Critical Infrastructure Protection.

Each of these agencies would need some means of hosting a CAP server, and incorporating some means of resilience into their CAP server(s). Given that there are potentially such a large number of CAP servers required, there are some aspects that could provide a strong and robust CAP network without seeing a proliferation of potentially fragile CAP servers. This is all built on the concept of a secure peer-to-peer network of CAP servers.

Federation
It should be possible to federate a group of CAP servers into a cluster. If we take a CDEM Group as an example, the group members may elect to deploy say 4 or 5 CAP servers to create a peer-to-peer network providing CAP alert hosting for the CDEM Group. Any authorised CAP message posted to one of the federated CAP servers would automatically distributed the CAP message to the other CAP servers in the federation. In this manner, the CAP message is instantly distributed and made available to other servers in the federation.

Peer-to-peer
I believe that the more robust approach to developing a CAP network is to base it upon peer-to-peer network technology, although tweaked to provide a secure means of publishing messages to the network These servers could of course be deployed any way to provide maximum resilience, and may be located close to major New Zealand Internet backbones, and quite possibly well outside of their geographic region. This has two potential benefits for resilience. Firstly, the message is available from multiple servers, so that the load (particularly for publicly accessible CAP servers) can be distributed across the multiple servers automatically. Secondly, should any particular server fail, the messages will still automatically be provided from the other CAP servers in the federation.

One example means by which this could be deployed is the following.

Provide a national CAP server network of federated CAP servers at key points - a nationally managed set of strategically located CAP servers. For example, Government internal CAP servers would be most likely located on the Government Shared Network (GSN) or whatever comes out of the recent restructure of this service. Public servers may be spread around both by geography and ISP (e.g. key ISPs may host a CAP server for their customers). In all circumstances these would fallback to other CAP servers in the federation in case of their failure.

Naturally, the open approach applied to peer-to-peer file sharing is not appropriate for a trusted network CAP service. To create a more secure network, something like a two-tier approach may be necessary.

CAP Publishing Servers
Private CAP publishing servers may be utilised to act as the publishing gateway to the public read-only peer-to-peer network provided by the CAP Read-only servers. Authentication, encryption and/or digital signing should be used as the basis to authorise the publication of a CAP message via the publishing server. The publishing server is responsible for verifying the digitally signed CAP alert, as well as the authentication details to verify the user is authorised to post the alert. Once authorised, the CAP publishing server publishes the alert to the road-only servers. This is the only channel to publishing CAP alerts to the network. Some form of CAP writing software (or service) may be useful for creating CAP messages and then publishing them to the servers. One protocol that may be useful for publishing is Atom as suggested by this IBM article.

CAP Read-only Servers
These are the user-facing servers that provide CAP messages to their end users. Only the CAP publishing servers are authorised to publish CAP messages to the peer-to-peer network for dissemination.

Naturally, this concept is part of a larger plan to build a CAP framework, and the circle would be able to be partly completed by designing web browser plugins that are capable of connecting to the peer-to-peer CAP read-only servers.

Widespread deployment of CAP browser plugins may mean that traditional servers may not be capable of supporting tens or hundreds of thousands of CAP clients regularly checking for new alerts. A peer-to-peer approach will probably provide the most scaleable and robust approach to disseminating CAP alerts via the Internet.

Originally posted on my blog, republished to TalkSahana.