Section 2: Strategies for Collaborating Across Jurisdictions on Open Source Software #

Despite the potential challenges, it is possible to create productive open source software collaborations interjurisdictionally.

Build a Governance Structure Intentionally #

Collaborations that start without a clear governance structure may struggle, especially if too many partners are involved. It may be difficult to agree on what collaboration model is being followed and determine appropriate roles for each partner.¹

When considering a collaboration, take the time to align with potential partners. Identifying a shared need or purpose for an open source application is one of the first steps to beginning a collaboration. By starting conversations with your counterparts in other government or public sector agencies, you will gain a better understanding of what their needs are, where there may be potential points of alignment, and what shape your collaboration should take.²

Once that initial contact has been established, partners can get into the specifics such as “planning and documenting the proposed governance structure, principles of working in the open, and their alignment on how to resource their shared work.”³ One way to approach these conversations is to use a tool like the Governance Game developed by the Foundation for Public Code: The Governance Game “an interactive game exploring governance of a public codebase. It helps participants reflect on what governances means for a codebase, the complexity around it, and surfaces issues worth considering during set up.”⁴

Create Communities of Practice around Open Source Software #

Open source champions across government agencies can form communities of practice around open source software. Tapping into pre-existing peer group networks of government staff responsible for delivering similar programs or services can be an effective way of developing and sharing open source software specific to certain areas of focus or use cases (e.g., transportation planning, asset management). CoPs with a general open source focus can be useful for exchanging knowledge on open source at an organizational level. CoPs can steward shared repositories of open source software modules and resources.

Create or Participate in a Pooled Purchasing Arrangement #

Procuring or developing open source software on your own isn’t always feasible, especially for small and mid-sized municipalities. With pooled procurement (also known as cooperative purchasing) you don’t need to bear the cost alone.⁵ Pooled purchasing increases the efficiency of a procurement process and reduces costs for participating organizations. The advantages of pooled purchasing for government include:

• Lower prices

• Quality controls

• Shortened delivery lead times

• Streamlined processes

• Access to alternative financing

• Technical cooperation

• Increased transparency and information sharing

Advantages also extend to suppliers:

• Repurposing existing / shared code

• Reduced transaction costs

• Service demand predictability (feature development and maintenance)

• Upfront financing for working capital and demand forecasting⁶

Creating or Joining a Cooperative Procurement

There are two main approaches to pooled purchasing. Joint solicitation (coordinating a shared process up-front) or “piggybacking” (sharing work that’s already been done across public agencies).⁷ These are the main steps to follow for joint solicitation:

1. The cooperative is formed when one or more parties identify a common requirement suitable for cooperative purchase and sign a written agreement to cooperate.

2. Lead party solicits proposals and awards contract(s).

3. Contract is available for use.

4. Participating entities sign an agreement (NASPO/WSCA calls it a “participating addendum”) in the specific contract(s). This is necessary to get users’ statutory requirements included as well as for the lead entity to administer efficiently.⁸

Piggybacking is a more ad-hoc approach. In the U.S., there are tools such as CoProcure that can help you find and join geographically and topically relevant products and solicitations. However, there is currently no ‘one-stop shop’ for cooperative purchasing opportunities in Canada; opportunities to piggyback on other organizations’ contracts will likely come through your connections to existing peer networks.

Properly Document Open Source Projects #

You can invest significant time and effort into developing a piece of open source software, but if no one else can understand what the software is and does, on a high level, and how the modules work, on a technical level, then the chances of its being adopted by others outside your team are low. To make it easier for others to adopt open source software you’ve developed, it’s essential to spend time properly documenting it.

Consider using the Standard for Public Code, “a set of criteria that supports public organizations in developing and maintaining software and policy together.”⁹ The Standard serves as a framework for governments and public agencies to develop their own open source projects in a way that is transparent, accountable, and understandable by others.

• Previous
• Next