A note on this blogs format - I will not hide my drafts until they are ready. All my writing will be displayed as soon as it's down in bits and bytes. Posts will be labeled Draft and Final according to my view on the topic.

Monday, October 27, 2008

InSTEDD Tracker


InSTEDD nails it with Tracker.

Tracker is a news and feed aggregator with a purpose. The site pulls in feeds which have a bearing on humanitarian relief.  InSTEDD's mission is focused in the realm of public health (pandemics) but they're smart about how they're approaching the problem.  The folks at InSTEDD have decided to fight pandemics by looking to destibilize the system that produces pandemic disease in human population. 

InSTEDD's particular focus at the current moment is capacity building in Cambodia and SouthEast Asia to boost reporting and tracking capability.  They believe that the best information and the quickest reporting stream is to be had from well educated people dispersed throughout the commmunity. The summary of their approach to disaster relief and public health is on this page at their site.  Their work, in their own words, is focused onbuilding "a better global immune system. We know we alone can't truly stop diseases, war, poverty, or climate change, but we think we can help humanity to learn about threats faster, and so respond quicker, and so soften the impact." (italics mine)

Tracker is designed to help humanity with that last bit, otherwise known as the important part. Unlike other news aggregators, Tracker doesn't categorize and segregate the different stories that are being pulled into the feed reader.  Stories about public health are right next to the newest software developments which are right next to the latest report from Human Rights Watch. 

"Tracker is an aggregator with a few twists. Links are not limited to breaking news, but include research papers, in-depth analyses, blog and vlog posts, podcasts, videos, websites and even book reviews. A story on a major earthquare might be grouped with an older but still relevant research paper on predicting aftershocks and fresh-from-the-field blog post about a new software application for mapping damage using a cell phone."

The goal of the site to set the stage for accidental interindustry cross polination of good ideas. Only when we can think faster and wider, when we can synthesize (meatier link here), disparate information, can we approach any useful planned activity in the disater world.

Tracker puts many of the pieces for a new snowmobile in one place - but are they the right pieces?

For now, I don't care. It's a step in the right direction and it's making the right philosophy a practical reality.

Saturday, October 25, 2008

Straw and camels

DRAFT (updated 11/9/08)

The straw that breaks the camel's back is a phrase uttered far too often in everyday conversation. It should never be uttered in (post) disaster situations. For the rest of the post, I'm going to refer to "the straw that breaks the camel's back" as the phrase

Why do I have such a strong reaction against the phrase?

Words matter. The words that are available to us both shape and limit the ideas that we are capable of expressing. Repeated use of the phrase pushes us, even if unwillingly, toward a certain simplistic mode of thinking.  This particular phrase lends itself to oversimplificiation and almost immediately to a case of the "if only's".  If only the nylon strap was better constructed. If only the levees had been better constructed. If only banks ability to leverage their assets had been better regulated.  If only <insert pet cause here> then <horrible disaster> would have been prevented.

But isn't the "straw that breaks the camel's back” describing the tipping point?

Well, yes, it is. But ask yourself how many people will take that into consideration when you use the phrase. Ask yourself: in your most fatigued state, do you always look for the linkages of causation within an event of are you looking for the immediate fire to put out? Or do you sometimes let yourself lapse into intellectual laziness and catch a case of the if only's?

Alternative thinking and disaster applications

Disasters occur every minute of every day. The reason you don't hear about them is the scale and the connectivity of the person affected by the disaster to your informational network.  The disasters that you do hear about are the foam on the crest of the wave.  There was a massive decentralized effort to get that story or wave to you in its exact form that was, to your eyes, completely behind the scenes. All you know is that the disaster showed up on the front page of the New York Times.

Disasters that you hear about are extraordinary events.  While the New York Fire Deparmtment recieved 490, 767 calls in 2007 it's likely you only noticed the few big or tragicincidents that were deemed newsworthy.  These are the events where numerous things go wrong in sequence and relation to each other to cascade onto the front page.

In the ideal world, we would learn everyday from our failings and incorporate those lessons into mitigation or response strategies. New York City's revised building code is a good example of this effort. The combined lessons learned from decades of international engineering successes and failures was distilled into codification.  This is not, however, the end of the story.

Disasters are unique in that there are never enough of them, at least on the catastrophic scale, to allow an easy synopsis of the lessons learned that are portable to other types of disasters. Finding portable lessons learned is the tough part here. Instead of learning about New Orleans if only's and the failure of the levees, we should be learning about the command and control problems ineherent in creating a diverse coalition of competing interests.  Instead of hearing about the Failure of Initiativeif only we should be hearing about ways to encourage an organizational capacity to pursue and nuture unnoficial information sources. We should be hearing about how to instigate and encourage and yes, catalyze, community based organizations who will fight government at every step for the good of the community itself. We should have heard more about how to reduce the operational friction that prevents healthy response across disasters.

What am I describing? I'm describing a world where the actors are distributed and completed by those with the organizational capacity to do so, at the level closest to the community and the end users. Preferably, the end users themselves should be organizing and responsible for their own recovery. I'm thinking of an organization where “decisions” per se are not made and handed down but where the individual actual actors make the choices and the reprocussions and reporting filters up. I'm imagining and organization that approaches the problem looking for linkages, relationships, and the potentialities for negative and positive feedback loops rather than for assignation of blame or credit. I want a collection of organizations that pursue the quickest means to follow their mission and help the widest range of people.

This ideal agency should not waste their organizational capital, budgets, or time pursuing the fix for the phrase. Fixing that one thing would only increase the likelihood of some other type of disaster.  I am not suggesting that agencies not fix what they are able to fix - I am suggesting that agencies acquire an awareness that their decisions are part of a web of decisions being made all the time which may have uninented consequences. 

A minor example - increasing the number of building inspections increases the likelihood of bribery and corruption.

Liveblogging transparency

In this blog I will often preach the value of transparency for individuals, companies, ngo's and government. I figure I should walk the walk as much as I write the talk. To this end, I will be liveblogging everything in this blog.  You will see the post layout, initial post outlines, thoughts, and the eventual final product.

This may be messy initial as I get the hang of it and can adjust my way of thinking through the topics.  I'm okay with that. I am no idiot savant. There will be failed ideas, posts, analogies, and misconceptions of other ideas. The best way for me to learn is to force my ideas to butt against those ideas and run my faulty ideas to ground as quickly as possible.

Viva l'experimentation!

Friday, October 24, 2008

Why people don't adopt FLOSS

I'm in a rush to finish a lot of things at work and am working on a longer post about incorporating systems analysis in emergency management so for now I'm going to quote a large portion of text from the Confused of Calcutta blog entitled "Learning about why people don't adopt open source". I think the post nails the problem on the head.

  1. They hate the principle. Such people are uncomfortable with the concept of opensource, they tend to get hung up with the free-as-in-gratis rather than the free-as-in-freedom, and they feel that somehow the very nature of their existence gets undermined by the use of opensource. It’s unAmerican, it’s McCarthyist, it’s even (hush your mouth) Communist. And don’t you know it’s already illegal in Alaska? Where will the world go to if everyone started using free things? Opensource users are stealing from the mouths of people who work hard everywhere. The very idea! These people are hard to convince, but when convinced experience Road-To-Damascus moments. Work on them, it will pay off.
  2. They believe it’s insecure. [Again, a wonderful feat of marketing, excellent management of the metaphors and anchors and frames around opensource.] Quite a common response. Code that everyone can use, that anyone can change, that no one owns? Open to inspection by all? How on earth could that possibly be secure? It’s all a plot to bring down the capitalist world as we know knew it. Solvable by education.
  3. They’re out of their comfort zone. This tends to be the response of steady-state professionals in IT departments in many organisations. If it works, why try and fix it? Why force yourself to take responsibility for the integration, deployment and support of something, when you can pay someone else to take care of it all? They’re risk-averse and responsibility-shy; understandable, defensible, this can often be solved by education.
  4. They know a better way. These are people who point to the end-to-end control that Apple/Microsoft has, and how that gives people more choice and a better experience. [Yes, I've always wanted to drive my car on railtracks, ensure that the wheels fit precisely on the tracks, and go by car only to the places the railway takes me. ?!?] Solvable by education.
  5. They don’t know about it. These people have been cocooned away so effectively that they aren’t even aware of the options they have. Totalitarian rule. Most probably they aren’t allowed to go on to that dangerous place, the internet, where they might see strange places and maybe even catch exotic diseases. If they do have connectivity, it’s locked down to a small number of cleared sites. Mozilla is definitely not one of them, and even Sun is banned. Solvable by education.
  6. They can’t do what they want with it. To me, this is one of the most understandable objections. They use something that’s proprietary, they’ve built a whole pile of things around the proprietary thing, and now they can’t function without it. It’s hard to replicate elsewhere or using anything else. It’s not just the applications, you have to think about the processes, the training, everything. I almost buy this. Almost. But all you need to do is imagine you are in a merger or takeover, and all this changes. There is an imperative to move, and all the excuses disappear. So while I have sympathy for this view, I am aware of how fragile it really is. The best way to solve this one is to simulate a merger or takeover involving a firm that does not use what you’re using.
  7. The move represents serious operational risk. Puh-leese. Find the remaining deckchairs on the Titanic, and get them on it. They will happily move them around until iceberg time.

Sunday, October 19, 2008

Spare cycles and the bailout

Chris Anderson at his Wired blog, The Long Tail, has a post up about titled "What recession means for free" I'm going to quote the post in whole because I think it's worth the read:

I get asked this all the time these days, so before I crash after a speaking tour of Latin America (eight cities in four days!), here are my thoughts on what a recession will mean for free-based business models.

First, let's confine this to online, which is where the most interesting free models are. There are three main forms of "real" free: Ad-supported, "Freemium", and the Gift Economy. Here how I think each will be affected:

  • Ad-supported: In the offline world, advertising is going to go down. Online, where it's easier to make the case for clear ROIs, I suspect advertising growth will continue to be positive, but will slow considerably. That means that many of the companies that were counting on a rising tide lifting their boats will be disappointed, and more than usual will go bust. Result: Negative
  • Freemium: This should become the favored model, since it's connected to direct revenues. But companies that have only worked out the free part but not the premium part are going to have to figure out what they can add to their products to make them compelling enough to pay for. If they don't, they will find their investors' patience with them is very limited, and many will fold. Those that get the freemium balance right should be fine: free is a good price to have when people don't want to spend, and freemium models can work well when just 5% of users convert to premium, thanks to the near-zero marginal costs of serving the other 95%. Result: Modest positive
  • Gift economy: This is driven primarily by people's "spare cycles" (AKA cognitive surplus) and rising unemployment means more spare cycles, sadly. Obviously people still need to pay the rent, so many of these shared contributions are really just advertisements for the contributor's skills. But other contributions will be idle hands finding work while they look for their next job. As a result I think you'll see a boom in creativity and sharing online as people take matters into their own hands. Today, if you're in-between jobs you can still be productive, and the reputational currency you earn may pay dividends in the form of a better job when the economy recovers. Result: Positive

Agree? Disagree? The comments are open."

If you're unfamiliar with the concept of spare cycles and cognitive surplus, I really do encourage clicking on the links in Chris' post. The second link, to Clay Shirky's post entitled "Gin, Television, and Social Surplus" has particular relevance to this blog.

What does this mean for New York City?
In the recent months the Wall Street housing bubble has collapsed with much of the blame resting on the intensely complicated IT financial modeling tools and the failure of their risk assessment models to quantify actual risk (a policy decision). All of those techies who created complicated risk assessment models may soon be out of a job.

We need to have a way to harness their excess cognitive surplus with a platform to accept their contributions and some ready made projects for them to immediately participate in. We also need to ask for their help. I wouldn't want to see their skills go to waste watching tv.

Cross-industry iterative implementation

David Armano at his Logic+Emotion blog created a great graphic about the iterative marketing process he's used for promoting himself and his company. The process focuses on a cycle of quick learning curves, intense bursts of prescheduled creativity, an assessment of successes and failures, and then a restart of the entire process once again. As the graphic suggests, this iterative cycle is more responsive than the traditional marketing pitch process.

Iterative/extreme/agile software development works on the same model and the graphic applies.

Social software development

For a couple months I've been toying with an idea to merge the community organizing and marketing power of electronic social networking to the FLOSS software development process. I've found that the easiest way to get the answer you are looking for is to ask the right question. There are currently too many real and imagined barriers preventing non-technical end users from asking the right questions. Increasing end-user knowledge of software tools across the board in general and allowing immediate involvement in the development of their tools in specific should increase the ability of the end user to ask the right questions to get the right answers.

Like I said, I've been kicking this idea of mixing non-tech and uber-tech around for a couple months now. Through the brain storm, I have asked for the thoughts and opinions of multiple people of both tech and non-tech persuasion. Both the non-tech and the tech has consistent responses.

First, from the non tech respondents: How do I sign up?

Non-technical end users have been lead around the nose with the promise of salvation by cool tech toys only to be disillusioned by the perversions of procurement, the fickleness of contractors, and eye-in-the-sky disinterested leadership. The people I talked with want to be involved in creating their toolbox but they have been put off by perceived lacks – time, tech knowledge, information about how to contribute, and no easy first step into contributing.

Underlying critique/problem/emotions(can be conflicting): desperation, despondency, frustration, technical ignorance, and passivity.

Now for the tech side: Why would we want to do that?

We've got a good thing going on and bringing in the ignorant masses, however well intentioned, will only slow us down. End users don't know anything about our work and they're just going to screw things up and make life difficult for everyone. Just let us figure out what you need, we'll make the code, install it, and teach you how to use it. Your opinions need not apply.

Paternalism and noblesse oblige– meet the digital age.

Underlying critique/problem/emotions (can be conflicting): insularity, complacency, mild case of the lazies, and worshipers at the alter of efficiency.

Middle ground
Where is the middle ground? On the one hand we need to convince the non-technical end user to reenter the fray. End users must be convinced that their contributions, thoughts, and advice are valuable. Successful (software) projects require the experience and participation of the people who will end up using the product. It may sound naive, but we need to grow some hope that tools may improve and meet the evolving needs of the user.

On the other side, we need to encourage technical minded people to wade into the messy gray areas of the end-user experience. Involvement consisting of a brief "requirements gathering" session will not yield the necessary results. Technical people have to understand the true need for a tool and understand the day to day ebb and flow that will color the use of the tool. Technical people need to get dirty and yes, gradually educate the non-technical.

Development models (thanks Wikipedia)

  1. Waterfall development

Waterfall development is the codified process for creating a product, any product, that strictly adheres to a preformed work plan. In Waterfall development, you cannot move on to the next step in the process without 100% completion of the previous step. Most often, if the requirements are not considered adjustable, many of the functions developed are not utilized by the end user. No matter how rigidly the Waterfall development model if followed, allowing any flexibility with the requirements introduces better functionality into the end product and puts you on the road towards iterative, extreme, and agile development.

  1. Iterative, extreme, and agile development

These three models of development focus on growing complexity and functionality rather than master-plan designing it. Many of the features of these individual development processes focus on incentivizing short bursts of productive work. Some of the most distinctive attributes include writing the tests before writing the code, releasing functionality early and often (buggy or not), allowing for goal posts to shift in between releases, and a willingness to make something work and then worry about making something pretty.

This may sound messy. It might be messy. This method has also been proven to produce more creative results and products. 37 Signals provides a great commercial example of extreme programming

So where can non-techies fit into the development cycle?

Waterfall development asks the end user to create the project requirements and then hand over all responsibility to the project technical lead. Iterative, extreme, and agile development moves too quickly to allow for such a neat division of labor.

The non-techie user can and should participate in any step in the design cycle. They can plug themselves in wherever they like because the development cycle is completely transparent, has low barriers to entry, and constantly requires the informed opinions of the end user. Without this input, the development cycle reveals itself as an unsustainable dissipative structure. End-user participation can come in the form of bug reporting, revising or creating documentation, user help and support, critiquing the graphical interface, requesting new features, testing recently released features, and yes eventually working on the coding should they feel up to the task.

How does one find a FLOSS project to work on?

The easiest way is to rely on the community. Ask people who use FOSS what they could suggest for your problem. If nothing else, they'll point you to someone who might be able to answer your question.

The other way to do it is to check some of the massive online project repositories. Sites like Sourceforge or Google Code are massive repositories of open source projects that are geared towards the developer who knows what project s/he wants to work on. But what if you have no idea what you're looking for?

Social Source Commons

Enter Social Source Commons. Social Source Commons is a web based social networking tool that lets you see what your friends, colleagues, and professional networking contacts are using for software. The site is not limited to FLOSS, so you get a complete picture of the range of options you might have to choose from. An additional unique feature of Social Source Commons is the ability to create and share a toolkit. A good example of a toolkit is the CiviCRM toolkit that packages together a suite of applications to help non-profits manage their constituent relations.

Once you find the software you're looking for, if it turns out to be a FLOSS project, the software description includes a link directly to the development community.

The code that makes up the Social Source Commons website is, itself, licensed as a FLOSS application. To make the application truly useful, the website needs a few more features including the ability message a friend, rank software on a standard scale (5 stars?), and let people suggest FLOSS alternatives to any proprietary software that is suggested/listed on the site.

Altogether, Social Source Commons provides software usage transparency, an open method for comparison and software research based on trust, links directly into the development community for non-technical end users, and the ability to modify the site itself to anyone passionate about the project and idea. End-users and techies both should use the site. End-users to discover new software and find the communities to support it; techies to find users and better understand the way the tools are used.

Social Source Commons just might be the necessary middle ground.

Thursday, October 16, 2008


We've been on a bender of sole-source proprietary software procurement. And because the tools dictate the way we work, we have also been on a kind of sole-source mindset bender.

Never fear, there is hope and a 12 step process.

Sole-source-anonymous 12-Step Program
  1. We admitted we were powerless over software procurement from on high—that our lives had become unmanageable.
  2. Came to believe that a Power greater than ourselves could restore us to sanity.
  3. Made a decision to turn our will and our lives over to the care of communal development as we understood it.
  4. Made a searching and fearless inventory of our toolkit.
  5. Admitted to the community, to ourselves, and to another human being the exact nature of our wrongs
  6. Were entirely ready to have transparent and interactive development and procurement remove all these defects of character
  7. Humbly asked everyone to reveal and help remove our shortcomings.
  8. Made a list of all persons we had harmed, and became willing to make amends to them all.
  9. Made direct amends to such people wherever possible, except when to do so would injure them or others.
  10. Continued to take personal inventory and when we were wrong promptly admitted it.
  11. Sought through constant interaction and conscious infusion of diverse opinion to improve our conscious contact with the community as we understood it, hoping only for knowledge of their will and the power to carry that out
  12. Having had a communal awakening as the result of these steps, we tried to carry this message to sole-source addicts, and to practice these principles in all our affairs.
Hugging is optional.

(If I offend, say so in the comments - it was not my intent to mock the 12-step program for AA but only for demonstrative purposes)

Remote control

For everyone well versed in FLOSS and/or tech implementation and use - this post is not for you.

I've been explaining Free/Libre Open Source Software (FLOSS) individually to people who don't know much about software in general and nothing at all about FLOSS. Invariably there is always a hesitancy to adopt FLOSS or consider it seriously. After much prodding and slightly rephrased repetitve questioning I invariably got down to the biggest misconception many non-techies have with FLOSS.

Just because a program is licensed as Free/Libre Open Source Software does not mean that the information you type into the program is available to anyone contributing to the design of the software. Your data is yours. No one can take that from you without your permission (unless they hack)

Explanation via analogy: A group of architects designs your house. They know your floorplan, how many bathrooms you have, where the pipes to feed your sinks are located. Based on the cost of the house, the location of the building, the floorplan, and what they know of you - they might be able to make a good guess what kind of furniture you're going to buy. However after you take ownership and move in, they'll never be allowed back into your house unless you open the front door (or leave a back window unlocked). They won't know the color of your couch, the threadcount on your linen, and will certainly not be able to see you eat breakfast each morning.

FLOSS development and community contributions stop at the architectural design level unless you choose to allow complete and total access. You decide.

Wednesday, October 15, 2008

Purpose of the blog

Kristin Shoemaker at OSATIC references a great article (post?) written by Bruce Byfield at Datamation. The post, called "Nine Attitude Problems in Free and Open Source Software" is a synopsis of the current challenges, most of complacency and focus, that he sees in the FLOSS world. The bullet point that hits home for me also provoked Kristin's post. Bruce Byfield thinks that FLOSS proponents have been preaching the trees for the forest. For every FLOSS advocate, much of the tenor of that advocacy has been of the "Woah! This tech is so cool. Look what I/you/we can do" with one particular piece of software. Byfield and Shoemaker urge the FLOSS community to instead start rephrasing the pitch more akin to the way the recycling movement has done. Focus on positive externalities and not the process.

That's what I want to do with this blog. I want to convince people (I'll start with a person) to start experimenting with FLOSS because of the ideals. FLOSS organizatinal structure is ready made for volunteer-dependent non-profits. It's a shame and it's beyond time to fix this problem.

Monday, October 13, 2008

Wiimote-whiteboard hack

If you have a projector that can be connected to a computer you can create a touch screen whiteboard on any surface for about $40.

The code is open source and there is an active community on Johnny Lee's website for this and other wiimote hacks. Save money for your office and get a very useful tool for creative collaboration in meetings.

FLOSS and your daily routine

Say you wanted to set up a meeting with a prospective client, how would you go about it? Most likely you're going to pursue a general strategy that consists of contacting the person via phone or email, agreeing on the topic of the meeting, determining the needed attendees for the meeting, checking calendars for availability, agreeing on a location, picking a time, and then writing a note for yourself as a reminder of the agreement. Most likely, if you're reading this blog, you keep track of this using an integrated mail and calendar program like Outlook, Yahoo, Hotmail, or the Google Apps suite.

According to this summary, over 95%* of the top email clients are created and sold (through advertising or licensing) through proprietary licenses. Most of you probably use one of these email clients, if not at home, then at work. The acquisition and licensing of these email clients is supposed to make your life easier. The goal of capitalism is to provide exactly what the customer desires at exactly the price at which he values the good or service if a firm can figure out a way to do so. Software acquisition doesn't fall outside of the strictures of capitalism. Software companies aim to satiate their target audience with functionality while maximizing profits.

All to often a proprietary software company views the market as a cut throat zero sum game. If they gained a customer or a feature, someone else must lose their market share or be locked out of that advanced idea. This bears out in the way proprietary software has been marketed and deals have been struck. Proprietary software companies often pitch their product akin to the fire Prometheus brought down from the mountaintop.

Sample exaggerated marketing plan for a proprietary email client

Software Company X: Hear ye! Hear ye! We have done extensive market research into the problem of sending messages to your loved ones. The best and brightest user experience guru's were hired. The smartest people, ever, have tested it and all agree. 500,000,000 people tested it and 98% agree that its the best thing to ever have existed. We have put the soul of our company into this product and we think our brilliance/diligence/cleverness/truthiness shines through. Just wait until you try it; your life will be changed forever (for the better!).
Representative of the 2% who disagreed: I doesn't do what I need it to do.
Software Company X: Of course it does.
Representative of the 2% who disagreed: No, it doesn't.
Software Company X: Oh, our market study and usability testing indicated that there wasn't sufficient demand in the market to justify our adding that functionality in. Plus, that feature would negatively affect the doohickey we added for a feature we thought was slightly more important than the one that is critical for your business.
Representative of the 2% who disagreed: Well, that's honest at least. What do you propose to do for me? Are you going to add my feature in?
Software Company X: Nope. We're working on other doohickeys that have nothing to do with your needs.
Representative of the 2% who disagreed: Well can I change it myself then?
Software Company X: No way. We are very proud of our work and have thus put it behind an iron citadel of copyright and intellectual property law. If you change it, watch out 'cause we'll sue your ass.
Representative of the 2% who disagreed: So what can I do?
Software Company X: Well, the other 98% are happy. Why don't you just settle down and work exactly like everyone else?

The italics captures my objection to proprietary software; It locks you into a way of thinking and organizing your life. Outlook users are forced to organize their day around different idea bins (mailbox, calendar, task list, created by software developers in Redmond, Washington. How many ideas have never come into existence because they didn't fit neatly into the Outlook world?

Enterprises, particularly in the nonprofit world where creativity is the lifeblood of sustainability, are locked into day to day patterns without any avenue for exploration. FLOSS, simply by providing the possibility for change, could force people to approach their day to day work a little differently than the next guy, think of a problem in a slightly different way, or help people interact with their work in a way they prefer. FLOSS, in short, presents the user with the terrible responsibility of choice for our daily routine.

With terrific responsibility, comes terrific power.

*Exceptions include open source Mozilla Thunderbird,+ Sunbird and Lightning,and the open source-friendly components of Lotus Notes

Saturday, October 11, 2008

Sahana - disaster recovery for the people by the people

Sahana is a Free and Open Source Software suite designed for post-disaster recovery. The word "Sahana" is not an acronym. Sahana means "relief" in one of the native languages of Sri Lanka, Sinhala. Sahana is the epitome of community generated and maintained FLOSS applications. It was imagined by volunteers, built by volunteers, and is sustained completely by volunteers against private competitors who didn't see the opportunity initially, and now that Sahana is nearing maturity, cannot compete with the FLOSS development model.

The history of Sahana is one of tragedy. The first version of the application was created after the massive 2004 Asian Tsunami in Sri Lanka with an internation support team with contributors from the United States (IBM) and Swedish development grants. The purpose of the application was to provide a lightweight IT solution to the collaboration problems inherent in an internationalized post-disaster recovery setting. The application was designed to push responsibility as far into the field as possible and to decentralize control so that actors could efficiently and effectively work together with a minimum of inter-organizational red tape. When the crisis in Sri Lanka ebbed a bit, the Lanka Software Foundation lead the charge for a redesigned, more robust and fucntional Sahana.

In addition to the initial deployment and use of Sahana in the 2004 Tsunami, Sahana has been used in many other crisis situations. There have been Sahana deployments in China, the Philipines, Burma/Myanmar, Pakistan. A customization of the application exists in New York City as well.

Sahana is a truly international program and community (as graphically illustrated in some of the awkward english phrasing in the application). The code that makes up the application can be internationalized into any language in the world given the need and the availability of a group of human translators.

Even though there is corporate involvement in the application (IBM and Respere to name two) the volunteer community that has emerged around Sahana has full control over the changes that are made to the Sahana application suite.

The community, in addition to being volunteer and community driven, is also quickly responsive to improvements and additions to the software. As an example, I mentioned the above quirks in the english translation. In 3 days, across the international date line and in 8 different time zones, a team has been assembled to fix the translations for basic english while another team is being assembled to create a National Incident Management System (NIMS) compliant english version for use by public and ngo organizations in the United States.

Warning: Many posts about Sahana to come
I plan on posting early and often about Sahana. A few of the topics I plan to write about:
  1. Current and intended uses
  2. Unintended/unplanned uses
  3. Community operations / organizational structure
  4. Future Sahana development ideas
  5. Reasons why the US should adopt Sahana (both Gov't and NGO's)
  6. Steps to make the US adopt Sahana (NGO)
  7. Steps to make the US adopt Sahana (Gov't)

Value of FLOSS for NGO's in a down economy

I'm echoing the ideas behind this post at the 451 group. I think the money quote comes in the second paragraph when Jay Lymon says that the downturn
"...may even translate through to the vendors that develop, sell and support open source, since rather than sheer economic value, their open source software and development projects and communities, including developers and users, represent potential innovation and opportunity, rather than money in the bank, which at this point has diminished value."

The value of FLOSS for NGO's isn't necessarily the reduced cost, instead it's the involvement of the community in the core of their organizations mission. The tools that help you serve the community are best when they are created by the community itself.

This economic downturn may result in NGO's flocking to FLOSS because they think it is an inferior good like the classic economic example of the potato. The idea behind inferior goods is that when times are good and there is disposable income, people will demand and buy fewer of these items. Potatoes, interstate bus service, and ramen noodles are good examples of inferior goods. When incomes decrease or people expect their incomes to decrease, the consumption of these items increases relative to previous consumption.

FLOSS, with the perceived high learning curve to adopt it, is viewed as an inferior good. Many large NGO's do not use FLOSS because of the percieved opportunity costs of engaging an open source community around their organization. Traditional software procurement policies also inhibit the creation of open source communities. (see FLOSS myths debunked here)

The economic downturn, with the resultant and harsher impact on the NGO community, may force NGO's to take a harder look at FLOSS to achieve objectives with a smaller budget. If the NGO's decide to start up and maintain an open source community, they might find themselves not only with cheaper software, but a broader and more engaged volunteer base.

Don't be surprised if FLOSS is a normal good in an inferior goods clothing.

Distributed resilience - MicroWind

What is this? It's a cellphone being charged by vibrations in the metal tuning fork-like doohickey sitting on the table in the picture. What's causing those vibrations? Wind.

This is a technology called Windbelt that was developed by 28 year old inventor Shawn Frayne to provide cheap and clean micropower to the third world. The idea, hatched after watching video of the collapse of the Tacoma Narrows bridge takes advantage of small wind-generated oscillations in a middle membrane that is then translated into electrical power.

Humdinger is the company that was created to commercialize this technology. How many small electronic devices could be charged by devices like this if they were planted outdoors in the city? What if the devices were glued into a constantly running HVAC system?

Taking the idea a step further: Take a look at this video from TED. at around 8:20 into the video Robin Chase (Zipcar founder) talks about creating adhoc peer-to-peer wireless mesh networks by adding a wireless router to every single car in the United States. Could we throw a Windbelt onto the spoiler of all cars to provide the constant power necessary to fuel a completely resilient wireless mesh network?

FLOSS and VOAD Definitions

The overarching theme of this blog and the idea of this post is the necessity of Voluntary Organizations Active in Disasters (VOADs) to move toward a Free/Libre Open Source Software (FLOSS) procurement policy not just for software development but also for day to day work, emergency operations, and organazational philosophy.

Before I can start talking about how VOADs can use FLOSS and why the FLOSS community should lobby for participation in VOADs, I will have to give some basic definition to both acronyms. I will also argue against the reasons VOADs, and traditional large non-profits, have ignored FLOSS historically.

Voluntary Agencies Active in Disaster is a coordination body "where the members are a coaltion of nonprofit organizations that respond to disasters as part of their overall mission." VOAD is simultaneously organized on a national, statewide, regional, and local level. Organizations that are active on all levels are the traditional big names in not-for-profit disaster work like the American Red Cross, Southern Baptist Convention, Catholic Charities USA (full list) . Many of these organizations are active on the state, regional, and local level also. Smaller not-for-profits are usually incorporated in the VOADs in the more local VOADs. In New York City, CityHarvest or The Clothing Bank are two examples of local non-profits engaged in only the local VOAD.

The organizations in VOAD are heavily focused on providing social services and recovery services to the victims of disaster. While some agencies are focused on the immediate needs of the disaster victims, others are focused on long term recovery, psychiatric health, or spiritual needs of the disaster victims.

Free/Libre/Open Source Software is (definition maintained by the Free Software Foundation)

Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

A program is free software if users have all of these freedoms. Thus, you should be free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere. Being free to do these things means (among other things) that you do not have to ask or pay for permission.

In a pracitcal sense, FLOSS means that you can make any changes you want to a personal copy of the software without fear of reproachment, and actually with the possiblity of encouragement by the community that uses that software.

Proprietary Software
The antithesis of FLOSS is proprietary software. Proprietary software is typically developed by a company that holds the copyrights on any products they release and does not (officially) let you, the end user make changes to the program.
Reblog this post [with Zemanta]