Three years ago, PayPal was growing exponentially, staying profitable and was considered the most successful online payments company in the world. This should have been the recipe of a company that was attracting top talent across the globe, and keeping their core engineers happy, thriving, and innovative. But, at the time, the PayPal engineering team wasn’t where they needed to be to stay ahead of the curve — they didn’t have the process, the tools, or the resources to extend their talent and stay engaged in creating amazing products and services.
Leadership had encouraged the formation of engineering silos to “concentrate expertise,” but this made it incredibly challenging to get things done. At the same time, popular services such as Google and Amazon were raising the bar for everybody. All businesses — not just software-focused businesses — needed to have websites (and mobile apps) that were snazzy and responsive in addition to being reliable. PayPal engineering needed to push the proverbial envelope to stay competitive in a fierce and unrelenting industry landscape.
For PayPal, the transformation started at the edge of the stack. The Kraken project, which was started by an internal team to support a new checkout system, proved that an open source platform could reduce time to market and still perform at scale. This was achieved largely in spite of the silo culture that ran rampant and tended to restrict innovation and creativity. Support from senior management and perception of less risk at the edge of the stack helped the project and ultimately unleashed a gold rush of interest in repeating the win with releases of internally developed improvements to other open source projects. When I came into PayPal, I received an avalanche of mail from teams who wanted to “open source something.”
Of course, now the challenge is to do it right by releasing only projects that actually matter to the world outside, and going the (sadly often forgotten by corporations) extra mile by building and partnering with a community for those projects through an on-going commitment to contributing development resources as part of the normal course of business. This focus on the benefits of community as a necessary component of open source success raises the question: “Can we function as a community internally?”
PayPal is adopting InnerSource across the engineering organization as well as continuing to integrate open source code as we pay down our technical debt.
A little over a year ago, PayPal set in motion a shift to agile to help accelerate our development cycle, but the silos were still impeding success. We realized that we needed to find a way to move away from silos to improve communication and make it possible to better utilize our resources. We believe that internal open source methodology (which we are calling “InnerSource”) will be key to making this work. It will interact with other critical organizational changes, such as a willingness to communicate and work across organizational boundaries, and the use of tools and practices that fall in the lean model for business and the agile model for software development.
InnerSource creates a pressure for better code quality due to the expectation of wider scrutiny (since teams are inclined to carefully review code coming from other groups’ pull requests). It can create better resource utilization across the organization, as wait time is converted into productive itch scratching, and we expect it to increase developer satisfaction since they’ll be able to fix things that are getting in the way of them getting work done — and won’t have to re-invent the wheel as often since all code assets of the company are available for use.
This isn’t a new idea. In 2001, CollabNet and Hewlett Packard started talking about their successes applying the open source methodology inside the organization to consolidate development away from bespoke coding per need to a few repeatable, easily-understood models that could be used over and over.
PayPal is adopting InnerSource across the engineering organization as well as continuing to integrate open source code as we pay down our technical debt. For us, InnerSource is a tool for our engineers to stay sharp, engaged, and happy. We’re also actively working for successful engagements with open source communities to seed valuable improvements we’ve made to support our scale of operations. For the open source community, this is the way we’re paying it forward.
Not a bad gig.
Look for more stories about our progress on InnerSource and open source in the coming weeks, and check out our keynote at OSCON.