For more than 210 years publishing company John Wiley and Sons has connected researchers, educators, and professionals with the skills and resources that they need to succeed.

In the early days the company obviously focused on print. But today software and digital resources are core components of the company. Wiley’s software powers interactions with centuries of scholarly insights and meaningful contributions to research, discovery, and lifelong learning. With 80 offices and facilities in 30 locations, they’re able to help customers in more than 200 countries solve some of the world’s biggest challenges.

In 2017 a small team at Wiley set about repairing these divisions within engineering and moving towards the goal of one team, one codebase. Director of Site Reliability Engineering Fedor Terlov, Security Engineer Alec Sumarokoff, and Principal Architect Benjamin Young took point on the project.

Open source software is a natural extension of this mission. “Enabling collaboration through open access is already part of our Research platform,” Young explained. “Open source fits in by providing a new level of transparency, revealing the code behind the science. In the last few years, we’ve open sourced several projects, contributed code to the Apache Software Foundation and the W3C, and funded existing open source projects.”

But, over the years, the sort of open collaboration the company enables externally became a challenge internally. The company’s globally distributed developers work on hundreds of applications, many of them brought to Wiley through acquisitions. Teams became increasingly siloed, often unaware of the tools and resources created elsewhere in the company.

Young and company wanted to help Wiley engineers collaborate internally much the same way they worked on open source projects–a strategy known as innersource.

We opted for GitHub Enterprise for the major functionality: pull requests, easy merging, team collaboration, and overall simplicity.

The team started by shifting development from Subversion and CVS to a self-hosted Git server. When that test server became a central hub for software development in just a few months, it was clear they were on the right track. “We talked to a few vendors and decided to stop hosting ourselves,” Terlov says. “We opted for GitHub Enterprise for the major functionality: pull requests, easy merging, team collaboration, and overall simplicity.”

Now GitHub is at the center of an evolving developer experience. Whether teams use Slack or Microsoft Teams, JIRA or GitHub Projects, they’re all on GitHub. Terlov sees this as part of a larger movement towards DevOps and infrastructure-as-code. “GitHub has an excellent foundation in providing functionality to manage source code. When everything is code, it becomes the center for developers from concept to production.”

With one point of entry for any process related to infrastructure and application development, QA, security, and infrastructure teams aren’t just working from a single source of truth. They’re also working faster. “It’s accelerated time to production,” confirmed Terlov.

Wiley is finding it easier to debug code, find bottlenecks, and move new features and functionality to production. Young likened it to having someone over: as soon as you invite someone into your house, you start tidying up. Whether software is open to more developers within Wiley or everywhere else, its creators can benefit from socializing it. “Suddenly developers are buttoning up the structure of their code—open source and innersource act as a forcing function to get the details right and ready for more eyes.”

That was the case, for instance, with Teasy, the team’s open source testing framework. Originally an internal tool, Teasy was built on Selenium. One of the Quality Engineering teams reached out to Young and expressed interest in opening up their code. They wanted other developers to discover, benefit from, and, hopefully, contribute back to it.

Now teams across Wiley share and collaborate on code, regardless of what vertical they’re in, using cross-functional teams that don’t map to particular business units but meet to review each other’s code. Frontend developers or API developers, for instance. “The first step was getting API teams to share their documentation with each other, so we could all see it,” Young says. “The next is creating an API hub that generates documentation. It’s all with the goal of raising visibility and encouraging feedback between teams.”

Terlov sees visibility as imperative, not just for feedback but for the team’s culture. In some IT organizations, teams may not see an application until it’s ready for production. Months of development history may be buried in undocumented decision making. “But with GitHub, we see an application from the beginning,” said Terlov.

Moving from disparate installations and self-hosted web stacks to the cloud and “infrastructure as code” also improved governance by enabling them to integrate with SSO services like Azure Active Directory, that they can use to fine-tune permissions and manage teams from a central location.

But it also balances security with the reassurance that the right repositories are open enough to invite contributors from across the company. As Terlov explained, “GitHub has provided a single, secure location for all our code for all our developers within our organization. It’s immensely more collaborative when everyone has the ability to see each other’s code.”

Moving away from 200 years of organizational divisions will take time, but Wiley believes it will pay off. Evangelism is ongoing to show developers how to use GitHub and prepare leadership for time spent on code in other business groups. Beyond getting the right tools in place, changing how an enterprise builds software requires an even larger shift in how everyone talks about software and projects. Developers not only need to learn a toolset, but also a new way to work together. Young explained, “We’re asking people to step back from squirreling away time. They may be busy shipping, but they will be so much more productive and write much better code if they simply talk to each other.”

For a centuries-old company, the shift from closed-off repositories to transparent development will not only help teams stay efficient but provides them with a new perspective on their code. “We’re not only saving time,” said Young, “We’re also starting to move beyond our roots and reach our potential as a technology company.”