Open source collaboration: Two cases in the U.S. public sector
First Monday

Open source collaboration: Two cases in the U.S. public sector by Michael P. Hamel and Charles M. Schweik

Globally, there is an emergence of open source consortia focused on the sharing of resources and code, and a desire to promote an open source approach generally. In this paper, we describe our findings from interviews with participants working in two relatively new consortia in the government sector: the Government Open Code Collaborative or GOCC, and the Open Source Software Institute or OSSI. For each case we consider six major questions: (1) How and why did these collaborative efforts begin? (2) What are their motivations? (3) How are these collaborative efforts governed? (4) What communication and collaborative infrastructure do they utilize? (5) What software do they focus on? and, (6) What is their current status? Our findings suggest that incentives, membership structures, stable paid staff, concentrated focus and attention to the creation and delivery of “value” to participating organizations are important factors leading to successful open source consortia.


Case 1: The Government Open Code Collaborative (GOCC)
Case 2: Open Source Software Institute (OSSI)
Case comparison




Central to the concept of open source [1] is Internet–based collaboration or collective action which can occur at two levels. At the first level individuals or groups collaborate on specific software projects. At the second level there is an effort to create collaborations, consortia, or “federations” around the concept of sharing code and resources, and to promote the idea of open source in general. Most of the existing literature on open source focuses on the former: case studies of specific projects or quantitative studies using data harvested from open source hosting facilities such as (see for example, Feller, et al., 2005). Less is known about the latter — open source consortia or federations — in part, because few exist and also because they are a relatively new phenomenon. But these consortia are beginning to emerge, and our sense is that we will see more of this in the future.

With this “open source collaboration” idea emerging in various domains, we set out to investigate to what degree it is occurring in the United States public sector. In general we find that, while there are higher–level efforts promoting collaboration between government entities or between government entities and private entities, these efforts are still fairly uncommon. In this paper we report our findings from interviews with participants working in the two U.S.–based public sector open source consortia we were able to identify: the Government Open Code Collaborative or GOCC, and the Open Source Software Institute or OSSI.

We begin this paper with a brief review of the literature, which includes research on open source software generally, motivations of participants, and common governance structures in open source collaborations. Following this review, we describe our methodology and report our findings from six major questions: (1) How and why did these collaborative efforts begin? (2) What are their motivations? (3) How are these collaborative efforts governed? (4) What communication and collaborative infrastructure do they utilize? (5) What software do they focus on? and, (6) What is their current status? After summarizing our findings for each case, we provide a comparative analysis of these issues, and present final conclusions related to factors that might contribute to the success or failure of such collaborative endeavors.




Motivations of developers and organizations in open source

While there is currently a limited amount of research focusing specifically on open source in the public sector, existing literature provides several insights into the factors that motivate individuals and firms to participate in open source collaborations. On the individual level, personal and professional needs have been seen as major drivers of participation in these collaborations. Meeting needs, whether they be breaking free from large software companies (Bonaccorsi and Rossi, 2006), or meeting new software and programming requirements, tends to be an important factor leading to participation (Lakhani and von Hippel, 2003; Shah, 2006). In reviewing the literature on collaborative alliances, Gray and Wood (1991) suggest that factors motivating individuals or groups to collaborate include a high level of interdependence, a shared desire to effect change, a shared understanding of a problem, and a desire to gain a competitive advantage.

The motivations of individuals and firms often overlap, but there are important differences. Recent work has found that firms are typically motivated by economic and technical benefits, while individuals often become involved to fulfill social needs (Joode, et al., 2006; Bonaccorsi and Rossi, 2006). Firms are typically motivated by the ability to experiment with a new software development model, evaluate the competition, boost public relations (by contributing to a public good), or to develop a new profit opportunity (Lerner and Tirole, 2005). In terms of the public sector specifically, there are several potential benefits in the deployment and use of open source in public settings, including potential cost savings, the avoidance of vendor lock–in, the sharing of resources between agencies or across governments and code transparency (which might be vital in certain application domains, such as e–voting).

Collaborative governance

While there is a lack of literature in regard to open source project governance in the public sector, there is a growing body of literature related to open source software and government collaboration generally. The governance structure of a collaborative effort can greatly impact the level of participation (Shah, 2006). Recruiting participants is crucial and often difficult in collaborative efforts, as is the ability to meet the expectations of participants and achieve buy–in. Research also shows that it is important to show potential participants that the benefits of participation will outweigh the cost and risk (Fedorowicz, et al., 2006). Looking at cultural change and open source methods, Neus and Scherf (2005) conclude that having passionate people, a simple structure, and a plan to start small and grow fast are important factors in successful open source collaboration.

The literature also suggests that leadership is an important component in an open source collaboration, particularly in creating an agenda, developing goals, and ensuring that the project continues to move forward without splintering (Lerner and Tirole, 2005). In terms of leadership structure, Howison, et al. (2006) found that the majority of successful open source projects large and small retained a single leader for long periods of time, while Fedorowicz, et al. (2006) argues that it is important that there be champions from all participating organizations, not just one lead champion.

In addition, significant shifts have occurred in the types of approaches to open source software development. We typically think of open source development as community–based efforts, or what Raymond (1998) would refer to as the bazaar model, in which many users of the code will make improvements that will then be offered back to the community, with participants typically only participating until their needs are met (Howison, et al., 2006). In recent years, there have been new approaches to open source software development; such as hybrid and firm–based collaborative efforts, which typically include private interests. While these approaches can increase flexibility and resource availability (Lin, 2006), these collaborations must also find ways to comply with open source norms and licensing, manage resources, align interests, and deal with ownership issues (Dahlander and Magnusson, 2005).

In the two cases of “consortium” we analyze below, we look at the motivations of the participants, and their approach to collaborative governance. In addition, we review how the consortia began, the composition of their communities, the collaborative infrastructure they use, the types of software they focus on and their status as of December, 2007.




Case selection

We set out initially to identify all higher–level “open source consortia” with a focus on the U.S. government sector. Our search involved looking for relevant published literature, contacting academic, open source and government contacts, and thorough Internet searches. We identified efforts to research, share and develop software for government, but some, such as the Interoperable Delivery of European eGovernment Services to Public Administrations, Businesses and Citizens (IDABC) in the European Union, and the Component Organization and Registration Environment (CORE) in the United States did not focus explicitly on open source software. After reviewing all of these efforts, we identified two that focus specifically on U.S. government open source collaboration: the GOCC and OSSI. As far as we can tell, these two groups represent the population of such government–focused open source collaborations in the United States. These two cases provide an interesting comparison in that they follow very different approaches to bringing open source software to the public sector.

Case research methodology

The research consisted of eight interviews, seven of which were conducted over the telephone, ranging from 45 minutes to one hour and 30 minutes; the eighth interview was a typed response to the interview questions, which were sent via e–mail. Snowball sampling was used to identify the four interviewees for each case. There was an effort to speak with a combination of participants that would be representative of the collaboration as a whole. The interview protocol was largely based on Schweik and English (2005) and questions fell under six categories: (1) personal involvement; (2) the history of the project; (3) the software developed, promoted or held by the organization; (4) factors leading to success and failure; (5) community attributes; and, (6) the governance and infrastructure of the effort. These categories were developed prior to analyzing the collected data based on the interview questions and responses (Yin, 1984). All interviews were tape–recorded and transcribed. Transana, which is a qualitative research software package, was used in the coding and analysis of the data collected. The data then went through three levels of coding: open coding to identify categories, axial coding to find interconnections (Neuman, 2004; Punch, 2005) and selective coding to illustrate themes (Neuman, 2004).



Case 1: The Government Open Code Collaborative (GOCC)

The GOCC, which began in 2003 and was officially launched in 2004, was a “voluntary collaboration between public sector entities and non–profit academic institutions created for the purposes of encouraging the sharing, at no cost, of computer code developed for and by government entities ...” (Government Open Code Collaborative, 2005). The organization focused on collaboration between state and local level government organizations, and allowed limited access to academic institutions. The GOCC was generally seen as a repository for open source code to be reused by government entities, but the collaboration also saw itself as a place for government entities to share best practices and collaborate on code development. The hope was that the collaboration would help to reduce the cost of information technology within government and promote innovation through the sharing of investments and improvements to a large network of like agencies (GOCC, 2004a). As one GOCC participant put it, “we have very similar problems, why don’t we solve them once and share them?”


The story of the GOCC really begins before the organization was established, with a few interested parties in government and academia. Public officials, like Patrick McCormick, who was the Chief Information Officer for the City of Somerville, Massachusetts, had been working with open source software in an effort to create high quality services on a budget. As McCormick observed, at the same time, then Governor Mitt Romney brought in a secretary of administration and finance and a chief information officer who believed in the advantages of open source. Soon after, the Massachusetts Office of Administration and Finance began a discussion around open source, and this discussion would eventually lead to a policy directing state agencies to consider all information technology solutions, including open source (Commonwealth of Massachusetts, 2004). In December of 2003, the Commonwealth of Massachusetts, along with Harvard University and the Massachusetts Institute of Technology sponsored an event, the Open Code in Government Initiative, which was meant to determine interest in a government code sharing organization. This initial gathering led to the creation of the GOCC and the development of the governance structure, rules, and licensing approaches the organization would follow.

The community

At its peak, the GOCC had about 20 member organizations, primarily state agencies and municipal governments, plus one academic institution. Of the 20 member organizations, very few played an active role; the States of Massachusetts, Rhode Island and Texas, and the City of Newport News, Virginia seem to have carried the weight of the organization. Beyond memberships, there were an estimated 100 observers who were either interested in participating without belonging to a member organization or were interested in watching the organization evolve. Those involved with the GOCC effort had a tendency to come to the organization “already using [open source software] and enthusiastic,” as one participant put it. While participants were typically from state and local governments, there were very broad interests among the members; however, membership numbers were not large enough to develop specialized sub–groups based on the wants and needs of participants.


Members of the GOCC effort felt they had a remarkable opportunity to cut the cost of information technology and develop innovative solutions within their organizations. Members believed strongly that “government should only pay once” and that investments in open source development could really pay off in the government context. The standard “open source derivative” idea applies. If one organization develops a useful and transferable piece of code, other organizations could pick up that code, make improvements to it, and make these improvements available to others, including the original organization. But one local government interviewee went even further, saying , “if [the code is] better value [2], longer lasting, and a more open standard [3] — it might even be a part of our responsibility [to use open–source solutions].” In addition, interviewees expressed a sense of pride and satisfaction in finding alternatives to pre–packaged software that does not always fit organizational needs well. Another participant noted that government organizations have pretty complicated demands, work with a software market that is limited, and have meager resources. Given this situation, according to this participant, it is no surprise that some of the proprietary software is not particularly good at meeting government needs, making open source software a more viable option.

Governance and memberships

The GOCC had a fairly well–defined operating agreement, which outlined the legal requirements and organizational governance structure of the organization. It also had an extensive terms–of–use agreement, outlining how members could or could not use the Web site ( At the top of the organization’s structure was an unpaid, elected chairperson who served a one–year term and was responsible for making the executive decisions for the organization. Officers were also elected annually; these positions included a municipal representative, technical lead, and policy lead (GOCC, 2004a). A volunteer program coordinator and a repository administrator held administrative roles in the organization (GOCC, 2004b; personal communication, 26 April 2007). It is important to note that the GOCC was a virtual collaboration, and the organization had no physical presence.

There was no fee to become a member of the GOCC, however, membership was only open to “federal, state or local government, an authority or other sub–national public sector entity of the United States” (GOCC, 2004a). To become a signatory member of the GOCC, authorization was required at the highest level of the member organization. Interested parties that did not belong to an organization that had signed the operating agreement could be involved in the collaboration as “observers”; however, these observers were required to be sponsored by an active member. The major differences between the two classifications were that members would be able to upload and download all code, and had voting rights, while observers could only download select code and had no voting privileges (GOCC, 2004a). These two levels of participation were meant to address the legal concerns outlined below.

While there was some disagreement between interviewees over how well–defined the rules of the organization were, and the degree to which these were formally documented, all participants interviewed believe that the legal framework developed by the GOCC was its strongest point. Unlike typical open source collaborations, government organizations have to deal with a variety of laws that differ from state to state, which required the GOCC to consult with attorneys from each participating organization. These consultations resulted in a semi–gated community meant to allow government organizations to share code, without exposing the code to the private sector or the public. One of the primary hurdles is that governments often have laws in place to prohibit organizations from giving away public property; these laws were typically meant for another time, and do not reflect today’s digital reality. As one participant put it:

“While it wouldn’t matter much at lower levels of participation, we wanted GOCC members ... to have the authority to develop software, to be involved in the development of software that could be given away to other members ... some state laws say that it’s okay if you share it with other government agencies, the idea being that the private sector doesn’t directly benefit from it. The laws are probably structured to avoid somebody giving away desks from a school to their cousin who has a real estate company; you can see where it comes from ... .”

Although all of the participants interviewed thought the legal framework was necessary, this particular interviewee questioned whether having a semi–gated community created other problems, such as blocking potential volunteers from improving code.

Communications and collaborative infrastructure

The GOCC used a Web site with a built–in blog, relevant news stories and a software repository. The site also contained all governance documentation and membership lists. While participants were generally happy with the organization’s infrastructure, one participant believes that a way to create and document versions of the developed code would have been helpful. Another believes that the lack of infrastructure to collaborate on code creation itself was a major shortcoming. Early on, the group had regularly scheduled conference calls, usually three or four organizations participated in each session; however, participation waned over time. Web site activity also ceased, and while the organization relied on a listserv for a time, the organization is now inactive (more on this below). When the organization was active, there were face–to–face meetings, usually taking place at conferences of mutual interest. Participants felt that this face–to–face contact helped to maintain social capital and energize group efforts. In general, participants believe that the communication and collaboration approaches of the effort were appropriate.


The GOCC repository held only a handful of individual programs, and the code typically came from other non–exclusive open source code projects and repositories, or was donated by members who developed the code to meet very specific local needs. But participants found the code in the repository to be of “little value” (meaning the code was not appropriate or effective at addressing the wants and needs of members); in fact, the participants that we have spoken to were not sure if there had been any downloads from the repository. Although members did not find the code to be applicable to their organizations, they did believe that the software quality was high.

The GOCC was envisioned as a “keeper of the code,” rather than a technical support or software development organization in itself. The organization encouraged members to donate code, which could be downloaded and improved upon by other member organizations. All participants interviewed believe that continuity, in terms of an assurance that development and support of the software will continue, was important, although some felt this was more important than others. One municipal government participant said:

“... oh [continuity is] critical ... if that’s not addressed, no matter how good the software is, nobody will use it, nobody will want to risk their business on something that might function very well, but once it breaks you can’t fix it.”

Another participant echoed this point and noted that government organizations tend to be short–staffed, so they need to rely on external contracted support. On the other hand, one more participant stated that continuity should not be a major issue to organizations because “you can try it out, and if you like it, even if it is dropped, you will still be able to get your data out” and “if you like [the software, you can] hire a programmer to work on it, keep it running for you ... I know how inexpensive that can be.”

Current status

The GOCC has recently become inactive. Several factors contributed to this outcome. First, participants we spoke with noted that being an all volunteer effort, the GOCC was not the primary concern of any of the members, and as other projects and responsibilities arose, it was not uncommon for a participant to cease activity for some period of time. Related to this was that no dedicated resources were contributed to the project. Second, there was no specific project that they could use to demonstrate collaborative success and motivate further collaboration. And third was the departure of the elected chairperson from the organization and his position in state government. While there were efforts by members to fill gaps in leadership, the organization failed to elect a replacement chairperson, leaving the effort without a strong central leader.

But even with the demise of the GOCC as a collaborative virtual organization, many of the participants are still very interested in and involved with open source software (for example, some participated in the recent Government Open Source Conference ( Interviewees noted that there are ongoing efforts to salvage some components of the GOCC, such as the software repository.

In sum, the GOCC case shows that maintaining an all–volunteer collaborative effort between public employees across different government organizations is challenging. Some state–level legislation created barriers in their ability to create truly open (as opposed to gated) collaborations, and a lack of focus on creating and maintaining products of value for participants led to lower participation rates. Finally, the loss of the chairperson from the once active organization further reduced member motivation to collaborate.



Case 2: Open Source Software Institute (OSSI)

The OSSI (, which began in 2001, is a non–profit organization whose mission is to, “promote the development and implementation of open source software solutions within Federal, state, and municipal government agencies and academic entities” (Weathersby, 2007). The organization acts as a facilitator between government entities and private firms aiding in the process of adoption, development, and implementation of open source software solutions. While the group has a strong affiliation with the U.S. Department of Defense (DoD), they are interested in all levels of government where opportunities exist (Weathersby, 2007).

The OSSI sees itself as having three major roles: policy advocate, research and development facilitator, and policy consortium. While the mission of the OSSI has not evolved much over time, the work of the organization has. Participants note that the group has gone from working on small and limited research and development requests, to working on multiple projects and more mission–critical government requirements.

Participants openly acknowledge that there is an “entrepreneurial perspective in the project,” and although their objective is to promote open source software, they do not oppose the use of proprietary software; in fact, some of the major players in the group develop and market proprietary software packages. Participants generally do not see the collaboration as one that develops software (although they do on occasion) but rather as a trade association. John Weathersby, Executive Director and founder of the OSSI, put it this way: “we want to help drive business opportunities to our members, but what we really try to focus on is helping to create a receptive business environment.”


The OSSI began its operation because individuals who would later be involved in the effort saw a need and an opportunity. While government organizations were “reinventing the wheel” and getting tied down with proprietary data formats and forced software upgrades, examples of high–quality open source software emerged and gained a following. This posed a threat to the proprietary software industry, and as private organizations watched these efforts grow, some firms saw business opportunities in supporting open source efforts. John Weathersby saw an opportunity in connecting private firms with government organizations looking to meet their needs with open source solutions. With this vision of facilitating the move toward open source solutions in government, the OSSI was born.

The community

The OSSI community is diverse, but its membership is primarily made up of private–sector open source interests. The organization also has a strong following, with over 1,000 individuals on their mailing list, 16 major corporate sponsors, and a number of other private and public entities that support the organization (as of the end of 2007). While the organization tries to remain focused on specific areas — for instance, they are now primarily focused on national defense — the group’s base has a variety of interests at all levels of government. For example, at the state and local level the organization is currently working to develop a suite of applications for criminal justice. Although there are both public and private entities involved in the effort, the public sector interests are most often contracting or creating agreements with the OSSI to help develop open source strategies, study open source solutions and possibilities or find the appropriate mix of talents to develop software.


While the OSSI participants seem to genuinely believe in the benefits of open source, it is clear that business interests are the primary driver. As one participant put it, “we expect to make a living doing this, but we truly believe it’s better for the government ... [the OSSI] helps gain access to those people in government that are thinking of the same thing.” Participants underscored the fact that the software industry is changing, and many companies that traditionally market proprietary software understand that. Often companies are willing to invest in open source because they are able to tap into the support and hardware markets, rather than focusing on profits from the software market. As one interviewee put it, “if you’re saving money on the software, you have more to spend on hardware and support services.”

Although selling hardware and support services are a highly motivating factor for some members, others are willing to provide volunteer or cheap services to create brand awareness or to work toward building new connections with a government agency. By volunteering resources to the OSSI, they have been able to point to a concrete product, working with a visible organization and government agencies. While the general body of open source literature emphasizes recognition or author attribution as an important factor in motivating (usually individual, volunteer) participation (see, for example, Weber, 2004; or Lerner and Tirole, 2005), it seems likely that this type of recognition may be more pronounced when promoting a firm’s reputation when working with or for the government.

Governance and memberships

The OSSI is governed by a comprehensive set of bylaws. At the top of the organization is the executive director, who is elected annually by the board of directors and is responsible for the day to day operations of the organization. As is typical with nonprofit organizations, the board of directors deals with the strategic decisions facing the organization, and has voting privileges, while the advisory board simply advises the organization on “strategic and tactical topics and issues” (Weathersby, 2007).

The OSSI has a complex membership structure, composed of organizations, rather than individuals, which has evolved over time. Although the membership schedule found within the bylaws shows three types of membership — corporate, government agency and academic institution — since the bylaws were established, two new types of membership have been added, community and associate, which were designed for those, “who wish to associate with OSSI and support our efforts through reciprocal, in–kind or monetary contributions” (OSSI, 2007). Graduated fees have also been instituted for corporate membership. These fees help the organization to fund the executive director and administrative positions. The executive director of the program notes that “you’ve got to continually tweak the value proposition so that it’s worth the sponsorship to all involved,” meaning that it is necessary for the organization to evolve to maintain and gain public and private involvement. For example, graduated membership fees were a “tweak” seen as an opportunity to enhance the membership base. The OSSI currently has 16 corporate, three government, one academic and a number of associate and community members. And as stated earlier, the organization also has over 1,000 interested individuals (non–members) from inside and outside of member organizations. Non–members have access to general information about what is happening within the organization and the open source world, but do not have access to project specific information.

While the organization does have formal governance and membership structures in place, participants say that the rules of the organization tend to be unwritten but understood, social norms. Participants are quick to point out that the organization is flexible and tries to adapt to the market, clients and members.

Communications and collaborative infrastructure

Although the OSSI does have physical offices, most of the work is done virtually. The organization has a public Web site and tends to use wikis, e–mail, and instant messaging for collaboration on specific projects. Some members, including the executive director, travel to Washington, D.C. regularly to meet with public agencies involved in the projects. Members of the organization typically frequent the same conferencing events, such as Linux World; and believe these events are ideal for bringing members together for face–to–face interaction, which they consider to be an important factor in virtual collaboration. One participant noted that the organization is very project–oriented, and at one point there was an effort to schedule regular teleconferences at the organization level, however, most participants were not interested in learning about new projects, which was the primary discussion at these meetings — anyone interested in the project was likely already involved, having knowledge of the project through some other avenue, such as an e–mail. These scheduled meetings have evolved into general communications sent out to all participants, allowing those interested to get involved. The group does employ more sophisticated collaboration tools, such as version control systems when needed, on a case–by–case project basis. Participants believe that this mixture of communication tools and approaches has been appropriate and works well.


The software resulting from the OSSI’s efforts is generally facilitated, rather than developed, by the OSSI. That is to say the OSSI helps to bring private development firms, and government organizations together to develop open source products that meet specific governmental needs. Although members note that being open source does not in itself mean that it is high quality, they believe the software developed through their effort is of the highest quality, providing great value to the government organizations. The software produced is often mission–critical, and has been developed for organizations such as the DoD. The software that comes out of OSSI collaborations is under an open source license, which can vary depending on the particular project. While the organization believes in distribution of open source code without limits, in special cases, such as security concerns in DoD software, the code may not be available on the Web for reuse. The OSSI is currently working to develop a repository that will hold open source code for broad government reuse beyond their membership base.

Current state

Participants in the OSSI give the impression that the organization is doing well, and slowly expanding in terms of the number and importance of the projects the organization is involved in. The number of memberships and listserv subscribers continues to rise. There is a feeling among the participants that the organization will continue to do well as long as it is creating value (by both creating code that is appropriate and effective at meeting governmental needs, and helping private organizations to forge new business relationships) and evolving to meet the needs of member organizations and the government entities seeking services.

The primary insight from the case of the OSSI is that in an effort with multiple interests, knowing participant motivations and how to create value for all parties involved is critical to success. Equally important is having a stable leader who can devote a great deal of time and energy to the effort and keep members engaged. Having permanent paid staff may help to ensure that the organization continues to evolve and recognize opportunities.



Case comparison

While both the GOCC and the OSSI work to help government take advantage of the benefits of open source software, they take very different approaches. The GOCC acted as a repository for the sharing of code, and the OSSI acts as a trade association and organizer of projects. Participants in both groups seem to believe that their collaboration is, or was, well structured; however, members of the GOCC believe that there were some key components missing in their organization. While the OSSI has a well–defined organizational structure, participants have indicated that the organization is relatively flexible, and willing to change and evolve to better fit the needs of members and clients.

The communities and their motivations

The communities in these two efforts differ greatly. While the GOCC only allowed membership to public–sector organizations with approval at their highest level, the OSSI’s membership base is primarily private–sector participants. However, the OSSI’s public sector clients are critical to the efforts success. Furthermore, the OSSI does not restrict access to their general discussions, but does restrict access to project specific discussions. Both cases include members with a broad range of software application interests, and are interested in supporting a variety of open source needs, but the OSSI tends to focus on particular projects or areas and there is currently an emphasis on collaboration with the DoD. Beyond the code itself, the OSSI has a major emphasis on research and policy advocacy, allowing the group to take advantage of a variety of opportunities, such as the DoD’s Open Technology Development Road Map, a program aimed at new methodologies for technology development. Although some GOCC participants envisioned a time when there would be specialized sub–groups for different interest areas, throughout the life of the organization the focus remained broad. In fact, one participant said, “there was a conscious effort not to steer it ... [that] meant it was sometimes sort of adrift, waiting to catch the right wave or wind at sea.”

While at its peak, the GOCC had a relatively large number of participants (20 member organizations, about 100 observers), the OSSI has established a much larger community (19 full–member organizations, and over 1,000 other interested organizations and individuals). The smaller fully privileged membership base is similar between the two organizations, in that both require permission from the group’s management body. For the GOCC this is a legal issue, stemming from a variety of state laws prohibiting the sharing of government property. For the OSSI, the privileged membership is needed to support the OSSI organization (via a membership fee) and to create gated sub–projects, especially where software security concerns are an issue.

Motivations differ somewhat between these two groups. Members of the GOCC, who all represented government organizations, were motivated by the belief that “government should only pay once” and they should not be subjected to the release strategies of any particular vendor. They also desired software with open and transferable standards and customizable options and saw their effort as an attempt to reduce software development redundancy across public sector settings, as well as to create opportunities to share scarce programming resources. Members of the OSSI are also motivated by these beliefs, but they also have an interest in paid software development and services, as well as hardware and support sales. Members of both collaborations believe that open source solutions can fill gaps left by proprietary software, and that open source should be considered as an alternative when considering software purchases in the public sector. Neither organization is necessarily against the use of proprietary software, and participants from both efforts were quick to point out that support and hardware expenses should be a part of any software consideration.

Nearly all of the participants from both efforts mentioned that value — or the creation of a product or relationship that is both appropriate and effective at addressing the wants and needs of member organizations or their clients — is critical in open source collaboration. One GOCC participant said, “unless it adds value to somebody else, this is going nowhere — it has to add value.” According to John Weathersby, Executive Director of the OSSI:

“... the project is firmly based on our ability to continue to provide value, whether through development of software resources, continued interaction and promotion of policy issues, encouragement of open source service adoption by commercial entities or general advocacy within government decision–making bodies ... as long as you are providing value, you have a great chance of continued success, but if you become complacent, then your value declines and you will be eliminated.”

One participant in the GOCC effort felt that while the group expected the value to come out of reuse and improvement of member provided code, this could have been a flaw in the organization’s framework, as the GOCC membership base may have been too small to create the vast improvements in code that are seen in the open source community at large.

While neither organization has a support system in place for the software they hold or produce, participants generally believe that some assurance of continuity of specific pieces of code is important. One GOCC participant said:

“[assurance of code is] critical, particularly because government entities do not typically have large staffs, they rely on external support, they’re going to look carefully at how the software will be supported and maintained. They look carefully at what the resources are and how they can get training for the software ... particularly anything mission critical or deployed on a broad base of users that requires a lot of support.”

An OSSI respondent had this to say, “continuity is critical to the continued long–term success of this project. As with most open source solutions, your value is based on your ability to provide continual updates ... .”


Both the GOCC and the OSSI have strong documentation on governance, and both organizations have a top–level elected manager position. While the GOCC had elected officer positions (municipal representative, technical lead, policy lead), the OSSI has a board of directors that deals with strategic decisions, and an advisory board that provides advice for these decisions. Participants in both groups mentioned strong leadership as a key success factor in open source collaborations working with government entities. In fact, interviewees from both organizations believe that having a strong champion who can spend a great deal of time working with the organization is critical; one participant said, “the key is a passionate director.” While both organizations had strong leadership, the GOCC lost its initial leader. One participant noted, “[with his] departure, some of the vision and the executive support for the project dissipated.” The Executive Director of the OSSI effort, John Weathersby, remains at the helm and members feel strongly that his energy has led the initiative to success. One participant said “[you need someone who can] show each of these communities how they can benefit by contributing something. It’s not easy, it takes persistence, it takes passion, and it takes an understanding of the interdynamics.” Another participant said, “you really need someone where their sole mission in life is to push this agenda forward and move the organization forward, otherwise it’s just a club that gets together. You really need dedicated resources if you’re going to be successful.”

Membership is the major difference between the two organizations. While membership was free (as in cost) in the GOCC (as long as there was written approval by high–level management of the member organization), the OSSI requires a membership fee to gain full privileges. These fees are used to compensate the small staff, and are used to support their projects. Participants in the OSSI effort tend to think that funding is an important factor, primarily because “for something like this you need to have somebody dedicated full-time.” GOCC participants, on the other hand, generally believe that having a paid staff is not necessary, but most believe it would help. Participants also note that there is some funding involved, even if that is just the cost of code development or staff time incurred by a member organization (although it should be noted that little code development took place).

Legal issues were a much greater concern to members of the GOCC effort. The OSSI’s tendency to focus on a single client and deal with legal issues on a case–by–case basis might explain this. Concurrent cooperation between organizations that have conflicting legal environments (e.g., state policies) sets the GOCC apart from the OSSI. GOCC members are proud of the legal framework they developed and believe that it brought with it a higher level of trust across their community, which gave them a level of comfort that can be difficult to attain in a government setting.

Communications and collaborative infrastructure

Both the GOCC and the OSSI have a similar communication structure in place. Members of the organizations collaborate virtually using Web sites, wikis, blogs, e–mail and listservs and conference calls. Participants from both collaborations are used to working in this type of environment, and believe that it is an appropriate approach. A concern of GOCC members was the lack of infrastructure for versioning, collaborative development, and documentation of code. The OSSI also lacks a central development infrastructure, however, these needs are addressed on a project–by–project basis and participants believe this approach has worked well. To compliment online interactions, both projects attempted scheduled organization–wide conference calls, but in both cases there was very limited interest among participants.

Participants from both organizations believe that virtual collaboration works well, but they also believe that face–to–face contact is very important and this is supported in much of the “virtual team” literature (Elron and Vigoda, 2003). Meeting in person appears to build trust and social capital within the collaboration, a theme also found in collective action as well as open source literature, which participants tend to see as a requirement for success. Although face–to–face contact is limited in both groups, they take a similar approach, which is meeting at events of mutual interest, such as Linux World, the Government Open Source Conference (GOSCON), etc.

While the GOCC and the OSSI both seek to help governments take advantage of open source solutions, the products of the two organizations differ quite substantially. Participants in the GOCC effort are unaware of any new software that has been developed as a result of their collaboration, and were surprised with the lack of transferable code held by members prior to the collaboration. What the organization did create was a community of like–minded individuals who continue to communicate with one another and the promise of code. Some of the individuals who were involved with the GOCC now have prominent roles in other open source collaborations. The OSSI also created a community of like–minded individuals and organizations, but has also aided in the development of “mission critical” software for organizations such as the DoD. However, some of this code is created for specific organizations and may not be readily available to other organizations. Beyond software, the OSSI has been successful in securing research and development projects and helping government agencies to better understand how they might use open source solutions.




We opened this paper by noting that there were two levels of collaboration in open source — one at the project level, where teams are working on a specific software project, and another at a “consortium” level, where organizations are working to coordinate multiple projects or undertake other coordinated efforts to develop and support open source software initiatives. We noted that there are emerging open source consortia and asked to what degree such consortia were developing with a specific focus on government sector open source solutions. The objective of the paper was to first identify existing consortia with a focus on the United States public sector and open source, and then understand how they began, what their motivations were, how they are governed, how they communicate and collaborate, and what their current status is. The results of our comparative analysis of the two identified consortia — the GOCC and the OSSI — have led us to several conclusions.

Overall, the GOCC and OSSI have similar goals (like the promotion of open source technologies and the development of open standards), but differ in many important respects in terms of the methods used to reach these goals. This comparison seems to shed light on some key factors that have led the OSSI to continue moving forward, and the GOCC to become dormant. Through our comparison of these two cases, we are able to identify four key areas which require attention when creating a consortia to mobilize collective action in open source (or other domains): (1) incentives and membership structures; (2) the possible establishment of some permanent staff to drive the effort with some method to finance this staff; (3) a concentrated focus on some agreed upon initiatives; and, (4) constant attention to the creation and delivery of “value” to participating organizations.

Incentives and membership structures

Based on our analysis it appears that a more flexible, as opposed to a firm, gated community and incentives are important in order to keep members engaged. As discussed earlier, the GOCC was an effort driven entirely by government sector employees, with no private sector partners allowed. The GOCC believed the legal structure developed to satisfy a variety of state regulatory environments was one of its greatest achievements, but it also restricted any involvement with the private sector, which limited the pool of potential resources and collaborators. The OSSI’s membership base, on the other hand, is largely driven by employees in the private sector seeking economic opportunities with government agencies. 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).

Staff and financing

In addition to incentive structures for participants, consortia must consider staff and financing issues. Our comparative analysis of the GOCC and the OSSI reveals the importance of paid staff members and strong leadership in maintaining the momentum of open source consortia. As discussed above in the case comparison, the GOCC was an all–volunteer effort with an unpaid chair elected by the members, while the OSSI’s board of directors elects a paid, full–time, dedicated director. The dedicated leadership in the OSSI appears to help keep members involved. The OSSI also has paid staff members helping the organization stay focused on its mission and motivated to create value in order to keep the organization going. The GOCC, on the other hand, had no such permanent staff and relied on volunteers, who were busy with full–time jobs, to keep the collaboration moving forward. The hope was there, but no specific project(s) emerged to help keep participants focused and collaborating. Furthermore, the loss of key volunteer leadership in the GOCC also contributed to a loss in momentum. Work from, Howison, et al. (2006) on successful open source collaboration has also suggested that strong leadership is an important component of successful collaboration.

Focus on initiatives

The third key factor contributing to successful collaboration is a targeted focus on agreed upon initiatives. As our case comparison reveals, the GOCC cast its net widely, with no real focus on specific projects. The OSSI, on the other hand, is much more project driven, with a concerted effort to establish connections between government clients and firms that could develop software and deliver services to meet their needs. Participants in both groups believe that focus is an important component of collaborative success, and in the case of the GOCC, lack of focus was seen as factor leading to the organization’s decline. Focused projects deliver economic rewards, help to keep members engaged with the organization, and create a track record of collaborative success. Government participants have a motivation to work with the OSSI because it represents a body of potential partners with skills in the open source domain that government agencies need.

Creation and delivery of value

Finally, the continual creation and delivery of value to members is a key factor in attaining collaborative success. Our case comparison shows that the OSSI maintains a greater degree of flexibility, allowing the organization to evolve in an effort to provide “value” to its members and clients. Lack of participation and focus in the GOCC effort was seen as an obstacle to creating the value members were hoping to receive.

Although this analysis focused on two specific efforts, our findings provide useful insights for new and existing open source collaborations, particularly those in the public sector. Our findings also provide a window into the world of open source collaborations for public organizations who will continue to face questions about the use of open source software in government. This is particularly valuable as we expect to see more of these collaborative efforts in the future. Finally, these findings also provide a strong basis for future research and may be useful in comparing similar efforts in other sectors or comparative analysis across countries. End of article


About the authors

Michael P. Hamel is a Business Analyst with the City of Boston, Mass. and a research fellow at the National Center for Digital Government. His research is focused on the use of open source software in the public sector.
E–mail: michael [dot] p [dot] hamel [at] gmail [dot] com

Charles M. Schweik is an Associate Professor with a joint appointment shared between the Department of Natural Resources Conservation and the Center for Public Policy and Administration at the University of Massachusetts, Amherst. He is also the Associate Director of the National Center for Digital Government, and an affiliated researcher with the Science, Technology, and Society Initiative at the University of Massachusetts, Amherst. His research focuses on environmental management and policy, public sector information technology, and the intersection of those domains.
E–mail: cschweik [at] pubpol [dot] umass [dot] edu



Support for this study was provided by grants from the U.S. National Science Foundation (NSFIIS 0447623 and 0630239). Any opinions, findings, conclusions, or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.

We would also like to give a very special thanks to John Weathersby, Executive Director of the Open Source Software Institute and Andy Stein, Director of Information Technology for the City of Newport News, Virginia for their insights, support, candor, and help in coordinating the project. We would also like to thank the following individuals for providing both their time and insights. This project would not have been possible without their participation:
Michael Balma, Hewlett–Packard
Deborah Bryant, Open Source Lab
John Allen Lever, United State Navy
Mark Lucas, RadiantBlue Technologies
Patrick McCormick , Former CIO — Somerville, Massachusetts
Kent Morrison, City of Steamboat Springs, Colorado
Scott Porter, Foundation for Free and Open Source Software in Government
Bill Welty, California Air Resources Board.



1. In this work, the phrase “open source” refers both to free/libre and open source software.

2. “Value” meaning a product that is better at addressing organizational needs than the alternatives.

3. “Open standards” are standards made available to the general public and are developed (or approved) and maintained via a collaborative and consensus driven process. “Open standards facilitate interoperability and data exchange among different products or services and are intended for widespread adoption.” (International Telecommunications Union, 2005)



Andrea Bonaccorsi and Cristina Rossi, 2006. “Comparing motivations of individual programmers and firms to take part in the open source movement: From community to business,” Knowledge Technology & Policy, volume 18, number 4 (December), pp. 40–64.

Commonwealth of Massachusetts, 2004. “Enterprise information technology acquisition policy ITD–APP–02,” at, accessed 10 August 2007.

Linus Dahlander and Mats G. Magnusson, 2005. “Relationships between open source software companies and communities: Observations from Nordic firms,” Research Policy, volume 34, number 4 (May), pp. 481–493.

Efrat Elron and Eran Vigoda, 2003. “Influence and political processes in virtual teams,” In: Cristina B. Gibson and Susan G. Cohen (editors). Virtual teams that work: Creating conditions for virtual team effectiveness. San Francisco: Jossey–Bass, pp. 317–334.

J. Fedorowicz, J.L. Gogan, and C.B. Williams, 2006. “The e–government collaboration challenge: Lessons from five case studies,” at, accessed on 13 February 2007.

Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani (editors), 2005. Perspectives on free and open source software. Cambridge, Mass.: MIT Press.

Barbara Gray and Donna J. Wood, 1991. “Collaborative alliances: Moving from practice to theory,” Journal of Applied Behavioral Science, volume 27, number 1, pp. 2–22.

Government Open Code Collaborative, 2005. “Welcome to the Government Open Code Collaborative Repository,” at, accessed 12 June 2007.

Government Open Code Collaborative, 2004a. “GOCC is launched,” at, accessed 1 April 2007.

Government Open Code Collaborative, 2004b. “Government open code collaborative operating agreement,” at, accessed 28 March 2007.

J. Howison, K. Inoue, and K. Crowston, 2006. “Social dynamics of free and open source team communications,” at, accessed 10 April 2007.

International Telecommunications Union, 2005. “TSB directors’s ad hoc group on IPR: Definition of ‘open standards’,” at, accessed 7 October 2007.

Ruben van Wendel Joode, Yuwei Lin, and Shay David, 2006. “Rethinking free, libre and open source software,” Knowledge Technology & Policy, volume 18, number 4 (December), pp. 5–16.

Karim Lakhani and Eric A. von Hippel, 2003. “How open source software works: ‘Free’ user to user assistance,” Research Policy, volume 32, issue 6 (June), pp. 925–943, and at, accessed 12 April 2007.

Josh Lerner and Jean Tirole, 2005. “The economics of technology sharing: Open source and beyond,” Journal of Economic Perspectives, volume 19, number 2, pp. 99–120.

Yuwei Lin, 2006. “Hybrid innovation: The dynamics of collaboration between the FLOSS community and corporations,” Knowledge Technology & Policy, volume 18, number 4 (December), pp. 86–100.

Andreas Neus and Philipp Scherf, 2005. “Opening minds: Cultural change with the introduction of open–source collaboration methods,” IBM Systems Journal, volume 44, number 2 (June), pp. 215–225.

W. Lawrence Neuman, 2004. Basics of social research: Qualitative and quantitative approaches. Boston: Pearson.

Open Souce Software Institute (OSSI), 2007. “Community members,” at http://oss–, accessed 10 August 2007.

Keith F. Punch, 2005. Introduction to social research: Quantitative and qualitative approaches. Second edition. London: Sage.

Eric S. Raymond, 1998. “The cathedral and the bazaar,” First Monday, volume 3, number 3 (March), at, accessed 1 April 2007.

Charles M. Schweik and Robert English, 2007. “Tragedy of the FOSS commons? Investigating the institutional designs of the free/libre and open source software projects,” First Monday, volume 12, number 2 (February), at, accessed 21 December 2008.

S.K. Shah, 2006. “Motivation, governance, and the viability of hybrid forms in open source software,” Management Science, volume 52, number 7, pp. 1000–1014.

John Weathersby, 2007. “Open Source Software Institute operational overview,” at, accessed 12 June 2007.

Steven Weber, 2004. The success of open source. Cambridge, Mass: Harvard University Press.

Robert K. Yin, 1984. Case study research: Design and methods. Beverly Hills, Calif.: Sage.


Editorial history

Paper received 7 December 2008; accepted 18 December 2008.

Commons License
“Open source collaboration: Two cases in the U.S. public sector” by Michael P. Hamel and Charles M. Schweik
is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.

Open source collaboration: Two cases in the U.S. public sector
by Michael P. Hamel and Charles M. Schweik
First Monday, Volume 14, Number 1 - 5 January 2009

A Great Cities Initiative of the University of Illinois at Chicago University Library.

© First Monday, 1995-2017. ISSN 1396-0466.