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.

Wednesday, December 10, 2008

IT SECURITY: UR DOIN IT RONG

draft

I'm going to quote a blog post in its entirety (I'll try not to do this too often)

Just a quick hit on this Intel-sponsored survey: apparently, employers think millennials like me are good employees, but that we're a risk when it comes to IT security. (Believe me, the intersection between millennial and IT prompted me to title this post LOLCats style: IT SECURITY: UR DOIN IT RONG). I think this speaks to evolving norms of security and privacy. I would be that a lot of employers' perceptions are based on the fact that people my age post a lot of stuff on facebook, have, or had, personal blogs, etc. But I think that's not actually super-relevant for professional IT security. Just because people put stuff out there doesn't mean they don't care about information being secure; rather, their standards for what NEEDS to be secure are different. Just because Paris Hilton got her sidekick hacked doesn't mean she's careless with her information; it means the hardware she's using is vulnerable. In a world of telework, among other things, agencies are going to have to come up with new, goof-proof ways to keep information secure. But a more open, tech-savvy generation isn't inherently an IT security risk. (bolding mine)

I think that Alyssa contradicts herself here.  Immediately after saying that the millennial generation posts information everywhere, she says that it's not a security risk because of standards for security risk are different.  That's like saying it's OK to have one person playing tackle football when everyone else is playing soccer.  When there are two competing rule sets, the group that is out of power but trends to information openness is automatically viewed as a security risk.  Hell, I know much of the open source world is a security risk. I just happen to weigh the benefits of openness much greater than the benefits of total information security.

I don't doubt (well, I hope) that Alyssa has a more nuanced view of IT security vs. openness, I just think that the nuance is a necessary part of the discussion to further the cause of transparency into the security conscious older generation. I don't want to have to wait for the boomers to die off to live in a more transparent world.




Tuesday, December 9, 2008

Social Networking, Trust, and Disaster

Draft

I riffed a few days ago on Twitter and its potential uses in disaster. Fester, over at Newshoggers (thanks for the plug Fester!) responded to my post and added a bit of analysis at the bottom which I glossed over as a basic assumption for understanding the value and drive/cause of iterative improvements

Legitimacy in today's world is based upon trust.  Good information that is widely distributed through a variety of common channels improves trust.  It also relieves the responding agencies of a massive command and control problem of evacuation and crisis avoidance.

But what is trust in social networking, how is it established, and what does it mean in crisis situations where there will be many interactions based on trusting the reportage of strangers?  After all, there are millions of people in city like New York and no one person can remember all their names.

Trust can be established in many ways through social networking. The lowest barrier to trusting information is to know the person in real life.  That person is not likely to be useful for reporting on crisis or emergencies. Your friend simply isn't likely to be an eyewitness on the scene of a particular disaster you're wondering about (unless you care very intensely about the disaster because of the relationship).  The second lowest bar is the friend of the friend or friend of the colleague, colleague of the friend. You trust a person that a person you trust trusts --say that five times fast.  The next level of distance is the voice of demonstrable expertise. We have these in real life, Jane Jacobs called them the neighborhood characters that are the bedrock and enablers of any community. Their expertise, whether it be in astrophysics, the relative merits of deli egg sandwiches, or disaster technology, is widely acknowledged by the general public and are trusted based on their demonstrated expertise.

Now here is where technologically boosted networking becomes a bit disjointed from our flesh and blood reality; there are non-experts without immediate or secondary connections to you who you will be relying upon to ort their experiences during disaster. Why should you trust them?

You end up with an extended network of friends, friends of friends, experts and trusted strangers because there is an implicit trust that is built into the fabric of those connections.  Knowing a particular individual, and being on the same technological extension of a social network, and knowing about a topic and finding another interested person passionate about that topic become one and the same.  Because of each individuals orientation, training, religion, schooling, preference for smooth over crunchy peanut butter, they have found a level at which they can communicate across/through unfamiliarity. Strangers find common cause through parallel orientations.  Those parallel orientations, over time, build into a more cohesive trust that can be translated as if the referral were a friend of a friend.  

I read an interesting blog post about the different types of twitter users (I cannot find the link) where there were basically broadcasters and engagers, and the difference was readily apparent by calculating the ratio of followers to followed and by monitoring how many tweets were replies or question redirects (@'s and Retweets-RT in tweetspeak).  When you include this basic caluclation on top of hte multiple level orientations, as Fester mentions below in comments, you have a valid social network that can provide relatively good information in a rapid response time frame.  The information can be assumed to be as valid as any median person could establish in the same time frame.

Now to respond to the second sentence of Fester's quote above- how does Twitter relieve the command and control function of an emergency manager or central control point? Participation in Twitter- in building and maintaining the relationship, networks and trust- enables large movements of people to self regulate based on information being provided to them by people they trust they can trust (not a typo).  The quick updates of twitter allow frequent adjustments to be made by everyone in the network. Broadcasted disagreements with the initial reporting lead to a quickly resolved situation where the facts quickly win out (I know this anecdotally only).  Twitter was wisely designed as an impersonal social network. If someone provides bad feedback, their feed can be dumped without residual social implications in a way that facebook friends cannot.  In this way, Twitter is even more quickly the best stream of corrected information.  

Public safety agencies and personnel should learn to take advantage of the self-correcting mechanisms inherent in an  impersonal, but trust based social networking tool that increases the penetration of good information.  There may need to be legal caveats to the methods by which public safety agencies can participate, and there would need to be an experienced bullshit detector at the tweeting keyboard, but there is no reason to expect a net loss of utility and safety from twitter.  If Bin Laden hacked Oprah's account and started tweeting, the account would quickly be ignored and would lose influence.

I will soon have another post of my response to fester's double-edged sword argument.



Wednesday, December 3, 2008

Gadgets and Gizmos

Draft

This is a post about the recent attacks on Mumbai.

I thoroughly enjoy the work 37signals does promoting themselves and their products. I don't even need a disclaimer; Not only am I completely unaffiliated with any of the partners, I don't even use their products. I am, however, a rabid consumer of their blog and book

Their entire focus is on overperforming while un-delivering.  They take keep it simple stupid to its brilliant extreme.  Choose the most basic tool that does the job and make that tool the best damned widget imaginable but realize that the process is iterative.  To get to that end killer app you should throw together as many practical drafts as possible and make them live to real life conditions so as to expose the flaws. 

Like I said above, this is a post about Mumbai, in particular the tools that the terrorists used to create their mobile network that could keep inside the decision cycle of millions of minds.  John Robb at Global Guerillas has a post up called "Off the Shelter Leverage" where he gives a preliminary (final?) list of the off-the-shelf technologies that were fused with group cohesion to create a cascading system affect in a major metroplitan area.  My question is, where was the off the shelf response?

The terrorists didn't have to go through a year long RFP and procurement process.  They had the flexibility to shop, compare, buy, and modify their own tools. Compare that to the procurement process for a government agency, even (particularly?) in the security realm.  While the security forces probably had more advanced technology, or more "secure" technology, the terrorists didn't care.  The terrorists were able to take advantage of the ocean of masking signals to stay anonymous - official security relies on dedicated services.  Terrorists modify their equipment to meet changing needs. Government has standard issue supplies.


http://blog.wired.com/defense/2008/12/the-gagdets-of.html

Twitter

Draft

Twitter is a mobile social web application designed to allow the efficient sharing of micro-thoughts in 140 character bursts.  In normal times people use Twitter to answer some very basic questions:
  • What are you doing now?
  • What are you thinking now?
  • What's got you puzzled/troubled?
  • Where can I find homemade bagel bites in the East Village at 3 a.m on Thanksgiving?
One of the emerging focuses, particularly after the Mumbai terror attacks, is on the disaster or crisis applications of a service like Twitter. (Follow all the links in this post at Weblosky for a brief survey of the mixed opinions of Twitter's efficacy during crisis.  Those opinions range from (paraphrased)
  1. "Of course distributed citizenry should be contributing on-scene reportage- it works! We rule!"
  2. "There's an unhealthy signal to noise ratio coming out of the scene but Twitter helps because it usually self-corrects pretty darn quickly"
  3. "Dirty Fucking Hippies - Leave the reporting to the pro's and go back to your commune"
As you might be able to tell, I disagree with the third way. I see no practical reason to ignore the large portion of the population that is on scene and reporting an incident, even if they might be wrong. I want to know what people are thinking, especially if they are wrong. Twitter is a tool where, if a public safety agency was quick and smart enough, they could correct public misconception quickly and relatively painless without relying the market penetration of traditional mass media. After all, who's going to go throw on a noisy TV or Radio when there's a mass murderers appearing out of no where and shooting into a crowd?

I also disagree with the first of these reactions, but only to a degree. I love the idea of an informed citizenry exercising their right to communicate in normal times but even more so during times of stress.  And so my support must go to the opinion smack dab in the middle at number two. There's a saying I've heard many times that, even through "official" channels that 90% of the information coming in the first couple hours from the scene of a large incident is gunk anyway.  All I want in the first few minutes, hours, of an incident is to know that there is buzz in the citizenry and that, yes, something is happening, stay alert.

Stay alert. That's half the battle right there.

Once people have been alerted to an incident, Twitter's quick iterative fact checking will win the day. These distributed information loops will be particularly effective with that enterprising public safety agency, calling LAFD/and halfheartedly LAPD, interjecting "official" news to aid the acceleration of correct information throughout the social network. 

The ideal Twitter-like tool would have to be location aware and be hosted on broadcasting mobile devices to be able to create low/no official network ad-hoc wireless mesh....but that's a post for another day.

Urban discrimination in the Stafford Act

Draft

Robert T. Stafford Disaster Relief and Emergency Assistance Act (the Stafford Act) is the law of the land for federal emergency management and disaster relief. The act not only authorizes FEMA's existence, but it also lays out the scope and particulars of the agency and how federal resource may be allocated for national, state, and local response.


There are many problems with FEMA. Some of them are due to personnel, others political, but today's FEMA rant is about policy.  When a disaster hits you and destroys a significant portion of your livelihood and home, the last thing you're really worried about is FEMA's paperwork. All you want to do is recover from the disaster as quickly and wholistically as possible. You don't care where the money comes from, all that matters is that you're able to afford a motel room, some gas for your car, and the plywood and contractors to fix your roof.  FEMA, through the Stafford Act, is even obligated to assist you in those efforts.


The immediate needs- things like food, water, baby formula, and medicine fall into the category of "critical needs" while the longer term fixes to your house, intermediate sheltering, and car repairs/replacements fall under FEMA's Individual and Households program.  The Stafford Act places a cap on combined aid (critical needs+Individuals and Households) going to households at a flat ceiling that is adjusted annually by the National Consumer Price Index (CPI-U) that is calculated by the United States Department of LaborBureau of Labor Statistics.


In 2000, FEMA's cap on individual assistance was set at $25,000 to be adjusted annually based on the National Consumer Price Index. This has resulted, in October 2008, to an adjustment for assistance to $30,300 per household. I have no argument with the base sum of money available via grant. That's not my complaint and it is a valid policy option to have a low grant total so as to incentivize the population to better insure themselves against risk. After more study of the issue, I may ask for a base increase to the funding amount.  That's neither here nor there.


FEMA is in the recovery service business.  By pegging the adjustment of the cap for individual assistance to the National CPI as opposed to the more local Regional or even more local Metropolitan Statistical Area CPI, FEMA is effectively providing more recovery for areas that had been lagging indicators for the CPI. They are able to afford moregoods and services with which to recover as compared to an urbanized environment.  For any absolute value enforced across the board, the urban dweller loses as they have less purchasing power.


FEMA should focus on providing equity in recovery services and stop focusing on dollar for dollar parity.


But I guess this is what happens when the Dakota's get four desks in the Senate.


NOTE - I am working on some calculations to show the disparity between the outliers taken into account by the CPI all urban areas vs. regional vs. Metropolitan Statistical Areas but I'm having some difficulties. I can't seem to recreate FEMA's accounting that created the new $30,300 threshold. The closest I've gotten is $30,494 assuming I perform the calculations using September to September as the base fiscal year.  I'll be re-examing this in the next few days to try to nail down the discrepancies.



Technorati Tags     ,,

Posting Schedule

Final

My recent posting schedule is no way to obtain an audience. Hopefully enough people have RSS readers.

I've got some posts in my head that I'll be laying out over the next two weeks. Anyway, thanks for sticking with the blackout of a nascent blog.





Sunday, November 9, 2008

Proprietary security

Final

Just a quick note - All the security flaws described in this article are attacks against proprietary software.  The argument about that open source software is fundamentally less secure than proprietary software doesn't really hold up, yet again.  Any software that has a significant user base will have to deal with hacks, attacks, and trojans.  Healthy FLOSS communities simply respond faster.

Technorati Tags     ,,

Two Innocentive challenges for readers of this blog

Final

Innocentive is a crowd sourcing invention network of corporate or ngo partners who post problems and a completely distributed network of folks who solve them for cash prizes. While many (most) of the challenges are of a very technical nature involving chemical engineering, bioengineering, physics, materials science etc there are, here and there, some problems which fall into the realm of public policy, architecture and design, and programmatic planning.  When I see on of these projects I'll post them here to see if we can't crowd source a crowd sourced question.  Thanks to Fester at Newshoggers for prompting this post and the series of posts on this issue to follow.

Chicago Public Transportation

Project Criteria
The provided solution should accomplish the following:

  • Develop a plan to increase public transportation ridership in Chicago to 1 billion rides per year, adding approximately 800,000 new riders to the system.
  • Solutions should be have reasonable costs that are explicitly estimated in the proposal
  • The use of innovative technologies and strategies encouraged, but should be reasonable.


The solutions should be in the form of a written document. The document should clearly answer the above questions and fulfill the above criteria. There is no absolute length limit to solutions for this Challenge, although we estimate that the winning solution will be between 2 and 15 pages. Longer, well thought out proposals will also be considered.

This Ideation type of Challenge has a guaranteed award of $5,000 that will be determined exclusively be the Seeker. If multiple solutions are deemed winners, they may be each awarded partial awards totaling $5,000.


Rainwater storage system for the developing world

Project Criteria

The Challenge is to design a very low cost rainwater storage system that can be installed in a developing country. Designs that are modular, adaptable, salvageable or that have multipurpose function are preferred.

This requires only a written proposal.
The proposal, which will be evaluated by the Seeker on a theoretical basis, should include the following:

  1. Identification/Detailed Description of a rainwater storage system that can meet the technical requirements as explained above.
  2. Rationale as to why the Solver believes that the proposed design will work. This is important for an acceptable solution. This rationale should address each of the Technical Requirements described in the Detailed Description and should be supported with relevant examples and literature citations if applicable.
  3. Cost estimates of all aspects of the design as explained in the requirements above.
  4. Detailed drawings of your design



Technorati Tags     ,,

Why FOSS will not suffer from Tragedy of the Commons

Final

Free and Open Source Software will never succumb to the tragedy of the commons. FOSS simply uses a completely different model of generation and community consumption. The tragedy of the commons argument (Wikipedia page here) is often used as an argument for government regulation of collectively held assets or for the complete privatization of all the assets. 

Regulation is encouraged by some to prevent the overuse of the resource by a select few of the owners.  In the typical example there is a town with a collectively held green that is used for pasturage.  Every town citizen has the right to graze their cattle on the common.  Assuming all the interested parties would like to own healthy cattle for more than one year, there is both a collective and individual interest to keep the grass healthy and resilient through moderating the grass consumption.  Unchecked individuals may seek to one-up each other in over consumption of the commons and thus jeopardize the entire communities long term health.  Those on the side of regulation say "Let's just limit how much any one person can take from the commons so as to guarantee the long term sustainability of the commons".

Privatization is supported by others to replace the collective responsibility for the health of the commons with a personal self-interest that requires an individual to think sustainably for their own survival.  The idea is to split the commonly held land into parcels and give responsibility and ownership to individuals. These individuals would then internalize their need to keep the ground healthy for the next season which would induce self-moderation individually, and through a cascade of this responsibility, collectively.

The process that catalyzes and then later maintains then extends Free and Open Source Software uses the language of the commons but springs from entirely different constraints.  The commons used to graze Bostonian cattle in the example above was a finite resource in which the end product was a definable physical product - the well fed cow. Because there is a physical limitation of how much grass can be grown on the common there is a competition for fungible things. The fight is for who can get the most grass into the greatest number of cows.  Any grass that your cow eats means that my cow cannot eat it. It's a zero sum game, bub, and I want you to be the zero.

Free and Open Source Software doesn't deal in fungible goods - it simply packages methods of organizing thoughts through technical skill.  Free and Open Source Software are commonly created ideas that have been made real. There is no zero sum in the competition for open source software.  If you win, I can win too, then build off both victories to create another win-win.  Free and Open Source Software, as you can see by that flawless logic, is for winners! More seriously, FOSS doesn't do anything but help you work and think faster, better, smoother. By removing copyright and ownership from the equation you, the end user, can focus on what matters; the value-added from the tool and the quickness with which the tool can be produced or refined.

As Cameron Neylon at Science in the Open alludes to in this post "It is not the object that has value, because it can be infinitely copied for near zero cost, it is the skill and expertise in putting the object together that has value." What you pay for, when you pay for anything in the Free and Open Source world, is the idea - not the object.  Without an object, there's no tragedy on the commons.


Technorati Tags    

Friday, November 7, 2008

OpenEvsys

Final

What is OpenEvys?


OpenEvys is a software suite in development that has been designed by the folks at HURIDOCS in collaboration with the guys at Respere.  HURIDOCS is a human rights watchdog network based in Geneva, Switzerland that works "to ensure that human rights organisations have the tools, knowledge, skills and supporting services to use their information resources effectively."  Much of HURIDOCS work is focused on helping the human rights community report abuses and interventions in some of the most dangerous areas of the world.  HURIDOCS tries to help other human rights agencies and individuals by creating the tools to do their jobs more effectively(a mission after my own heart).  OpenEvys will be a Sahana-based case working system designed to aid humanitarian agencies keep track of both human rights violations and the measures taken to intervene.


Why am I so excited about this announcement?

I have a few reasons, in no particular ranked order, why I"m excited about this new development.

OpenEvys will be Sahana based

Sahana is a free and open source disaster management tool (Sahana site here/ My blog description here) that is currently focused on post-disaster aid and recovery coordination. The Sahana community has a very organic bottom up organization that solicits contributions from all interested parties and varying levels of technical skill. It's an egalitarian organization where anyone with a good idea will have a fair shake. Additionally, the community is just that- a community. When major disasters have hit (Leyte mudslides, China earthquake, etc) the Sahana community has mobilized its volunteer base to aid in the implementation and customization of Sahana to the locality. 

So far, however, Sahana has not moved much beyond in-kind donations or "logistics" for the aid coordination.  This is not a knock on Sahana - FEMA has a juggernaught of personnnel and budget compared to that being funneled to Sahana and they're still lost. There is only so much the Sahana community can accomplish with the limited resources available at present.

Because OpenEvys will be Sahana based, the organic community, technical standards, and hopefully the volunteer base might be mobilized to support deployments of the software suite.  The main advantage for OpenEvys adopting Sahana community standards is that it will allow for easy customization of OpenEvys for post-disaster case working.

Free and Open Source Case Management Software

What do case workers do? Case workers are the advocates for individuals affected by disasters.  They help people of all incomes, races, ethnicities, religions etc... to recovery more quickly from the disasters and get back on their feet. In non-emergency situations case workers focus on helping those who fall into at-risk or vulnerable populations. Many of these people are also the most likely to be severely impacted by disasters so much of post-disater caseworking is aiding pre-existing clients with an additional set of problems created by the emergency.

Case workers are often social workers or are those with a particular humanitarian bent.  Technical knowledge is lacking in their training more often than not because of the overburned schedules and lack of funding that is sadly consistent regardless of the economic climate.  Time is money and caseworkers never get enough of either.

An additional feature of the case management universe is that there is a multitude of disparate agencies (see the alphabet soup of agencies at the bottom of the linked page for a small sample) who have case workers on staff. None of these agencies are rolling in cash.  Each would like to serve as many peple as possible while keeping within their budgets.  In order to prevent duplification of benefits, reduce individual agency overhead, and provide more consistent services, the agencies would benefit from a case management software suite that adheres to open standards and is fully customizable by each of the agencies through paid or volunteer efforts. 

While there are ongoing attempts to create this clearing house for case managemnet (See the Coordinated Assistance Network) the software is often too expensive to maintain in non-disaster situations and funding has been an issue.

OpenEvys will be the baseline case management software suite that has already found a champion in HURRIDOCS.  Agency participation is voluntary.

Technical tools for the non-technical end user

The most important development in my opinion, is that this is another attempt to engage the non-technical in the creation of their own tools.  By creating a Free and Open Source Case Management suite based on Sahana, HURIDOCS is giving the power to the social workers/case workers at the point end of the mission.  The social workers get to dictate how they want to work and what their software will enable them to do.  This revelation, this empowerment, of the end-user caseworker can only help the entire process. 

Assuming positive engagement of the case worker community, the software will make them more effective in the short term with the implementation of a community-designed software suit but also in the longer term as the implications of self-created tools empowers the end user to change their approach to how they approach their work.

Non-technical end user social workers (dirty f****ing hippies) will be able to reject off the shelf software as the mediocrity it likely is and build their own with the help of the technical community.

This future cannot come soon enough.



Dear Humanitarian-ICT group --

I'm Tom Longley, a project manager at Human Rights Information and
Documentation Systems, International (HURIDOCS). HURIDOCS is
Geneva-based, and has worked on information management for human
rights for 20 or so years. We've developed some useful tools to assist
human rights defenders in monitoring the situation in their country,
or globally. These include data standards, methodologies, controlled
vocabularies and database applications for documenting and analysing
human rights violations.

After a Request for Proposals process (RFP) run across this summer,
we've decided to use SAHANA as the underlying framework for
"OpenEvsys", anew open source human rights case management system.
SAHANA's features and capabilities clearly meet many of the requests
that organisations using our past applications have made of us over
the last year: clean, attractive interface, server-based, multi-user,
access control and permissioning, improved security, mapping and
charting.

Your colleagues at Respere (http://respere.com/) won the RFP with an
exiting, hugely persuasive vision of what could be achieved by
investing in, and re-using SAHANA in this way. OpenEvsys will be
released as free and open source software, and we are also pursuing
open methods in the product's development. Development is already
underway at Respere: we'll open the growing codebase up shortly on a
public repository, and gradually build up the ways in which people can
involve themselves in the project.

Amongst many things, we see OpenEvsys as:

- A generic case management system, tethered to Human Rights
standards, that meets the core needs of monitoring organisations but
is not costly to customise.
- An open place where technical people and others can contribute to
improving a system that is directly in use by human rights organisations.
- a starting point for service providers to work with in many
different local ICT markets and settings.
- A challenge to the sad habit in our sector of locking up vast public
international and donor resource in costly, duplicate, secret systems
that could easily benefit our community, and be strengthened by public
exposure.

We've put together a short briefing paper about OpenEvsys, which
describes what it will do, how it's being developed, when it will be
ready, and who will find it useful:

http://www.huridocs.org/tools/monitoring/openevsys
(grab as PDF: http://tinyurl.com/openevsysbrief ~240kb)

Happy to take any questions right here...

Regards,

Tom


Technorati Tags     ,,,,

Monday, October 27, 2008

InSTEDD Tracker

FINAL

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

FINAL
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.

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

Sole-source-anonymous

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.

VOAD
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.

FLOSS
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]