Internal Projects vs. Open-Source

Problem

Netflix is really well-known in the open-source community because when Netflix went from their own data center to using the AWS cloud, it made a lot of what they had built open-source, as they had built it from scratch. When I was working for Netflix, a large part of my responsibility as a manager was hiring. I needed to attract really good developers, as Netflix only believed in hiring really senior developers. To this end, as a manager, I attended a lot of talks, went to a lot of meetups, and spoke at conferences. My role was to develop Netflix's presence as a technology company, especially in open-source communities. From one of these events, I attracted a really good developer who was very attracted by the idea of open-source development. When he joined the team, things became a little challenging.

Actions taken

While open-source development was one of the pillars that Netflix wanted to chart its future with, internally there was a lot of production systems, and not everything was open-source, and to make things work we still needed to rely on many internally developed non open source solutions. Unfortunately, the engineer was not in sync with this reality. While initially he was enamored by presenting at external talks, he wasn't thrilled about the internal work that went along with it. He enjoyed writing the blog posts and was happy to go to meetups about open-source developments, but when it came to internal work, he didn't communicate well with the rest of his team, he wasn't much into the internal deployment processes, and he'd miss deadlines. In summary, he would optimize for the open source vision at the expense of internal needs and realities. While I had recruited the engineer based on the open-source philosophies of the company, I pointed out to the engineer that no open-source projects had ever been successful without an internal deployment that had been highly impactful and successful. For example, Facebook made Hive open-source because they had a good story about Hive being a really successful internal project. Following this conversation, the engineer's attitude towards internal projects improved a lot. There were aspects of the job he didn't enjoy, such as internal meetings, which I offered to take on, as long as he provided the material for the meetings. By changing the engineer's mind, we were able to successfully deploy the project, and at the same time it was open-sourced as well.

Lessons learned

Many engineers view open-source as a philosophy. It's important to marry this with the reality of company deadlines and internal projects, so that engineers can see how their work marries with their belief in open-source code. As leaders, we have to work on bridging the philosophical divide and ensure both the open source ideals and the internal requirements are met and thrive.