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.

• Person Registry for Sahana
• Warehouse Management
• Disaster Victim Identification
• J2ME clients for form data collection in the field
• Optical Character Recognition for scanning forms
• Peer to peer synchronisation of Sahana servers
• CAP Aggregation and Firefox CAP plugin
• CAP Editing and Publishing
• Mashup/Aggregation Dashboard
• Theme Manager

Having been neck deep in the process; working with others to set up our assessment process, coming up with ideas (I’m stoked to have two students working on CAP ideas that came out of my earlier suggestion), and reviewing each and every of the 45 proposals we recieved, it has been exciting to get so many projects accepted.

I think that by the end of the year, we are going to have some great new functionality available in Sahana. Even more, I hope we’ll attract more open source developers to our ever growing community!

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.

The Concept

Last year, I was involved in a project in New Zealand to produce an investigative report on Public Alerting Systems with the New Zealand Centre for Advanced Engineering. This report will hopefully soon go public, and I’ll provide a link when it does.

This report was looking at the different technological solutions for getting alerts out to people in as timely a manner as possible. At one point in the search for different systems, we started discussing means of injecting HTML in web pages via an ISP, so that a public alert could be sent out to anyone on the Internet. I’ll talk about this and other options later. Let me get to the point of this post.

After starting at the HTML injection idea, and progressing through a few others, I reached a kind of natural conclusion that a more suitable means of alerting users via a web browser would be a browser plugin that can subscribe to Common Alerting Protocol (CAP) feeds, and when a relevant alert comes in via CAP, this is displayed to the user in their browser using the XUL:notificationbox at the top of the webpage.

Draft Requirements

Anyway, a possible idea for a Google Summer of Code 2009 project is that of constructing a browser plugin for Firefox that implements this alerting capability, and expanding Sahana to support full publishing of CAP alerts. Here are some features it could/should support.

Firefox Plugin

• Bundle publicly available CAP feeds (ideally listed in a nice Country/State taxonomy – this will make it easy to discover and utilise existing CAP services.
• Allow users to optionally register location in some manner, so as the plugin can identify relevant alerts (by location) and give them higher status than say remote alerts. Users should be able to register multiple locations – whether it has home & work, or multiple cities. Privacy is of course king and this information must be protected.
• Provide a means of adding additional user provided CAP feeds to the plugin.
• Provide the ability to open the alert in a new tab and format in a human-readable manner, including niceties such as embedding Google Maps to show geospatial information and links back to the source website of the alert for verification.
• Implement means of verifying messages that are digital signed, and decrypting encrypted messages.

Sahana

• Implement a CAP feed in Sahana so that Sahana can act as both a producer (in terms of creating a CAP message) and a publisher (in terms of making it available via a CAP RSS/Atom feed).
• Implement a CAP proxy or similar, so that say all users of a Sahana server can obtain CAP alerts directly from the Sahana server – rather than going to an external website. This may be useful for distribution of alerts within an organisation or centre without having every client browser connecting to an external server.

What would be very nice, but may be beyond the capabilities of Sahana servers currently, is making the CAP service on a Sahana server easily discoverable on a LAN via zero-conf services such as Bonjour.

Draft Outcomes for Assessment

The outcome of such a project would be to produce a working solution whereby a Firefox Browser plugin is capable of working with public CAP alerts and that CAP within Sahana is capable of fully acting as a CAP server via RSS/Atom feeds to the CAP alerting plugin.

Compulsory

• Implement the specified requirements
• The browser plugin works as expected with publicly available CAP feeds.
• The browser plugin works as expected against the Sahana demo server. (Yes, this means that your modifications to CAP on SahanaPHP need to be implemented).

Optional

• Implement the Sahana CAP server in SahanaPY
• Provide one or more standalone CAP clients for a mobile platform e.g. Google Android, Apple iPhone/iPod Touch etc
• Write an Internet Explorer plugin with similar functionality – it is important that this functionality is also provided for IE given its widespread usage and deployment.

Whilst the plug-in can and should operate completely independently of Sahana, it should also be designed to work well with Sahana servers (e.g. SahanaPHP and SahanaPY).

Anyway, this is just an idea I wanted to float and get out in the community for discussion. I’d welcome any further comment or ideas to build upon this!

This award recognises an outstanding project to develop open source software. The project must be either based in New Zealand or have substantial contribution from New Zealanders living here or overseas.

For those that aren’t aware, the Open GPS Maps Project started a number of years ago out of a desire to produce freely available maps for Garmin GPS receivers, and it has grown to be a fairly significant project supported by a wide community of users and ‘regional mappers’. Graeme Williams has done a fantastic job in growing and maintaining this project, and it has been very well received by members of the NZ Recreational GPS Society of which I’m the current President. Many of our members are active contributors to the project. Back in the early days of the project, I produced the original ocean to give the map a more realistic look.

This is fantastic recognition for the tens and hundreds of people that have, and continue to, contribute to this project.

Another parallel project that has been gaining momentum, and has been working with the Open GPS Map Project is Zenbu. Zenbu is Japanese for ‘everything’, and has been producing a community driven directory service, including georeferenced service stations, ATM’s, where I can find curries etc. The symbiotic relationship between these two projects is really starting to come to the fore now that Zenbu’s point-of-interest database is being distributed with the Open GPS maps. Zenbu was also a finalist in the NZ Open Source Awards for Open Source Use in Business.

It is really exciting to see these open and collaborative projects gaining such recognition and momentum.

The rapid growth of the Internet and World Wide Web has spawned the creation of new and potentially useful software applications that may provide benefits to emergency managers. One of these applications that is currently drawing attention is the wiki.

Wiki is the Hawaiian word meaning to hurry, hasten; quick, fast, swift. Wiki software therefore refers to packages that are designed to make it quick and easy to create and modify collaborative web pages on the Internet. They have actually become more powerful and advanced than just for the creation of web content – wikis now power some very content-rich websites including the open source Wikipedia – the open encyclopaedia.

What are some of the key characteristics of a wiki?

• server-based software
• free, with few licensing restrictions
• accessible from any web browser
• can be run on a standalone laptop
• uses html links to reference other pages in the database
• designed for collaboration and sharing
• records all revisions of documents and tracks changes made by users
• immediately highlights recent page changes and by whom

What opportunities exist for wikis in the emergency management domain?

Wiki software has much potential to be used as a collaborative planning tool – whether planning occurs within or between organisations. Rather than passing a word processing document around via email to all participants in the planning process, the plan could instead be created and maintained using a wiki. A secured web site would provide an excellent home where plan developers could log in to check the latest changes and make modifications. The one key benefit over using a document-based approach is that everyone is always guaranteed to be reading and editing the latest version of the plan.

As certain milestones are reached in plan development, it is possible to lock the wiki, and create a ‘snapshot’ of the current plan before continuing the review and development process. Conceptually, this model of development is quite similar to techniques used for managing the development of computer software – with developers sharing a central repository.

In addition to planning, a wiki can also be used as a knowledgebase to store information and references to other documents. For example, certain pages in a wiki could be ‘tagged’ with a pandemic tag. Then, by viewing the pandemic category, it will show all pages that are tagged with pandemic. This provides quick and easy access to relevant information.

The benefits of wikis do not end when response starts. Conceptually, wikis can be installed on laptops or PDA’s enabling responders to have an entire knowledgebase available on a PDA including all the links and available plans.

Wikis could be used on a set of wireless laptops as a tool to assist your incident management system of choice. For example, the response plan developed in the EOC could be created in a wiki, and then planning/intel, operations, logistics, finance, information could collaborate on the one document with each section being able to view the other sections.

Wikis are also starting to be used in response and recovery by those people that have access to power and communications. Probably the best recent example is the Katrina Help Info wiki that is used to consolidate response and recovery information following a disaster – in effect creating a portal for the event with links to other agencies websites. In this manner, a wiki could be used as a public information system where key infrastructure is available.

Another example is the Hurricane Katrina web page on Wikipedia which started as a collaborative effort to record open source situation information. In the case of the Flu Wiki, wikis are even being used to develop a community knowledgebase about a hazard before the event.

It is important to note at this point that public wikis with permissive access controls can have issues with the quality and authenticity of information provided. Restriction of editing rights to approved and trained personnel can ensure that quality of information contained in the wiki is not threatened.

The next likely development is going to be the consolidation of wikis and community mapping projects such as the Hurricane Information Maps that were developed following Hurricane Katrina and utilise Google Maps. The combination of information contained in a wiki linked to spatial references and presented on a map will provide a very powerful information resource for response and recovery.

In February 2004, I wrote an article for the IAEM Bulletin outlining some of the benefits that open source software had the potential to provide for emergency managers. At that time, little open source software existed for emergency management, and I had just come out of a simple attempt in 2003 to create a Web-based disaster management system. That effort failed, for while there was a well-recognized need for open source disaster management software, there were no real drivers to encourage development of a solution.

2004 Tsunami Spurs Development of Sahana

The driver came with the tsunami that struck Sri Lanka on Dec. 26, 2004, which prompted the development of a free and open source solution called Sahana. Within a couple of days, the need for a system to manage vast quantities of information became obvious, along with the need to attempt to coordinate 1,300 NGOs responding to hundreds of thousands of displaced people. In the following days and weeks, a Web-based system for managing disaster information was built on-the-fly based on the most pressing needs. Accordingly, the following were the first modules developed:

• People Registry – track and match victims of a disaster.
• Organization Registry – register, connect and track NGOs involved in response.
• Camp Management System – register and track camps.
• Request/Assistance Management System – record, track and match requests and offers of assistance.

Sahana development was initially led by the Lanka Software Foundation and supported by volunteers from the Sri Lankan IT industry. As the immediate need for Sahana subsided in the months following the tsunami, more international contributors became involved in the project, myself included. These ranged from programmers wanting to help out, to those who wanted to offer assistance drawing upon their disaster experiences, including emergency managers.The positive feedback to Sahana prompted further development to add more response and recovery capabilities applicable to any disaster management situation.Longer-term, the goal is to use Sahana as a means of encouraging comprehensive emergency management in communities by supporting preparation and mitigation. This will start by providing tools to incorporate plans and reference material, such as communication directories in advance and other techniques to encourage greater interagency co-ordination before an event.

Capabilites

Sahana has been designed to operate in a diverse range of environments due to the nature of disasters. It can run on Web servers and laptops, and has even been installed on a PDA. Over time, it will support both standalone and networked modes of operation and allow communication between multiple Sahana servers, including synchronization of data.There are a number of future modules planned or under development:

• Disaster Impact Assessment.
• Alerting.
• Inventory/Supply Chain/Logistics.
• Volunteer Coordination.
• Intelligence.
• Response/Rescue Team Management.

In addition, there are a number of key technologies identified for inclusion:

• Mapping/GIS, and GPS integration – it can already use Google Maps.
• Biometrics.
• Provision of information via open standards:
  • Common Alerting Protocol (OASIS/CAP).
  • Emergency Data Exchange Protocol (OASIS/EDXL).
  • Various OpenGIS Protocols (OpenGIS Consortium).
• Support of existing paperbased forms.
• PDA forms for remote fieldwork.

Deployment

Sahana has seen official deploy ments in multiple events, including the Sri Lankan response to the tsunami in 2004, the 2005 earth quake in Pakistan and the 2006 mudslide in the Philippines. It has also recently seen unofficial deployment in support of the Yogjakartra earthquake and in preparation for an eruption of Mt. Merapi. Sri Lanka’s largest NGO is also deploying Sahana within their disaster unit.

Recent Events

In mid-May 2006, a workshop was held in New York that brought together key members of the Sahana development community and IBM. The meeting served two purposes:

1. To discuss IBM support of the project, and
2. To consider further development of modules for Sahana that could be used during response to a pandemic.

A pandemic presents an interesting opportunity for the deployment of Web-based disaster management systems, as most infrastructure should be operating normally (relative to a hurricane or earthquake).The Sahana project is interested in contributions, be they time or financial. Time contributions can be made in providing design advice based upon disaster experience, writing the code, testing Sahana or helping to write the documentation. Financial contributions will be used to target module development, such as sponsoring development of a specific module or supporting the core development team that works full time. An international community maintains Sahana, and all contributions are provided back to that community at no cost – a share-and-share-alike ethos to ensure that everyone benefits. Sahana is free to use and has no licensing costs associated with it.

Links

• Sahana Web Site
• Sahana on Wikipedia
• Dr Sanjiva Weerawarana’s Blog, a record of initial Sahana deployment (entry1, entry2)

What is Open Source and what are the benefits to Emergency Managers?

The spread of the Internet has given life to what some may say is a radical change in which software is developed. Traditionally, software development has been driven by commercial vendors that provide you with a software package that cannot be directly modified to suit your organisations needs. Yes, you may be able to customise it with options and configuration settings, but if it doesn’t implement a function you need, there is usually little hope of getting it implemented. This is because you do not have access to the source code – the human readable code that tells the program how to operate. Open Source Software (OSS) changes all that.

What is Open Source Software? It is software that people can freely read, copy and modify the source code. This allows people to improve software, adapt it, and fix bugs. Additionally, this can often happen at a greater speed than conventional software development. But, the essential point with OSS is that you have the source code to the software, and the freedom to modify it, and redistribute your modifications.

The Internet has brought about the spread of Open Source Software because it provides a means of linking programmers and users around the world. The individuals come together on a project-by-project basis to develop software for a specific purpose.

So how can Emergency Managers benefit from Open Source Software?

Repair and Maintenance
Have you ever found a bug in your software, but you’ve had to wait until the vendor releases the next version of the software to fix it? Well, if you are using OSS, you can fix it yourself, or pay someone to fix it for you. Additionally, your fix then is released back to the community so all benefit from fixing the bug.

Licensing and Cost
Emergency Management Agencies often are not well funded, with some having to make do with whatever hardware and software comes their way. OSS provides an extremely cost-effective means of providing functionality. For example, if you receive Windows PC’s with no office software, you could download and install OpenOffice.org – a suite of office productivity software for free, and it is also compatible with Microsoft Office files. Other day-to-day software solutions are available, including web-based groupware servers. Of course you can install the software as many times as you like – consider how expensive that would be with commercial software?

Extendibility
If you want a specific function added to your open source EM software, you can always pay a programmer to implement it for you. The real benefit of OSS comes when these additions are feed back to the community at large, so the community as a whole benefits, and spreads the cost of development. It also gives you a chance to support a programmer in you town, rather than across the country or the other side of the world!

Flexibility
Once again, with the source code in hand, you can customise the application to allow for internal consistency with jargon in your organisation. By changing the terminology used within the application, you can reduce the training requirements, and maintain consistency with other applications.

Economies of Scale
There is the potential for pooling of resources to achieve economies of scale. One EMA may not be able to afford to develop an EM application. However, by working with others and pooling resources, it would be possible to come up with enough funds to provide full time jobs for people to work on OSS – specifically an EM application (or suite of applications).

Speed
And finally, because you have the source code, you are not tied into the commercial vendors release schedule. Want that feature? Need a bug squashed? You can pay someone to do it right now.

At this stage however, there is little Open Source Software specifically designed for Emergency Management. But that is about to change. Some of the base functionality is the same across most organisations – such as a contact directory, basic message handling etc. Rather than having to build all this functionality from scratch however, we can take an existing stable OSS project (e.g. egroupware) that has some functionality required for emergency management, such as groupware which provides contact directories, calendars, user authentication etc, and then develop and integrate specific emergency management functions, such as alerts, and message handling. This translates to months not years to get a useable product into development.

Links to Popular Open Source Software and Information Sites

• Mozilla Firefox – a very popular open source web browser
• OpenOffice.org – open source office software
• Open Source Initiative
• The OpenCD – a CD containly a wide range of open source software packaged on a CD
• MediaWiki
• eGroupWare – web-based collaboration software
• WordPress – the software that runs this website is also open source