New blog posts
So You’ve Decided To Open-Source A Project At Work. What Now?
Posted on Jan 9, 2014 by
Many companies are starting to investigate and participate in the open-source community, and yet few guides for doing so exist. This article focuses primarily on the process of open-sourcing a project at work, which brings with it other concerns and decisions.
Why Open Source?
Before delving into the how, it’s useful to step back and talk about the why. Why is it that so many companies have or are starting to establish an open-source presence? There are actually a number of reasons:
Companies want to be known as a place where smart people work. One excellent way to show this is by releasing code that has been written at the company. Doing so creates mindshare in the community, familiarity with the company and its contributions, and fodder for future technical brand initiatives (such as giving talks at meetups and conferences).
Time and again, you’ll see contributors joining companies that sponsor open-source projects. I saw this happen frequently while at Yahoo, where YUI contributors would sometimes end up as Yahoo employees after having contributed to the project on an ongoing basis. Similar hires have occurred in the Node.js community. The reason is pretty clear: If you work on an open-source project in your spare time, imagine how great it would be to turn that hobby into a job. Additionally, allowing job candidates to see some of the company’s code gives some good insight into what working at the company would be like.
A lot of companies benefit from open-source software, and contributing open-source software back into the world is a way of giving back. These days, it’s part of what it means to be involved in the technical community. When you receive, find a way to give back. A lot of companies are embracing this philosophy.
There are many more reasons why companies are choosing to open-source, but these are the primary drivers. Therefore, the process of open-sourcing a project must be aligned with these goals while protecting the company’s interests.
Suppose someone at your company wants to open-source something. This has never happened before and you’re not sure what to do. Do you just put it up on GitHub? Announce it in a press release or blog post? How do you know that the code is OK to open-source? There is a lot of planning to do, and it all starts (unfortunately) with the legal department.
Giving away company assets is as much a legal issue as anything else. The very first conversation should be with an appropriate member of your company’s legal team to discuss the ins and outs of open-sourcing. In larger companies, one or more intellectual property (IP) attorneys are likely on staff or on retainer; in smaller companies, this conversation might start with the general counsel. In either case, it’s important to lay out exactly what you want to do and to clarify that you’d like to formalize a repeatable process for open-sourcing projects.
The primary legal concerns tend to be around licensing, code ownership and trade secrets. These are all important to discuss openly. Because many companies have done this already, you should have a fair amount of evidence of how other companies have established their processes. The most important thing is to engage the legal department early in the process and to have a champion on the legal team who you can work with should any issues arise.