What can we learn about remote work from open source projects?

August 14, 2020

Open source projects have been functioning in a distributed and remote fashion for years, with much success. In this article, we look at how open source practices can be adapted and applied in a corporate environment to make remote work more efficient.

Before diving into why it is worth looking at some practices that make open source projects successful, it is probably useful to quickly discuss the main challenges of remote work.

The organizational challenges of remote work

6 out of the 8 obstacles to remote work we’ve identified are entirely depending on the organization of the group itself: communication, management, trust, methodology, culture, and written culture.

How are open source projects circumventing those challenges?

There are a few things that can be learned from the way open source project are intrinsically managed:

Propose and share a common vision

Un projet open source est avant tout un projet commun

Open source projects federate contributors—be they corporations or individuals—with very diverse backgrounds, around a shared objective that is the inherent motivation of the community. Without a shared objective, there is no community.

Transposition in a corporate environment:
Propose a vision/project that all the employees can relate to

As obvious as it may sound, building a company’s culture around a shared project is not necessarily a simple endeavor. Often times, a company’s objective evolves towards something that only resonates with or targets a limited amount of people. “Becoming the leader in domain X”, “Achieve an annual revenue of $Y million”, or “Be the best on innovation Z”.

There ought to be a more inspiring goal, that the vast majority of the company can adhere to. It is even more crucial in a remote environment, since this shared goal becomes the glue between employees and their day-to-day work, and the reason why they wake up in the morning. A good practice to state the company’s vision is to be crystal clear on the problem(s) the company solves for its customers.

Leadership over control

Offrir un leadership, être présent plutôt que contrôler, micro-manager

Open source projects can’t leverage the subordination link that typically exists between an employee and their company/management. Open source project leads are usually acting as helpers to the community, making sure the project can make progress without strictly speaking controlling it, for they would be at risk of discouraging contributors.

Transposition in a corporate environment:
Managers must be particularly available in a remote context—available without being invading or intrusive.

Remote work requires a shift in one’s practices as a manager: autonomy must be encouraged, and excessive control avoided. However, it is important to be particularly available to people who tend to be slightly less independent, or who may temporarily require assistance. Just like an open source project lead, a remote manager must do everything to solve a problem as it arises.

A good practice for a remote manager looking to identify improvement opportunities will be to pay attention to all the occasions where they had to pull rank to get a task completed…

A major hindrance to remote work is often trust. How can open source projects, gathering people who initially don’t even know each other, manage to establish communities based on trust?


Sans transparence au sein d'un projet open source, la communauté a difficilement confiance.

Mutual trust is key. An open source project needs to put everything in place so that new contributors joining the community have trust in the project. Transparency is essential to establishing this trust: decision processes and discussions are public, allowing to understand what led to it. Open source projects that tend to have a more opaque governance often struggle to attract external contributors.

Transposition in a corporate environment:
Remove obstacles to finding information (file permissions, documents can easily be found, …) and decisions (meeting minutes, …).

Transparency within the company is also a way to gain employees’ trust. When virtually everyone can access the information trail that led to a particular decision, it becomes much easier to understand the the company’s roadmap in terms of tasks and priorities.
Of course, some corporate environments or topics (ex. confidentiality or security) may not allow for full transparency. In that case, information must still be made available: while it might not be accessible to everyone, the way one can get access must be documented and itself be transparent. That way, people know the process they must follow should they actually need to access this information.

One of the usual complaints about remote work is: “Remotely, my company culture will disappear” or “It’s impossible to maintain team spirit with people working from home all the time”.

All open source projects are not in this case but some of them succeed to create a community with a real team spirit and a common culture.

What are the secrets of those projects to create and maintain their culture?


Annual conferences allow to work on the project but also to bond

Annual conferences allow open source communities to exchange about technical topics, organize creativity workshops and of course to bond by talking informally or by having fun.

Transposition in a corporate environment:
Create team retreats combining those different moments (technical/business discussions, creativity and fun)

Company seminars are quite common. However, it could be interesting to take inspiration from the way open source conferences are organized to create events enabling a good mix of those 3 kinds of interactions: technical/business talks, creativity workshops and fun activities.
Ideally the content of the team retreat should be built collectively to involve the group in the event. While operating remotely, the effort to organize such event is definitely worth it as it will create the cohesion within the organization for the year to come.

Code of conduct

What a community accept or reject define its culture

The community culture is defined by the behavior of the persons composing it. If an open source project doesn’t want its culture to depend on few individuals who could “pollute” the project, it must clarify which behaviors the community encourages and the ones that it rejects (read about this topic the excellent presentation “Assholes are killing your project”). This is what the code of conduct is made for.

Transposition in a corporate environment:
Write a code of conduct shared and updated regularly and collectively

The code of conduct clarifies the expectations. Indeed, if there are no rule defined, people can interact “without filter” and it could create important damages. By setting up rules, we are not limiting the freedom of speech, we are just avoiding misunderstandings.
It’s even more important when working remotely as often the main communication channel is a group chat (like Slack or MS Teams) and people will try recreate an informal tone. In order to avoid any misconduct, a code of conduct will formalize what kind of company culture we want to create. For the code of conduct to have even more impact, it’s important to write and update it collectively to be sure it represents the values of the group.

Communication issues is the #1 challenge quoted by people working remotely.

Let’s analyze what open source projects put in place to communicate properly:

Asynchronous communication

Open source projects must embrace asynchronism to build a wide and vibrant community.

Open source project communication must be fundamentally asynchronous in order to adapt to the various constraints (geographical location, work priorities, …) of the community members. When a contributor is working on an open source project, there is no guarantee that other contributors will be available at the same time. They must therefore make sure they can work on their task on their own, and later sync up with the rest of the community.
Latency tends to be minimized, and social/work interactions are funneled through the right set of tools that allow anyone, when they come back online, to glance over what the community has been up to, and what has to be worked on.

Transposition in a corporate environment:
Spot synchronous constraints and try to be compatible with asynchronous communication patterns as much as possible  

A company that relies on in-person work will tend to favor synchronous interactions, often leading to people getting stuck on their task, waiting for the next synchronous exchange that will allow them to discuss and unlock the situation.
A common mistake when implementing remote work is to adapt existing in-person communication methods to remote. This is made even easier with modern enterprise communication tools such as Slack or Zoom. However, efficient remote work requires new practices embracing asynchronous communications to be put in place.

Implementing such new practices requires an introspection on the company’s current practices: how are people interacting with each other? Synchronously or asynchronously? For each synchronous interaction, what could be a more asynchronous alternative? Synchronous interactions remain useful in some situations, but a majority of them can be transformed to be asynchronous. Try and do the exercise for yourself!

Written culture

Written culture is what enable asynchronous communication

Written culture goes hand in hand with asynchronous communication. Open source projects rely on writing for sharing and circulating information. This enables anyone, in particular parties external to the community, to understand how the project works, learn about its status and its direction, simply through reading and without needing the help or explanations from an existing contributor.

Open source projects track all their information in a wiki or a content management system, theirs taks in an issue tracker, etc.

Transposition in a corporate environment:
Setup tools that enable collaboration through writing. Track all deliverables.

Transmitting orally information is quick but it’s also fleeting and will require to be repeated next time someone needs it. On the other hand, a written and available information will enable asynchronous communication inside a company, it’s also a way to be sure it’s not altered and that it could be spread easily. The company needs to initially invest to create the good habits to document things but once the habit is there, it’s a huge boost to work (and even more remotely).

The last category of challenges with remote work is about methods. Lots of workers complains about work organization being less clear remotely.

What are the methods used by open source projects?

Well-defined processes

Well-defined processes make the work predictable and clarify interactions

By having well-defined processes, open source projects make sure contributors understand how the project works and that they can be involved on any task (depending on their skills of course).

Transposition in a corporate environment:
Document all the processes in a light and understandable way.

A company will work better remotely if it writes down its processes. Documenting processes will allow to easily onboard newcomers and everyone to not miss a step when performing a task.
Of course, this documentation should remain clear and understandable. As in open source projects, you have to be sure someone new can understand how the company works without needing someone to teach him/her.

Globally accessible tools

By giving access to the tools, open source projects ease onboarding

Documenting processes allows virtually everyone to work on any task. Open source projects have also to make sure all the required tools are available to everyone. Indeed, a tool not available is an additional obstacle for a user to start contributing.

Transposition in a corporate environment:
Break the silos, give access to the full tool chain to everyone

When working remotely, it’s key to foster autonomy. By giving the possibility to everyone access to the means required to perform all the tasks, you enable a maximum number of persons to work without any obstacle. Each time it’s possible, you must open (or at least ease) access to the tools.

To conclude,

We have seen lots of practices from open source projects can be reused in a corporate environment to improve the efficiency of remote work (and this list is not exhaustive).

What we discover is how practices of open source projects are designed for the community and to enable this community to collaborate and build something together.
Those practices will have even more impact if the community is involved in their definition and their maintenance.

Our main takeaway to build an efficient remote organization would be to apply this principle: Involve as much as you can the group in the definition and the evolution of the practices of working remotely. Set up a continuous improvement loop.

If you want to go further and integrate progressively all the best practices of remote work in your organization, you can have a look to our Dr. Remote solution to guide you automatically in your remote work organization and to help you improve continuously.