Since my company does not sell software, the choice to open source code is rather simple. Consider the alternative: keeping code a proprietary secret. Keeping secrets is expensive. Proprietary code needs to be maintained as other code dependencies often create the need to tweak things. Since there’s a steady churn of developers in and out of projects (and companies), there’s a good chance the person updating the code has to first learn what it does in order to update it. This cost of keeping proprietary code is justified when the secrets contained are very valuable. Indeed, we have lots of code that is quite essential to how we make money and we’re not about to share that code. But for much of our code base, it’s just not worth keeping it to ourselves.

In addition to being a cheaper way to manage software, there are benefits we seek to gain by publishing code in the open. The most commonly hoped-for benefit of publishing code is that someone will come along and fix the code for us. OK, it’s not really something we can bank on, but this does happen once in a while when the conditions are just right. When we publish code that others use in their projects, they often find cases that we had not explored in which the code could be improved. When they offer us fixes, we usually accept those changes so that we all have a better code base. In a virtuous cycle, we find ourselves contributing to projects we use, and find others contributing to our projects. Well-designed projects take well to organic contributions from many sources. We try to make our code very open-friendly so that it’s not fragile or rigid, but elastic and resilient.

A more realistic (though non-obvious) benefit of being an open source publisher is related to hiring the best engineers we can attract. We want engineers who are comfortable publishing code, so we have to show that we do the same. Top engineers often demand to work at companies where they are allowed to continue to develop their public reputation and where they can learn from others who are doing the same. For some engineers, the act of sharing their code is very much part of their work ethic. They strive to do more than just solve the task at hand; they seek to share their solution for others to benefit - as a way to pay back into the system that supports them when they need solutions. We get it and we support it. Being an open source publisher attracts talent and helps us get the kind of people who already know our coding style and technology focus areas.

In fact, we can even get the benefit of publishing Open Source without publishing code. If I tell an engineer at Yahoo that we plan on publishing their code, they will look over their code carefully, make sure it’s better documented, it has more unit tests, etc. since that publication carries a bit of their reputation on it. This alone means that we are more likely to have higher-quality code in our open source repos than in our proprietary ones. Usually they are the ones who initiate the request to publish their code and usually they have already worked on some fit and finish polishing before they even come to me. Whereas code is code, some of it good some not so good, open source code always has more potential for improvement.

Since much of our code-base is based on open source, we have flexibility to hire people who know the code already. We can track which open source projects are successful and which are potentially too risky for our involvement. We can offer to engage in partnerships with companies who will support the software we use, since they can leverage that support for their other customers who use the same. We basically manage our technology more effectively, and protect ourselves from getting stuck with old code.

To run a successful tech company that participates in open source you need to invest in getting the support of open source experts. There are community politics that often come into play, and there are legal details that are very much a part of many conversations. But with a clear sense of what really is proprietary and what really should be shared, you can shift from asking “why should we publish this?” to “why shouldn’t we publish this?” When you have good reasons not to publish, then don’t. But when you examine your overall technology portfolio management over time, you will find that open source participation is essential to long term tech health."

---

The Yahoo! logo is a registered trademark of Yahoo!, Inc. OSPOCO is not affiliated with Yahoo!