Open Source and Global Health
'Open Source Development and Global Health'
Introduction
Open source software and global health share key philosophical traits. Both intend to allow for a greater good which is shared by all peoples of the world without discrimination to location, finances, or culture. Software that is free can't be lost to funding loss, project reorganization, or end-of-project termination. Free software allows for sustainability. There can be no better ideal to both global health and free software than having "the freedom to improve the program, and release your improvements to the public, so that the whole community benefits" Richard Stallman → http://www.fsf.org/licensing/essays/free-sw.html This is one reason why we have chosen to use open source licensing for the Capacity Project's iHRIS Suite, and other projects. At IntraHealth we take to heart the idea that the education, tools, and ideals we bring to partners in the field live on once we have successfully ended a project and moved on to the next thing.
Open source ensures that the code can live on legally and can benefit by sparking community around the code. If all goes well, a strong community can spark very rapid development, rapid and free development. So what exactly is open source?
Open Source Software DefinitionFrom the Open Source Initiative → http://www.opensource.org/docs/osd:
- Free Redistribution
- Source Code
- Derived Works
- Integrity of The Author's Source Code
- No Discrimination Against Persons or Groups
- No Discrimination Against Fields of Endeavor
- Distribution of License
- License Must Not Be Specific to a Product
- License Must Not Restrict Other Software
- License Must Be Technology-Neutral
To successfully release your software as open source there are a few steps to take to ensure others will know about it and have the freedom to work with you. The first step is to choose a license. There is no single step more important than to license your code, even before you start writing it. The license isn't just the legal footing you have to protect your creation, it is also a statement of intention. Choosing a good open source license states your intention to work with others and to share your good work freely.
Open Source Licenses:
The GPL or General Public License is the most well known of all open source licenses and the most widely used. What sets the GPL apart from other licenses is
that it does include some protections as opposed to licenses like BSD or MIT. Still, it guarantees freedom and openness as opposed to any proprietary license.[[Image:]]
The protections built into the GPL are the protections of retaining your identity and intent. The license itself has been called "viral" by Microsoft lawyers and executives because it guarantees that the code will always be open. If opening the code was your intent then that can't be a bad thing.
Building a Community:
One cannot simply assume that the decision to release a project under an open source license automatically guarantees a community will grow up around it. There is work involved in fostering community and there is work involved in making sure the ground is fertile for growth. The single most important thing to keep in mind about open source communities is that the community is first and foremost made up of those who will actually use the application. Do not expect a random person who has no need for the application to simply jump in and fix your bugs or add a new feature.
Here are some ideas about growing a community:
- Make something good. There is no way around this. No community grows up around useless things.
- Once you have this good thing, or even the idea for the good thing, find other people who like similar good things. Join in the conversations around those things and let people know your intentions. Ask them to join in. You are already part of communities and social networks - use them.
- Have a builder/maintainer. This does take work, you can't just sit back and wait for people to come to you. Assign someone who will work on the community and make sure it is easy for them to participate.
- Be open. Be transparent. If you are always guarding your ideas and your work the community will leave. If you don't start off open and transparent they will never show up to begin with.
- Be OK with criticism. You'd be amazed what talking sanely to your most fervent critic can do for both you and the critic. Sometimes your critic can become your best advocate.
- Provide multiple ways for people to learn about and take part in the community. Community is all about discourse. If there is nowhere for the community to share then there is no community... or at least not one in which you are involved.
- Publicize. Let people know about your "something good". Let people know about your community. You never know who is out there looking for what you have to offer. This doesn't just have to be online - make the communication grid dense.
- Accept any and all help. It doesn't have to appear in the final code - it may not even be code. Accepting work only grows the community.
The community building process for the Capacity Project goes beyond simply the software. We are attempting to create ownership of the whole project by growing up the community at all levels. We do this through our defined processes: stakeholder leadership participation from the first day; strengthen any infrastructure from personnel to hardware; developing software customized to each area's critical needs; always provide data for decision making; sustainability.
While most of the folks who are taking ownership of the iHRIS Suite are not developers, we've watched with great interest as developers have begun to take notice and join in. The Ministry of Health in Uganda has taken a special interest in the suite and has a few very good developers on staff. Conversations with that staff are now easily taking place on a simple IRC chat room we have set up for iHRIS (#ihris on otfc.net). The type of help these developers are giving us is invaluable as they will also be the users of the system - this is exactly the type of community which can transform an application over time.
Tool set and releasing:
To make sure people have access to your code, and to make sure your code is usable in a large variety of situations its important to use the correct tools to share and promote your code. For the Capacity Project we chose to use Launchpad. Launchpad is an online tool built by Canonical (the sponsors of the Ubuntu Linux project). Launchpad is a code hosting site which is also a multi-function workspace that includes a version control system, bug tracking, translation tools, etc. Plus it allows for you to use other tools in place of theirs while still maintaining a single location for a project. Other similar systems which might suit your project better are Sourceforge, and Google Code.
Try to make transparency instinctive to your workflow. The more you share, the more you will reap. Don't feel shy about the "doneness" of your work, let people know its not done or its just thoughts - the discussion that builds up around that can make your work better long before any big problems arise.
Final thought:
We all have a common story to tell in helping people with their health. While sharing global health ideas and information comes naturally to us, sharing our tools can be too. If it does, we can all benefit.
More Information:
IntraHealth International → http://www.intrahealth.org
Capacity Project → http://www.capacityproject.org
iHRIS Suite → http://www.capacityproject.org/hris/
Launchpad → http://www.launchpad.net
iHRIS on LP → https://launchpad.net/ihris-suite
Sourceforge → http://sourceforge.net
Google Code → http://code.google.com
Open Source Initiative → http://www.opensource.org/
dm4son@del.icio.us → http://del.icio.us/dm4son
Open Source Software for Public Health Wiki → http://www.ibiblio.org/pjones/wiki/index.php/Open_Source_Software_for_Public_Health
Recommended Reading:
Books:
Here Comes Everybody - Clay Shirky
Code: And Other Laws of Cyberspace - Larry Lessig
Democratizing Innovation - Eric Von Hippel
The Wealth of Networks - Yochai Benkler
Papers:
Commons Based Peer Production and Virtue - Yochai Benkler, Helen Nissenbaum: 14(4) J. Political Philosophy 394-419 (2006) → http://www.nyu.edu/projects/nissenbaum/papers/jopp_235.pdf
