Why Your Employees Should Be Contributing to Open Source


Many employers are leery of permitting open-source contributions during office hours. How would contributing to external open-source projects benefit them and their customers?

Only a few companies have active open-source committers on their teams, so for a lot of developers, open source has to happen after the day job. But hacking until deep in the night, after a full day of work, can get unhealthy. The habit also excludes people with external obligations, like kids or elderly parents or school. These developers don’t take part in open source, even if it would benefit them, their employer, and the customer they serve.

Unfortunately, employers, employees, and customers are usually not aware of the missed opportunities.

Many employers still think of software development as though it was like painting a wall. If I add more workers to help with the job, the time needed to complete the task is reduced in a linear way. Up to a certain point, that’s true for painting walls, but it isn’t the case for software projects. Building a product involves many different technologies in several layers of the stack. Mastering the complexity of software depends on the knowledge a team has and how the team members work together.

If managers are afraid to let their employees contribute to open source during office hours, it’s because they’re asking themselves, “Why would painting walls other than ours help the company?” This article will investigate why it makes sense to let employees contribute to open source — even during office hours.

Open Source Retains Employees

Open-source projects are a great way to learn. Every project has its own structure, tools, personalities, and processes. Participating in an open-source project is a great way to take a look at how others work.

What tools are they using? What are the processes in other teams? How should you discuss enhancements outside of the company, where the boss often makes the final decision? By participating in open source, engineers are able to take an in-depth look at other high-end projects without handing in their notice.

Open Source Benefits the Team

Most commercial projects are heavily based on open-source software. Some bugs and edge cases just happen for large, high-traffic deployments. In those cases, we need experts who can debug the issues on time. Root cause analysis is faster in teams with deep knowledge of the used technology and internals. They don’t depend on the time of other project maintainers and are able to provide patches on their own as well.

A committer is also the go-to person for smaller problems and daily questions from others in the team. Committers educate others, and they speed up the daily business.

Investment in the Workforce

Every company wants the best-educated and most-skilled engineers on the market. As I’ve already mentioned, engineers who contribute to open source can take a look at many different projects without switching employers. They are able to grow their skills, knowledge, and experience a lot faster than developers who don’t look up from their own tea cup. Open-source involvement is collecting technical and leadership skills on steroids.

Open Source as a Playground

Some engineers have their own, small playgrounds. Others prefer to contribute to big projects “just for fun.” For many engineers, open source is a playground. But why would a playground be beneficial?

Playgrounds are the perfect place to try out new concepts and patterns. And when a project is open source, it’s easy to get feedback from other highly skilled professionals. The code can be discussed at meetups, conferences, or online.

Engineers from other companies bring different backgrounds and use cases to the table. In this way, they’re able to gain deeper insight. Diverse groups reach better results than a single team in one company.

Open Source Builds Morale

It’s definitely a perk to get some time from the company to work on open source:

  • We get time to learn and develop our skills.
  • Our awesome work is recognized in other places than just our own company.
  • We can easily discuss code and design with engineers from other companies.

Being able to contribute to open source during office hours is a perk that a lot of engineers are waiting for. It’s a major bonus in a crowded market and can help a lot when hiring.

Every Project Is Beneficial

Some engineers like to write parsers for esoteric programming languages, just for fun. Others build a website where people can paint 8-bit art. Every participation in open source has a positive direct or indirect influence. Quite often the positive influence on the job isn’t clear at the beginning.

Let’s take my job as an example. I’m working on a database and its admin interface. The database has an HTTP API: If you put a document into the database, you can access it later using a URL.

In the last year, we got a couple of bug reports for our UI. Users created documents but were not able to open them. When we thought we fixed the bug, it broke in a different place we hadn’t thought of yet. The bug affected just documents with special characters, so our assumption was a broken encoding. Another team triaging closed our issue, and the hex-encoding taken from the RFC works properly.

Unrelated to the issue, I started to take part in the WHATWG as an editor for the console standard. The console standard tries to standardize the browser console in different browsers. Web standards are the building blocks for the modern web.

What’s the benefit for my database job? Good question! I wasn’t expecting much benefit when I started. After a few weeks, the first major benefit appeared out of nowhere. We got another report of the same issue. The issue I created a few weeks before already had links to the RFC. This time, I was able to add a lot of more material: validators, algorithms, examples, sections in the RFC, as well as implementor notes from the WHATWG.

A pet project, unrelated to my job, had a high, indirect, positive influence on my day job. It illustrates well how a completely unrelated project can make a positive impact for a company.


Supporting open source is highly beneficial for employers. Every participation in a project benefits not only the developers, but also our customers and employers. Right now for many developers, open source often happens at night and weekends. For many, these habits aren’t healthy, nor are they always possible. Open source doesn’t have to work this way! Just a few companies have realized the value of open-source contributions during working hours. They give their employees time alongside their main tasks to contribute.

A good way to change the current landscape is to talk to your management. Show them this article or give a short presentation. Suggest starting with a small experiment, perhaps a few months of limited experimentation in your own team. Maybe your company offers a 20-percent time. Provide ongoing, regular feedback, especially if your managers are nervous. Share the positive and negative impacts this open-source experimentation has on your team.

I’m sure there will be more positive impacts than negative in the long term. Managers will see the benefits and start helping you support the idea company-wide. We all have the opportunity to change the companies we work for; we just have to do it.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles.
Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.

  • titpetric

    I couldn’t agree more. It opens your mind for new thinking, perhaps breaking some bad habits of the type “we always did it like this”. Over the years I encouraged myself and our developers at Monotek to write technical blogs (http://scene-si.org, http://foreachorg.tumblr.com) and contribute to open source. A coworker wrote a PHP static analyzer with some specific functionality on my specification, we open sourced it (in part, to find it when we needed it). Some other guy improved it beyond what we imagined, we use his version now. I contributed to projects which deepened my existing knowledge, and expanded it with new skills in Golang, Docker, and the understanding that comes with it. It’s as much about teaching as it is to learn – and open source provides this in full. But the struggle between paid and open source projects is real – if somebody is an employee, it means business first. But not technically business only. The original Google example of having 1 day for side projects is always quoted, but I believe we fall short – mostly because we don’t set limits for work, and goals for side projects. And goals should be defined. If your side project is learning a language, your goal should be to teach the language forward, have a talk about it (internal or public), to publish a book about it, to solve a problem with that language, to evaluate a use case – these things improve us as individuals. And I can say, just submitting a PR to an existing project feels satisfying.

    • titpetric

      https://github.com/titpetric/PHP_Codesniffer-VariableAnalysis Would be the resulting project based on our open source efforts. Illusori (https://github.com/illusori) would be the “some other guy” who improved it beyond our imagination ;)

      Edit: at least one bad part about open source (like this) – there are 2 pull requests open for a few years, one of mine, and one of some other guy who also had a valid change. Mine is about 3 years old.

  • Pingback: You either die a hero or you live long enough to see yourself become the links. - Harvey Dent - Magnus Udbjørg()