Data and Info Sharing with No Power or Internet? - Meet LDLN

There is an organization that I have wanted to introduce people to for a while.  It is a game changer, provided it can be applied more and baked into operations and various technologies. 

In disaster operations, the Internet is the predominate way to share data and information across people, organizations, and geographies--when it is available.  It is a critical failure point to inter-organizational and region-wide operations that need to share across wireless networks.  When access to the Internet is compromised, cascading effects occur such as having to reconcile what the latest data and information is. In fact, data and information sharing is often reduced to files on USB sticks that are physically traded.  Version control becomes essential, but hard to maintain.

LDLN

LDLN (pronounced "landline") is a robust open source mesh network that goes beyond network reliability issues for connecting to the Internet.  LDLN combines the best of sync technology to enable data and information sharing with or without Internet across networks, organizations and geographic areas.  Most importantly, this is all done without duplicating content or complicating reconciliation efforts.  Simply said, it is designed to just work without the need for constant management and oversight.  Pretty cool, huh?  

Normally, I would limit conversation of this type of technology to the techies among us who work to maintain network operations.  But I believe everyone should be aware of its existence and capabilities to inform strategic and operational thinking before and during disasters. There are two key components to LDLN's potential success, it's software and it's hardware.  These two aspects are are discussed below in the Q&A with LDLN's founders.  

This technology is not a far cry from Ushahidi's BRCK, which is a small all-in-one portable router (wired and wireless), server, and multi-modal Internet connection device with a long-lasting battery back-up.  However, BRCK's focus is on single-point data and information exchange while LDLN allows the carrying of data and information on any device to another access point, which then automatically shares the most current data and information with all devices connected to the new access point.    

BRCK and LDLN are complementary technologies that enhance each other's value proposition.  LDLN could potentially be implemented on BRCK as well as any other hardware such as existing servers and routers.  The hardware, though, does not need to be limited to the RaspberryPi devices mentioned below.  While these possibilities are not yet in LDLN's current product, they could be a next step for them.  

I am glad LDLN was able to respond to my Q&A request.  Check out the entire Q&A below, which includes pictures of LDLN's software.  

LDLN Question & Answer

What is your name and role in the product/solution/company? 

• Matt Grasser - CEO
• Emily Duong - CCO
• Sam Krueckeberg - Engineering Lead
• Arthur Chen - Chief Legal Counsel
• Joyce De Vera - Head of Marketing
• Nick Ihm - CTO
• Christopher Guess - COO
• Kristine Austria Sanchez - Designer

What does LDLN do?

LDLN is a communications system for disaster relief organizations when there is no power, internet or wireless connectivity. LDLN allows organizations currently reliant on notebooks and pencils to have a fully synced, fully backed up, reliable communications system over any size of operation theater.

What/who inspired you to create LDLN?

We were inspired by our team members’ experiences across the world. Chris first conceived of the idea while working with Occupy Sandy during the Hurricane Sandy response, and suggested it up as an idea at a Philippines resilience hackathon. From there the team pooled ideas and skills to create a system responders would want to, and easily be able to use in the field with minimal training.

What challenge does LDLN help users overcome?

When a disaster relief organization deploys to the field in 2015, they are for the most part still equipped with the same tools that were available in 1991. Every major tool and recovery method used today currently relies on two things that are, to put it mildly, in short supply: electricity and internet connectivity. In absence of connectivity, relief workers fall back to the stalwarts of pads of paper and pencils.

In short, we provide the software and hardware necessary to form a modern backbone for communications and document synchronization. This resilient, decentralized, "designed-for-disasters" network does not depend on cellular technology, Internet connectivity, satellite up-links, or even an external power grid where others would.

How does it do this?

The LDLN Base Station, a tiny computer about the size of a deck of cards, combines the networking features of a traditional decentralized mesh network node with the reliability and storage capabilities of a traditional web server.  Standing in stark contrast to expensive, bulky, custom-built satellite trucks and enterprise solutions, the Base Station is inexpensive, extremely portable, and consists of open hardware.

Building on this network of Base Stations, mobile apps powered by LDLN's SDK afford the familiar interfaces of a modern mobile experience, using of peer-to-peer protocols to skirt the need for a centralized network. Apps and Base Stations work in harmony to push and pull pieces of encrypted data across the network, ultimately displaying information in a natural and easy-to-read format.

What is next for LDLN?

LDLN is very proud to be have accepted into The GovLab Academy Coaching Program at New York University for the spring of 2015. We are looking forward to engaging with thought leaders and experts in the fields of disaster relief and government action.

In parallel, LDLN is currently developing our second generation of base station and mobile technology. This will allow in-the-field customization of the data collected and reported along with massive speed improvements on the base station side.

How can people get in touch, learn more or test LDLN?

Anyone interested can get in touch with our team through our website or social media, or via email.

• Website: http://www.ldln.co
• Facebook: https://www.facebook.com/ldln.co
• Twitter: https://twitter.com/landlineph
• Email: info@ldln.co

Since our software is open source you can also take a look at the code at our Github site: https://github.com/LDLN/

Innovation at the Sahana Software Foundation: Interview with Mark Prutsalis

Today, I had the pleasure of interviewing Mark Prutsalis from the Sahana Software Foundation.  We spoke for a while on the history and vision for Sahana, a non-profit organization developing open source software for disaster management and humanitarian needs.  In recent years, it has had a lot of success and is poised to continue. Some highlights from the audio below:

• Sahana was built by a local technology group in the aftermath if the Indian Ocean Tsunami in 2004.
• In 2009, the local technology group discovered they had a different mission and Mark took it over as part of the Sahana Software Foundation.
• New York City, Los Angeles, and International Red Cross all use Sahana software.
• Current software version is "hard to use out of the box" and development focus right now is on project requirements.
• There are plans to become more strategic and shift to an "expert system" that is easier to implement and has features based on best practices, not just customer requirements.  Hosted solutions and less technical and operational customization will be required in the future.
• However, Sahana is trying to build solutions that don't yet exist in the market.
• The ability to scale operations with hundreds of thousands of people and sites is a priority for Sahana to better enable real-time planning and management.
• Haiti earthquake in 2010 was a "watershed moment" for Sahana where it was able to crowdsource and geo-locate almost all 150-160 hospitals in Haiti within 24 hours.  Only two couldn't be geo-located.  Sahana, in partnership with OpenStreetMap, used geo-rectification to confirm crowdsourced locations.

Check out the audio for the complete 15 minute interview!  (sorry for the initial background noise, but audio is still clear)

[soundcloud url="http://api.soundcloud.com/tracks/82283668" params="" width=" 100%" height="166" iframe="true" /]

Market Driven Technology Innovation in Emergency Management

I recently attended a great demo by a new emergency management technology called Veoci.  This has great potential.  I even sent this along to my friend who works emergency management at a major airline. But as I look at the market for technical solutions and compare it against the problems of emergency management (and business continuity), which is increasingly cost-conscious, I realize there is a great divide between what is out there and what is needed such as feature mix, usability and scalability.  This post focuses on the innovative entrepreneur who wants to help the "disaster" solutions market go beyond its current technical limitations, provide a great service to its customers, and realize success.

Features and Specialization.  Any successful entrepreneur will tell you that product specialization is a key element of growth strategy and innovation.  After all, it is very hard to pinpoint precise problems and actually develop innovative solutions, even more so when the solution tries to do everything.  The more a company can continually test and improve, the more likely it is to solve customer problems beyond expectations.   But the problem is, where should companies specialize and how should they approach it?  This requires integrated innovation.

Usability, Scalability and The Fallacy of the "One" Solution.  In the past, many providers, especially at the enterprise level, have included feature rich solutions at the expense of usability and scalability.   In fact, emergency management is so dynamic and interdependent that one solution is simply not practical.  As a result, this model has proven tiresome, costly, and ineffective for our most important needs...collaboration, coordination, and management.  Additionally, and most importantly, it is not reflective of what is really needed, integrated innovation.

Integrated Innovation

So what exactly do I mean by Integrated Innovation?  I am defining this as the ability of companies to innovate through specialization, but better serve customers through integration.  Understanding this concept is most important to getting better market-driven solutions.  Here is what it entails:

1. Focus on a niche - Select a very particular problem that you want to solve.  This is includes management and coordination, resource management, financial management, mass communications, and health and medical, etc.  Look at the many Emergency Support Functions to identify functional areas and explore them from tactical through strategic priorities and users.   Be the best at one really important thing.
2. Build with integration in mind - If I only focus on one thing, what is the value-add?  Integration. Period.  Building your system with enough flexibility that customers can easily connect other systems that compliment your  product will enable customers to build a cost-effective and efficient ecosystem customized to their needs.  Should this integration be in the form of APIs, standards, a marketplace, user provisioning, or single sign-on?  The jury is still out, but the market will help drive this decision.  Just be prepared and begin forming technical alliances among other solutions so your customers don't feel like they are getting proprietary solutions that require customization after customization.  Start with similar size solutions to yours and look at how Facebook, Google, LinkedIn and other social media solutions have built with integration in mind.  If fact, there is a now a secondary market of social media management and analytic tools (another market for emergency management)?
3. Growth - Growth ties all this together.  In fact, that is why companies start in the first place.  They want to grow to a point where they have significant market share to realize profits and investor value.  But how should this occur?  It is highly unlikely that with a market full of solution providers, many will sustain themselves in the long-term.   The market is only so big.  However, that should not prevent anyone from developing a solution they believe in.  Solution providers should understand ALL their exit strategies and still feel successful whether they are bought-out or merged with another solution.   Either way, you have contributed meaningful innovation to the market, something that is sorely needed.

This post is my message to all solution providers and has a few more implications.  Help change outdated the procurement cycle and help drive innovation through your approach to development and growth.  The end result will be meaningful solutions that make your customers happy, not just "satisfied" with a solution that has too many features, is hard to train on, and does not reflect the emerging collaborative and interdependent landscape.  And regardless of your approach, user-centered design and frequent user testing should be a part of your solution.  Consider design thinking and agile development in your approach.