H-FOSS Goals

Humanitarian FOSS (H-FOSS) is simply the application of Free and Open Source Software in support in of humanitarian Response. In alignment with Humanitarian principles, H-FOSS offers the following advantages:

  1. No Discrimination on Access: Once available under a FOSS license, the software effectively becomes a global public good, available for anyone around the world to download and use freely. Thus there is no inherent discrimination on the access to this software.
  2. Transparent and Trustworthy: As the software design and mechanism for building FOSS is transparent it becomes more trustworthy. Additionally with truly global and diverse FOSS communities, the software becomes resistant to any particular political agenda. Particularly in conflict such software can serve as a transparent mediator
  3. Low Cost and Local Capacity: FOSS helps reduces the digital divide as there is no additional cost for the product itself. However you still need people to maintain the software, and if this service is costly the nation has the freedom to promote local capacity development within the nation and such local capacity development is encouraged by FOSS communities.
  4. Global Reuse and Shared Inter-Org Development: NGOs and Humanitarian Relief organizations all need software tools to be effective, however not all have the needed funds to disburse to purchase the software tools. FOSS can easily a provide a vehicle for intra-organizational development of tools in the Humanitarian domain, where each can contribute a fraction, yet benefit from the whole.
  5. Adaptability: No nation handles the humanitarian response the same way and there are many variances expected of software including translation for it to be usable in a nation. With FOSS, as the blueprints are also available freely, anyone is able to modify the software as required to suit the problem.

Ref: http://en.wikipedia.org/wiki/Humanitarian-FOSS

Alignment to Red Cross Code of Conduct

However such benefits cannot be just realized by software, but also by the communities that support the solution.

Many humanitarian organizations reference and/or adhere to the Red Cross/Crescent Code of Conduct. The concept of Humanitarian-FOSS is aligned to this code especially in the following areas:

  1. The Humanitarian imperative comes first. Humanitarian-FOSS Projects should have this as their primary goal, irrespective of the Free and Open Source aspirations.
  2. Aid is given regardless of the race, creed or nationality of the recipients and without adverse distinction of any kind. Aid priorities are calculated on the basis of need alone. There is no restriction on who downloads, modifies and uses Humanitarian Free and Open Source Software. The only constraints that should be permitted should be that which promotes the humanitarian goals.
  3. We shall respect culture and custom. Free and Open Source communities are most often global communities and thus represents an integration of various cultures. The tools are often deployed by locals in the region of the disaster or crisis.
  4. We shall attempt to build disaster response on local capacities. Local communities are encouraged to build capacity on the knowledge of FOSS tools. This help improve their resilience to future disasters.

A Recommended Code of Conduct for Open Source Community Contributors

Given that the solutions we deploy helps to save lives and alleviate suffering it is important to be cognizant of the impact of your decisions and conduct

Version 1.1

  1. Our primary goal is to help victims through the direct and indirect use of humanitarian free and open source software (H-FOSS)
  2. We will keep tools simple, end user usability the focus and alleviation of suffering for victims the goal
  3. We will collaborate with other projects to do our best to provide comprehensive solutions even if that means that there is some mutual redundancy
  4. We support open standards and will seek to implement and test them in advance in preparation for collaborative response
  5. We will adhere to global and local cultural norms of respect and etiquette in our interactions with other developers, users, and responders. We will strive to understand their points of view and preferences.
  6. We will understand the needs of our users and adapt our systems to their ways of doing things and not the other way around.
  7. We will disclose commercial or other relevant interests when suggesting a solution.
  8. We will actively share our knowledge and best practices with others.
  9. We will try our best to not become a bottleneck or a single point of failure in deployment and development by promoting training and good documentation practices
  10. We will honor our commitments when volunteering by ensuring that we understand what is expected of us, and the time and effort involved.
  11. We will be honest and forthright when discussing the capabilities and limitations of our solutions.
  12. We will support and promote local capacity building and diversity in our communities

Based on some feedback on Version 1.0

Version 1.0

  1. Keep tools simple, end user usability the focus and alleviation of suffering for victims the goal
  2. Strive to collaborate and integrate with H-FOSS and other aligned solution providers to provide a holistic solution even if it means there is some mutual redundancy (which is positive)
  3. Support Open Standards and look to implement and test them with others in advance so that you are better prepared
  4. Adhere to globally and local rules of respect and etiquette in your interactions with other developers, users, responders, etc. Strive to understand their point of view that may bias their preferences.
  5. Understands the end client. Let the system adopt to their ways of doing things and not the other way around.
  6. Implementation biases and commercial interests should be avoided as much as possible in the solutions you recommend
  7. Actively share your knowledge and best practices with other projects and encourage reuse
  8. Try your best to help but work towards not becoming a bottleneck or single point of failure during a disaster response effort. You can do this by keeping your solutions simple (KISS), providing clear developer documentation.
  9. If you are volunteering to respond, make a commitment and make sure you understand what is expected of you and that you can commit that time for the expected duration
  10. If you know your tool has major points of failure, do not gloss over them but ensure you set that expectation with users during a response effort. It might still be the best option.
  11. Support and promote local capacity and diversity in your community and support infrastructure. Any form of harassment is completely unacceptable
 
/home6/gyttjaor/public_html/humanitarianict/wiki/data/pages/h-foss_code_of_conduct.txt · Last modified: 2010/10/18 06:54 by chamindra
 
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki