Process code for software procurement

4c. Integration

This section will help you:

Embed software in your organization’s social and bureaucratic infrastructure

Create clear plans for staff training and software maintenance

Join a community of practice

Common challenges

You may encounter these frictions as you do the work of integration. These are challenges the Recommended actions are designed to solve, or that may arise as you take those actions.

Relying on a single “champion”

It is often passionate champions who take on the responsibility of forward-thinking software work. Ongoing software maintenance and staff training can disappear if this protagonist burns out, encounters too many barriers, or leaves the organization.

Lack of resources for lifetime ownership and maintenance

A contract is not the end of a procurement process, nor is final product delivery. It is important to have a detailed plan for ongoing use and maintenance.

Governance between different organizations

When it comes to governing open source projects, political—not technical—skills are required. Discussing new features, allocating responsibilities, and pooling funds are all governance challenges that come with shared software.

Recommended actions

1. Documentation

It is crucial to document the software thoroughly. This includes technical documentation as well as operational documentation.

Technical documentation

This includes overall architecture, modular integration protocols, APIs, specific module function, ongoing maintenance considerations.

Operational documentation

This includes what end users should be aware of, how to train new users, and best practices for getting the most out of the software

Ensure the technical team and product owner collaborate on writing thorough documentation

Make sure that this is easily accessible, there is a clear process for updating it, and it is embedded in the training and maintenance plan

2. Creating a training and maintenance plan

There should be a robust plan for ongoing staff training and software maintenance. These can be time- and budget-intensive, so be sure to allocate resources appropriately. Both should be continuously updated as working drafts throughout the software development process, and completed when all features are built and perform at a satisfactory level.

Small incremental changes are best practice in open source development

It minimizes the risk of breaking dependencies. When everyone working on the code is in sync, any changes affect each other with minimal disturbance.

Create a maintenance plan

This should include:

Regular (annual) performance audits—for the software itself, and the processes that it supports.

Staff training plan to onboard new users in the future.

Staff time for software maintenance and updating (particularly if the city’s digital infrastructure changes in ways that affect the software performance).

Strategies for sharing with other jurisdictions (if it is custom software or OSS).

3. Releasing code under an open source license

Many national governments recommend that agencies or subnational government organizations who have developed their own software should release the code under an open source license. That way, all agencies can benefit from the code, and the burden of ongoing maintenance and support is shared.

Many governments have guidelines for choosing licenses specific to their legislative context

For example, if your open source project is an adaptation or derivative of an existing open source project, the best practice is to use the same license as the original; if it is a new open source project, the license you select will depend on the desired outcome and the licensing of any third-party software used in your project.

Choose an open source software license, and a version control platform

If it isn’t already on one, transition the code to a distributed platform like GitHub.

4. Joining a community of practice

If you used open source or built custom software, you will benefit from having a community of practice—others who use and maintain the software together. When considering collaboration, take the time to align with potential partners. Converse with your counterparts in other government or public sector agencies to gain a better understanding of what their needs are, where alignment can increase, and what shape your collaboration should take.

Play The Governance Game

This great resource from the Foundation for Public Code is “an interactive game exploring governance of a public codebase. It helps participants reflect on what governance means for a codebase, the complexity around it, and surfaces issues worth considering during set up.”

Link to The Governance Game

Form a community of practice

You might join an existing community that supports your specific software, create an entirely new community around your new software, or activate an existing network (like a Provincial CIO network) and create an open source software committee within it.

The value of collaboration

Collaboration on open source software is a win-win. The software you build, or the adaptations you make, will be useful to other jurisdictions as well. Open source software performs better and becomes more secure as the community around it grows. Each user benefits from continuous improvements to software (in the form of updates, new features or security improvements). It is therefore in each user’s best interest to contribute, and to add more contributing users.

For government organizations, another benefit of collaboration is that they do not need to constantly reinvent the wheel. When source code is released under an open source license, any jurisdiction can make small software adaptations to ensure that the software is best-fit to local use cases, regulations and standards. When a core set of functionalities are shared, each jurisdiction’s time, effort and resources can be focused on making small adaptations to fit the software to their local context (rather than building a full set of core functionalities from scratch). Knowledge and resource sharing help partners with less experience in open source software to build capacity.

Takeaways

Create or complete the following outputs.