Working in the open with a sense of humility and community

I was first introduced to the concepts of Open Source Software, while studying computer science at University Laval. I had a teacher who kept talking about a kind of software that uses a code visible to and editable by everyone, to benefit end users.

Coming from a world where I had to pay my hard earned money as a student for computer games and programs while actually learning about maximizing corporations’ profit with software, it seemed like an odd concept for a business to be successful financially. Surely, they’d be crushed by competitors that would just steal their code and sell it for themselves.

Fast forward 20 years, as a Senior Developer for the Site Reliability Engineering (SRE) team at CDS, I now realize that not all software ends up being a perfect candidate for open source projects, but it’s possible to at least work in the open to a very large extent, especially in the government.

Take GC Notify as an example. This service has allowed the Government of Canada to send close to 63 million notifications as of today to our end users since November 2019. The core technology underneath was originally developed by the United Kingdom’s Government Digital Service and CDS adapted it to its users’ needs, including making it fully bilingual!

We saved a lot of time initially putting the service together because we didn’t have to start from scratch. We built upon an already mature product and we continued to work in the open so that others could build upon our own.

Knowing this, one may wonder why working in the open isn’t more widely adopted yet in government. I’ll try to explain what challenges to adopting open source I’ve observed through my years in the government and what worked for me to navigate them.

Working in the open is not easy

Working with the SRE team, I’m continuously exposed to the fact that most of the technology used today to provide modern services to our end users is either an open source project itself or relies heavily on multiple open source projects, whether we procured the solution or built it ourselves. In fact, these projects are so essential to the world’s entire technology infrastructure that the United States Senate is currently introducing a bipartisan Bill to secure open source software.

Working in the open, even if only internally at the start, can help departments and agencies build on top of each other’s work and research, without requiring lengthy and bureaucratic approval processes. This is why GCpedia and GCConnex, the internal collaboration platforms launched more than a decade ago, were so successful; because they enabled us to naturally find employees and teams who had similar challenges and help each other.

Working in the open increases the chances others may reuse our work and even collaborate with us. For example, if someone was to find a bug with GC Notify, they could jump on the project’s repository and create an issue, whether they’re a government employee or a member of the public. The team would be made aware and could investigate directly, even though we also have a more traditional form available on the website to contact them.

As public servants, we’re all subject to public scrutiny and criticism, which can be daunting for many of us and can impact how many rules and authorizations some teams may have to deal with to be granted permission to work in the open. That in itself can be quite the journey! This is all extra work and you’ll (probably) spend a lot of time convincing various groups and committees that it’s possible to work in the open in a secure way.

On a personal level the fear of making a mistake in public, or being judged on the quality of our decisions can be frightening and I understand the hesitation towards making your work available to others before it’s fully polished.

In other words, the way things are now makes it harder to work in the open by default, to no one’s specific fault. It’s just the way things have been for so long, even though the Digital Standards and the Policy on Service and Digital make working in the open such an important concept to adopt.

At CDS, we’ve been working in the open since our inception, making it easier for our employees to adhere to this principle naturally. However, we’re conscious that different departments may have a harder and longer journey ahead of them.

I believe that the effort required to work in the open is worth it and that it’s essential to continuing to improve our services for and with our users. It’s not an easy transition, but it’s possible to slowly adopt such practices by opening up internally throughout our organization and increasingly building our processes around continuous improvement (like this example from the Information Technology Strategy team at ESDC).

A certain dose of humility

I realize that working in the open may feel quite scary initially. It requires a good dose of humility and we need to realize that no one’s perfect. By working together, in the open, we can all strive to continue learning from one another.

In government, we typically follow strong project management principles and processes, which we tend to refer to as “waterfall”. While there’s value in those, the lessons learned in this approach are usually drawn after the project is completed. In theory, this should mean that future IT-enabled projects are increasingly successful, but it seems this isn’t the case in reality.

We need to listen to the end users and to encourage everyone to join us in our journey from the beginning to help identify things that could be better, propose solutions to solve some of the challenges that we could face, and learn from one another. And this means being open to suggestions and ideas that may not have come directly from a member of our team or from the initial “business requirements gathering” stage.

Having the humility to accept that everything can’t always be fully planned ahead of time and that someone else may have something to contribute is important and demonstrates that we’re ready to work together with our end users, for our end users, as a community.

A sense of community

It’s also important to realize that, in the software development world, the most successful open source projects are the ones that actively nurture the community: the people that are using and contributing to the project. While you can have a dedicated team of developers maintaining and adding new features to your software, it can’t compare in size and capacity with what a dynamic community brings to the table.

This community needs to be supported and welcomed in order to be successful, which means being honest about what you can and can’t accept as an external contribution. By being clear upfront, you can help make sure that people will be better prepared to join actively.

In fact, that’s why highly successful open source project teams often have community managers as part of their employees. Working in the open is not an added effort for them, it’s a strategy to go beyond the limits of their own team’s capacity!

Even CDS has the opportunity to continue improving on its ways of working. I can imagine us further opening and building up our ability and capacity to manage communities around our open source projects through fostering ways of working that make it easier for our teams to incorporate external contributions.

For example, we could look into setting up a community management role at some point or help current development teams set their work methods that makes it easier for them to incorporate external contributions.

Join the community

Here at CDS, we try to work in the open as much as possible because we believe in the value it can bring to the end users and even ourselves.

And we encourage you to join us, as government teams, by making your own work available for contributions from the public, and/or as end users by looking up our projects and helping us find ways to make them better.

It might not be easy and can even be scary the first time. But with a good dose of humility and a bit of courage, you too can create or join an amazing community. If you need a little help getting started, reach out to us (by email)!

We’re all in this together!