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.
[Tweet “”Why you should let employees contribute to open source during office hours” via @robinson_k”]
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.
[Tweet “”Open-source lets engineers 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.
[Tweet “”Open-source involvement = collecting tech and leadership skills on steroids.” via @robinson_k”]
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.
[Tweet “”Open-source contribution during office hours is a perk that 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.
[Tweet “”Tell your manager how open-source contribution is beneficial to the team.” via @robinson_k”]
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.
[Tweet “”Why Your Employees Should Be Contributing to Open Source” via @robinson_k”]