Open Source in the Enterprise

An excellent series of posts has been published over the last few weeks on the TODO Group blog. The series focuses on why each of the companies got involved in open source. It's been enlightening to read through each one and get a glimpse of what open source means to each company and how it impacts culture. In this post, we're going to dig deeper into how a company does open source, especially in the enterprise, which has a unique set of challenges.

So what does "in the enterprise" mean? For us, it means that we have direct relationships with our customers: they know us and we know them. We work closely with them to ensure their Box implementation meets their expectations. It means that our bottom line depends on not dropping the ball. This affects our open source code in several ways. The code that we produce must be robust. Our features must be well documented and fully implemented. Features can't be deleted between releases without providing ample periods of deprecation warning. Compliance and legal considerations must be taken into account along with extra precautions against exposing security vulnerabilities. Sharing source code that exposes vulnerabilities not only risks a breach, but also risks losing the trust & business of our customers. Besides, we pride ourselves on creating code that is high quality and a pleasure to use. In spirited defiance of enterprise companies' stodgy and slow reputation, open sourcing our code is a chance to show off our expertise and character.

Getting Off the Ground

For open source to be successful in any company, it needs to have advocates. At Box, our first step was establishing an open source committee made up of engineers passionate about the open source community and giving back. This accomplished two things: it gave the engineering org a single place to look for answers, guidance, or brainstorming support, and, more importantly, it gave legitimacy to the program.

The committee's first order of business was to define our presence on the web. At that point, our web presence consisted of a scattering of projects hosted on GitHub, each with varying degrees of activity, documentation, and adoptability. We began an effort to clean out stale repositories and simultaneously kicked off a project to build the microsite.

The microsite established a landing page for our open source efforts. We could highlight our flagship projects. Unrestricted by the GitHub UI, we could tap the creativity of our designers and programmers to create a notably Box-like experience.

Building Momentum

With all that effort invested in cleaning up our presence, we wanted to keep it well maintained! First, we defined a set of requirements for all new open source projects. Each new project needs to:

  • Have the proper license files and copyright
  • Have a defined owner who will maintain the project and respond to Issues and Pull Requests
  • Have documentation
  • Have passing unit tests
  • Have easy to follow installation instructions accompanied by how to run the unit tests
  • Follow language best practices and conventions
  • Not expose any security threats
  • Get approval from our legal team and business owners

To that end, we created a workflow within JIRA, our bug tracking software, to facilitate the process of getting a new project reviewed for each of the requirements. If an engineer wants to open source a project, a JIRA ticket is created and it works its way through the process. The ticket specifies the group of engineers responsible for owning the project. At each stage of the JIRA workflow, the ticket is reviewed by the relevant teams for each of the requirements above.

So far this process has served us well. We had some bumps in the beginning and had to assign an SLA to the open source committee so that JIRA's wouldn't get dropped. It has given us visibility, auditing, and confidence.

After a project goes live, we trust our engineers to maintain it and respond to issues and pull requests accordingly.

Every project starts out healthy and growing. As time goes by a project matures and may plateau or no longer be relevant. We implemented a straightforward badging convention for each of our projects to help communicate this to project consumers.

Accepting Changes from External Contributors

We maintain legal protections for users of our projects by requiring that each contributor to a Box open source project sign our Contributor License Agreement. It quickly became clear to us that manually enforcing this was going to be a headache. We wrote a bot that uses GitHub webhooks and verifies that each pull request author has signed the CLA. We use Travis CI to confirm that each pull request will pass the build. These two automation steps give the contributors immediate feedback on any obvious red flags, saving both them and the project maintainers precious time.

Building an Open Source Culture

We've come a long way, but there's further to go. The focus in an enterprise business is on the customers and getting them the value they need. When we launched the program, there was a surge of interest, but the unseen challenge was in shifting how we prioritized and measured the value our work. All sorts of people wanted to get involved or open source a small tool, but few of them were able to shift their workload in order to do so. Getting the support of engineering leadership has been a critical element.

We're excited about what we've been able to accomplish and we look forward to seeing the projects emerging from other businesses in situations similar to ours. Being a part of the open source community is a rewarding experience and is totally achievable by companies working in enterprise capacities. If you have ideas to contribute or questions, I'd love to hear from you! You can find me on Twitter.

Catch Ben VanEvery (@bvanevery) speaking on Box Open Source tools at Box Dev on April 22! Register today: