C.H. Robinson embraces open source: iteration accelerates so fast that they need to 'hit the brakes'
In 2014, C.H. Robinson faced development process bottlenecks: heavy dependencies between teams and waterfall processes slowed delivery. The company shifted to inner source development, introduced GitHub Enterprise, and internalized open source practices. Today, deployment frequency has increased significantly, but rapid iteration has also overwhelmed users, prompting business departments to request a slowdown.

In 2014, third-party logistics provider C.H. Robinson hit a development bottleneck: how to eliminate blockages in the technology development pipeline?
According to Vanessa Adams, the company's director of architecture and application development, at the time, each engineering team of 8 to 10 people developed features around a specific module or product, such as order management capabilities. However, teams often stalled due to dependencies on the progress of other product groups.
Adams told CIO Dive that at one point, completing most development deliverables and milestones required coordination among 12 to 15 teams. To reduce development dependencies, C.H. Robinson began exploring ways to allow people to work across product areas rather than waiting in priority queues, hoping project timelines would align.
Naturally formed bureaucratic processes slowed down application development, with teams following processes similar to waterfall rather than more modern agile methods. Therefore, C.H. Robinson turned to "innersourcing," bringing open source development practices into the enterprise to reshape engineering methods and accelerate development.
Both internal and external customers are placing higher demands on enterprises, driving technology teams to develop quickly and iterate faster. New management and philosophies such as agile and DevOps have taken root in enterprises, often triggering innovation in technology stacks.
"There is a portion of code that is considered 'secret sauce,' and they want to keep it physically near headquarters, used on infrastructure they own."
— Matthew McCullough, Vice President of Field Services at GitHub
Open source technology makes enterprise product and software development smoother, and more companies are accepting its use. In 2017, GitHub reported that45% of the Fortune 100 use GitHub Enterprise to build software, and C.H. Robinson also adopted the product.
But open source does not mean it must run in the cloud. Matthew McCullough, Vice President of Field Services at GitHub, told CIO Dive that the vast majority of customers adopt a hybrid approach, balancing on-premises deployment with cloud solutions. Open source work may happen on GitHub.com, but organizations rely on GitHub Enterprise for more proprietary code.
"There is a portion of code that is considered 'secret sauce,' and they want to keep it physically near headquarters, used on infrastructure they own," McCullough said.
Embracing non-proprietarization
C.H. Robinson is a "middleman" in the transportation chain, closely connected to customers and carriers. "We like to call ourselves the 'Uberization of trucking,'" Adams said. "We match customers with carriers."
The 113-year-old global logistics company has more than 15,000 employees, of whom about 800 work in IT, with total revenue of $14.9 billion in 2017. The company relies on technology to match customers with carriers; if technology is disrupted, the network cannot match successfully, and the supply chain may stall.
Driven by engineering, C.H. Robinson turned to GitHub to support inner-source development and share code among development teams. Open source technology in the enterprise allows teams to reuse other teams' code like building blocks, rather than rewriting it.
This shift made C.H. Robinson act faster, but cultural impact followed.
The CIO is very aggressive in moving from proprietary systems to open source systems, but "honestly, I'm a bit nervous about it."
— Vanessa Adams, Director of Architecture and Application Development at C.H. Robinson
Moving to open source technology or development models can be a painful process. In the past, the finance department only needed to sign a three-to-four-year service agreement, depending on the company's update cycle. McCullough pointed out that open source is not a simple vendor agreement or procurement.
After adopting open source, the legal department must approve contributions to open source projects, procurement needs to understand there may be no invoices to send, and managers must understand that contributing to open source frameworks during work hours is part of the process. McCullough said this is a long-term shift that may take months or even years to complete.
But C.H. Robinson is "fertile soil" for this shift, he said. Engineering practices already operated in small teams of 5 to 15 people, giving them a certain degree of autonomy, and each team could adjust open source frameworks according to its own needs.
This was a "major organizational change," Adams said. The CIO is very aggressive in moving from proprietary systems to open source systems, but "honestly, I'm a bit nervous about it."
The company adjusted personnel to focus on two areas: products and meeting business unit needs. Teams applied inner-source practices to all products, which drove C.H. Robinson to adopt new tools, technologies, and processes.
Now, when we talk about a "single global transportation platform," "we don't create the same functionality in 10 different places," Adams said.
Going through a "painful" process
While facing development bottlenecks and striving to adopt agile practices, C.H. Robinson was also a member of the SD Learning Consortium , which includes companies such as Ericsson and Barclays.
As part of the collaboration, C.H. Robinson visited other large engineering organizations, which made them realize that inner sourcing is feasible, even though Ericsson's scale and size far exceeded theirs, Adams said.
By slightly adjusting internal team structures, C.H. Robinson was able to be open to the concept of inner sourcing. Giving development teams more autonomy allowed them to make decisions as independently as possible without escalating through layers.
"I won't deny it, it was a bit painful," Adams said. "But we would never go back and change it."
Many millennials "are looking for a different way to work in the enterprise. They don't want top-down mandates," McCullough said. Bringing external coding experience into the enterprise, "they still understand there is profit to be made and goals to achieve, but the way to achieve them can be different."
But getting software engineers to adopt open source development practices is not the problem; the challenge is getting enterprises deeply integrated with proprietary systems to shift to open source models.
Engineering teams also need some guidance to go beyond existing development practices.
For C.H. Robinson, the biggest change was speed. By changing engineering structures and adopting inner sourcing, the company significantly increased the number of deployments in its DevOps pipeline. Since 2016, C.H. Robinson's weekly deployment count has grown by 162%.
But in the end, the number of releases doesn't matter. What matters is the value delivered incrementally, rather than the large quarterly releases of the past, Adams said. "The behavior we want has emerged: we want to deliver incremental value as quickly as possible, and you'll see that in the numbers."
However, iterative releases also brought side effects, with the IT department running almost too fast. Now, the department can introduce small product changes weekly, forcing users to adapt to nearly continuous adjustments. "We do hear 'slow down,' and that's new," Adams said. "The business side is also undergoing a mindset shift, thinking about how to handle the volume of changes we push into production."
