Name of group/organization/project: Open Source Software Institute (OSSI) Overview: The Open Source Software Institute (OSSI) is a non-profit (501 c 6) organization that was launched in 2001 with the purpose of “[promoting] the development and implementation of open source software solutions within federal, state, and municipal government agencies and academic entities”. OSSI acts in three capacities: as a policy advocate, as a research and development facilitator and as an open source policy consortium. The OSSI community is diverse but mostly made up of private-sector open source players. The organization has a strong following of 1,000 individuals in their mailing list (as of the end of 2007), along with 16 major corporate sponsors, 3 governments, 1 academic institution and some associates and community members. The structure of the organization consists of an elected Executive Director at the top, who is responsible for the day to day running of the organization, along with a board of directors that deal with strategic decisions. Similar to a non-profit organization, it also has an advisory board that advises on various strategic and tactical issues. Though OSSI’s  initial focus was on defense, the group has diversified into all levels of government. For example, as of 2009, they have been working on a suite of applications for the criminal justice department for example the Public Open Source Safety Environment (POSSE) which aims to provide each agency autonomy and control of its IT system and record data. Problem addressed and Solution implemented: OSSI rose out of the demand for product software that met individual government agency’s organizational needs. The members felt that when it came to information technology, government was reinventing the wheel. The solution was therefore to “[facilitate] a move towards open source solutions in government”. OSSI’s strategy focused on particular projects. Developed software were often mission-critical such as the development of code for Department of Defense (DoD). There was clearly a collaboration between private entities and government organizations to develop open source products that met specific government needs. OSSI also went beyond code development and puts major emphasis on research and policy advocacy. At the moment, members have access to the open source codes under open source licensing, which varies depending on the project. However, software developed for DoD is not available for reuse on the web due to security concerns. OSSI’s immediate goal is to launch a repository for all the open source codes for broad government reuse beyond the membership base. Challenges Faced and Criticisms:

• Narrowly focused on specific projects like the DoD software, which could not be shared with other organizations.

Lessons Learned:

• A stable leader, who was able to devote significant amount of time and energy to the organization, was key to the organizations survival. Also having a dedicated paid staff was crucial. The graduate fee levied from corporate sponsors was used to fund the executive director and the administrative positions.
• A well defined organization structure was important but flexibility allowed for change and evolution of the organization to better fit the needs of members and clients.
• Nearly all those interviewed by Hamel noted that value was critical in open source collaboration.
• Incentives and membership structures can help mobilize collective action in the open source development domain. “The generation of new economic opportunities with government partners provides real motivation for members to participate in the collaboration, which is supported by recent work which found that firms are typically motivated by economic and technical benefits (Joode, et al., 2006; Bonaccorsi and Rossi, 2006).”
• Focus on initiatives. OSSI’s project driven model kept the organization focused. This meant that government participants were motivated to work with other collaborators because of the skills and potential benefits on offer.
• Participants were quick to point out that “that support and hardware expenses should be a part of any software consideration.”

References (websites, documents, links, resources used and for further information):

1. “Open Source Collaboration: Two Cases in the U.S. Public Sector” Michael P. Hamel and Charles M. Schweik. First Monday Journal, Volume 14, Number 1-5 January 2009.  (http://www.uic.edu/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/2313/2065)
2. “Open Source Software Institute Website” (http://www.oss-institute.org/)