GitHub GitHub Universe 2021 - Main Broadcast Sessions, 28 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Making InnerSource & Developer Experience Real at one of Canada's Top 5 Banks - GitHub Universe 2021

Description

Presented by Anthony Vacca, Sr. Director, OSPO & Developer Experience

As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub

Thanks!

Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github

About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com

A

Hello github universe, it's an honor to be speaking to you today from toronto ontario. My name is anthony vaca. I am the senior director of our developer experience and open source program office at rbc at rbc. We are transforming the way, we're working and it's through inner source, which is our foundational project towards future. More active participation in open source.

A

For those that don't know rbc is a global bank with our headquarters here in toronto, canada in canada, we are one of the leaders of the big five banks when it comes to customer service offering award-winning products to our clients. We have pushed through into the digital space, with over 5 million active mobile users.

A

We are number one in market share and investments, banking, private, banking and we are focused on helping our clients thrive and our communities prosper.

A

Now being at 150 year old bank servicing over 17 million clients in over 30 countries, our 80 000, plus employees, can become siloed, as you have thousands of developers building our leading products like any software shop. We also get stuck on problems and relying on our community to help solve those problems. Those problems can range from interacting with many internal systems, security, controls or processes that no one have ever seen before.

A

So when someone asks a question, they tend to ask their team lead, who has their manager, who may know someone else that has come across this before the key? Is it's very ad-hoc conversations to help developers solve problems, and we have a great culture that enables that? But what happens when someone is in a remote team at the bottom right hand of the screen and you're so siloed that that team doesn't have that support network?

A

It gets very difficult now multiply that across a large organization, and we follow ourselves into that trap of conway's law where an organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.

A

Basically, how we design systems may not make sense, but it works because its hierarchy is there having been with rbc for 17 years in many different roles across the organization.

A

We, like many organizations, have this problem, but in 2014, rbc went through a big change in leadership when we had bruce ross and martin wildberger join rbc to lead up our technology and innovation department.

A

This new leadership started to modernize our tools, our processes and one of the first things they did was a converge on one scm tool, which was github.

A

In fact, I remember one day: martin our executive, vice president of technology, innovation asked our developers. What else can we do to resolve your pain points and people spoke up? Almost half of the ideas were about better culture and collaboration.

A

People wanted open source, but inside the bank people wanted that inner source culture so after successfully driving an open source program in their previous companies. Our new leadership didn't need any convincing about the power of open source. They realized that having an open source program office led to better software engineering practices and today, open source actually has become a key supply chain of software for all large banks, with 47 percent, actually making contributions back. So, at rbc, with the inspiration of the linux foundation, we came up with a four horizon approach to our strategy.

A

First, we focus on inner source. We needed to work on standardizing our practices, build that culture of collaboration code, reviewing our branching strategy and so much more. We needed to bring that culture of open source inside the bank, because if we can't work together inside the bank, how are we expected to work outside the bank now? Because a key principle of inner source is code?

A

Transparency, open source code is an obvious supply chain of software that comes into rbc, so our second horizon is using open source safely and respectfully since we consume so much open source. Naturally, we make enhancements fixes so horizon. 3 is about contributing back to open source projects.

A

It is the right thing to do and in some cases the legal thing to do, but we actually want to give back because it doesn't make sense for us to decouple our software upgrade and then reapply our fixes. We want to get back to the open source community because it's the right thing to do and it feels good to be part of a thriving community and finally horizon 4.

A

As we build better well-engineered software. We want to lead strategically and give back to the open source community where it makes sense, but it all starts with horizon one where our goal was to make github our software collaboration marketplace for our developers.

A

Out of the gate, we could not make all our repositories public inside of rbc. Our security policies didn't allow it for two main reasons. The first being projects were built for a need to know basis.

A

There was no central place, people could build and collaborate on reusable software second constraint was all projects need an official owner at a bank. We can't have orphan software if someone builds something it's got to have an official owner.

A

So to solve this, we created an internal public, intersource org, with only three rules that we negotiated with our security team. The three rules are number one: there are no hard-coded usernames or passwords. This just makes sense and it's proper engineering practices number two is no client identifiable information, we're a bank we need to protect our clients and number three no code will be directly distributed to production.

A

If someone wants to reuse a piece of code in our shared org they'd, either have to fork it or what our recommendation is to package it and build it as a dependency.

A

If you use the code, then you'd be responsible to maintain it with the rest of the community. So this org was a start. It was our big milestone to kicking off our program and from there it was fun we started to engage with the community.

A

We started to work on reusable projects that we thought everyone can benefit from and through this we actually defined what our culture means to us and I'll share that here at rbc. We want to be collaborative and experimenting openly communicating with challenges and ideas.

A

We are willing to admit that it's not perfect, we're always looking to grow and improve we're energized by the opportunities and, most importantly, we're willing to give instead of take. This all sounded good, but I needed a way to measure this, because you can't manage what you don't measure. So we started to measure four things. We started to measure the slack chatter.

A

We start to measure who was attending our events and as more and more people started engaging with us, we start to measure who's, collaborating who was participating in creating repos or contributing back to projects they never even heard of before, and with these metrics we eventually graduated into reuse metrics, so here's an example of how many people made at least one contribution per month since the start of our program.

A

Looking at our collaboration, metrics from github, we can see our social events early on was very, very lightly attended. But as we had our big community events, more and more people started working and collaborating on projects. Until we finally launched our reuse program and when we launched our reuse program in 2019, we actually found more and more projects, reusing it and it just started to grow. We can now see teams that are building in these dependencies into their projects and deploying them to production as more and more apps reuse.

A

The amount of reuse increases as well, so we can actually make better decisions on what projects to invest in which are critical and which ones may be needed to get some more work or decommission them. So, in the end, our apps are now starting to look the same. The same icons, the same colors, fonts and more.

A

Our devs are we're using our security patterns, mostly because it's just easy and saves them time. So inner source has really started to transform the way we work and if you've ever read the book crossing the chasm. You know there are five stages we track in adoption. The first stage is the early innovators.

A

These are people where you say the word, inner source and they're hooked, and they want to get involved. Second phase: is your early adopters, your visionaries? These are people where you need to spend. Maybe two minutes with someone explain open source inside the bank and they're set, then, is that dreaded chasm?

A

This is the hard part of the adoption, because this is a big leap towards your early majority, followed by your late majority, people who maybe need a little bit more convincing and finally, your laggers and skeptics.

A

Now the early part is easy. These are employees that want the change they want that culture that community this makes about 15 16 percent of your population.

A

Moving on to the difficult part, this is where employees want the solution handed to them. They want the convenience for that community collaboration and reuse, and in our journey we're now approaching our chasm as we take all the best practices. We've worked together with the community on and scale them across the organization and for us to get started. We really focused on building that foundation and our strategy has really been at first be pragmatic, make what these people want the reality.

A

If people want the ability to do more code, reviews or change their branching strategy, let's work with them to set all the foundational components and prepare to scale as we're scaling now we're starting to look at building a reward mechanism, we're making it easy for developers to share and collaborate. We need just to train developers. We need to give them rewards just to make sure we attract that early majority, the late majority.

A

There may be two things they may not have the awareness of where reusable artifacts and where the collaboration happens, or we have to actually look at the technical feasibility.

A

Maybe this won't work for all teams, but we're going to try and the late majority will focus on building those small bespoke solutions and, finally, the laggers, the skeptics is, you know we just may need to push in a different direction. Maybe it's a management change or we just really to try to dig down deep, why it's not working, but that's what our strategy is for the next few years. I want to thank everyone for listening and look forward to the discussion.