Working in the Open: Part 1

This series of blog posts will explore the concept of “Working in the Open”. In this first entry, we will attempt to explain what it means and why we should make conscious efforts to work in the open by default, whether you are a software developer or not.

For over 40 years now, open source software has slowly taken over the world and is now present in every aspect of your life, even if you don’t realize it. It managed this feat not by forcing itself on people but by being open by default.

What

Before diving too much into the Why should I care?, let’s start with the What does it mean? At its most basic, working in the open means that your workspace, or part of it, is public and participatory. ¹

Public

Yes, it does mean that your work is visible to everyone, both your colleagues from other departments but also our citizens. It also means that other governments across the world may look at it and build on top of your great work.

Now, there are some nuances here (see the term “inner source”) as not everyone is ready to make the leap and go full open, although it should be the default stance based on our Policy on Digital and Service. In that case, teams are encouraged to open up their workspace to the entire organization, at the very least. And even internally to all GC departments.

Participatory

Note that by this definition, your workspace is not only discoverable and accessible to everyone who wishes to visit it but it is also configured to enable and encourage collaboration to your work itself. That means sharing your drafts and work in progress, your planned activities and tasks, your notes and, yes, your source code.

It’s not just “working out loud” and sharing the fact that you are doing “something”. It’s promoting your work so that others may hear about it but also clearly communicating your intent of working with all parties interested whenever they feel like contributing. It also implies that people can come on their own and start proposing changes to your work, not just when you share your screen during a weekly update meeting.

A study on distributed educational professional networks ² highlights 5 key practices for the success of working in the open:

• Public storytelling and context setting
• Enabling community contribution
• Rapid prototyping “in the wild”
• Public reflection and documentation
• Creating remixable work products

This is a critical set of conditions that enable open source projects to have thousands of people that may not even know each other to come and contribute together for the greater good of all.

Cultural

This is a very different approach than what most employees, both from the public and the private sector, are used to. Normally, people will work on a document or their part of a project for a while. Then, the document will be reviewed by a select group of individuals, either because they are already known by the employee’s team or because it’s the established process. Changes will then be made to the document based on the feedback and subsequent rounds of reviews will be done until a final approval is done. Then, more changes will be made again. Because a document is never perfect.

When you work in the open, feedback can be submitted live, as the document or the source code evolves. You still control the changes made to your work. Yet, you accept that you don’t know everything and that others may know more than you on a topic. And that’s absolutely OK because that’s the reality. It requires humility and a desire to be inclusive, accessible and to continuously learn.

Why

This is all great but why should you, a public servant, even care about working in the open?

Discoverability

We are more than 250,000 employees in the Government of Canada. Some departments have more than 25,000 employees. Shared drives, intranets and various collaboration platforms are very often closed by default. Working in the open makes your work discoverable

Files can be sensitive and they should be protected if that’s the case. But the workspaces themselves should be open by default so that we can collectively be able to share our work with our colleagues.

Yet, if anyone has tried collaborating with other departments or even with the private sector, you know it’s a technical nightmare and usually ends up being done via manually versioned documents in emails. That is very inefficient, error-prone and sometimes simply unrealistic.

Some may say that this is going to create information overload. Once again, note that working in the open is not imposing yourself to anyone else. It’s letting people interested in your work the chance to discover and to jump in when they are ready for it.

Reduction of work duplication

The traditional approach to plan and prioritize a long time ahead for work is aimed at minimizing the investment risks that organizations have to take to maintain their services for their users.

As such, organizations will set large processes aimed at harnessing needs and initiatives from all around its various teams. Each branch will have its own series of information gathering, filtering and prioritizing in order to submit project requests to the upper committees. Then, when all the silo’d planning is finally “done”, the organization will convey a committee of stakeholders, usually top executives, to sift through the remaining proposals. Multiply this by as many departments and agencies there is in a country’s government…

This probably seems like a good way to manage very large initiatives and bring similar efforts to light but it creates another series of steps for departments and teams to deliver value to citizens in the hope of avoiding duplication of work. It remains a very bureaucratic process requiring a lot of overhead and centralized control. And we still are dealing with a high amount of uncertainty since technology changes fast and the actual business requirements may evolve as well. By the time we are done harnessing the information, prioritizing the investments and getting ready for work to actually start, the context may already have changed. (We most likely will dive in this last topic in a different series of blog posts related to project vs product management)

By working in the open by default, releasing our work as open source and promoting its reuse across the whole government could help increase the adoption of solutions already in use and being developed across departments. Without the overhead and rigidity required by a central body but still aligned with our objectives of a modern and digital government. Because, in the end, we should all be aiming for the Digital Standards.

In reality, it could even open up opportunities of natural collaboration with other interested parties such as provincial and municipal governments and even the private sector without requiring any Memorandum of Understanding or contracts.

Economies of scale

In an organization where accountability is critical such as the government, we tend to increase the oversight and means of control of the spending in each department. That is a responsible way of managing our activities and we should make sure that all dollars spent increase the value for citizens.

But by looking at our collective work through line items and breaking down the work by silos, we sometimes miss the larger picture.

Software developers tend to break down problems into small, programmable pieces. Good software developers try to make those pieces reusable. That’s where the magic happens if you work in the open.

A piece of software that you developed to perform one task properly is an immaterial good. It is not physical. And as such, anybody could benefit from having access to it. By making it available to others, you just scaled the value of that solution to the rest of the government (and, well, the whole world).

But, more importantly, you created the opportunity for others to come and work with you. And by doing so, you expanded the scope of people able to contribute to your work beyond the physical constraints of your team. In the government context, with our funding model, this becomes extremely powerful.

This tweet from Vivian Nobrega, Open Source Advocate at Treasury Board of Canada Secretariat, sums it all very well:

The most practical sustainable solution in the [Westminster] Model is making all projects #opensource by default resulting in a decentralization of power over projects, and transitioning to a service-oriented funding model to ensure these projects remain non-legacy.#FWD50

— Vivian Nobrega (@ShadeWyrm) November 8, 2019

Early Feedback Loop

Another great reason to work in the open from the inception of your project is that you create an opportunity to have people give you feedback right away. Using the traditional review model is okay but having the stakeholders work concurrently in a live document is not a technical utopia. This can be done today with tools and services we currently have access to.

The idea here is not to have others change your work directly. You still are its maintainer, whether this is a policy document or source code. It is simply to give people a chance to advise you as soon as they can if something can be improved. There are ways to make in a way that is scalable and that will increase your ability to deliver faster and better services to your users.

We’ll dive a little more on these tools and services in an upcoming post.

Quality of Work

An interesting phenomenon has been observed by the United Kingdom Ministry of Justice (see blog post). It turns out that people that knew their work would be visible to the public had a tendency to write better quality code. This is not intended to be some kind of big brother behaviour. The goal really is to increase collaboration and transparency. It just so happens that humans tend to be more careful about what they write when they know people outside their teams may read their work.

When

So, let’s say you’re now convinced. You want to start working in the open. When should you do so?

As soon as possible! Now! Open up your workspace to at least your organization. Get comfortable with the idea that all your drafts are available for others to look into and work with you.

Of course, working in the open doesn’t mean starting to share citizens’ data, but really more about how you work. Privacy is a critical right for everyone and we have to be secure by default. Neither concept is at odds, however, and we’ll explore how you can successfully address security and privacy risks while working in the open in our upcoming post.

References