InnerSource is a fancy word to describe a simple concept –- the use of open source best practices to promote the sharing of knowledge, skills, and code inside an organization. Although a lot of these practices were already happening, our journey to create American’s InnerSource community started in earnest two years ago.

I wish I could tell you that things took off like wildfire and grew exponentially, but like most journeys, our InnerSource road has had some twists and turns. We’ve learned by experimenting and failing but we’ve also managed to pivot when needed.

Looking back, I’ve found five takeaways that have been critical to making InnerSource successful here at American.

Position InnerSource as part of how we deliver software instead of an extracurricular activity

A misperception that took root early in our journey was the notion that InnerSource was an activity outside of an engineer’s day job. This was a natural perception because of the grassroots introduction of InnerSource and but it stuck for quite some time.

Engineers associated InnerSource with hackathons, social gatherings, and pet projects.

It was time to pivot! Some of the ways that we did this included:

• shifting our focus from the initial “fun” projects that were InnerSourced to highlighting projects that were live in production.
• focusing our workshops on technical topics that more closely align with what our development teams were using.
• clearly communicating the support from upper management.

We want InnerSource to become part of the fabric of how we work every day here at American. By shifting the purpose of InnerSource to focus on code reuse, on breaking down silos, and on collaboration, we’ve seen a change in momentum.

Promoting is a marathon, not a sprint

Changing the culture inside of an organization requires frequent promotion of what feels like an endless repetition of the same message. I personally struggled with how much it felt like we were repeating ourselves over and over again as we talked to different groups. Progress can be hard to see and feel when you’re working on changing the culture of an IT organization with more than 3,500 team members.

I had to adjust my expectations. Although we were often repeating ourselves, I realized that we were reaching new people every time. Repetition with the same people also helped the message take root. It was getting out slowly but the message was getting out.

Support from management is essential

A top down push of InnerSource is unlikely to be truly successful in any organization. However, the support of upper management is essential as InnerSource is taking root inside a company. In order for something to become part of how we operate, it’s imperative that all levels are on board.

The best initiatives are ones that start at the bottom and are then aided by support from management. In our case, this support has come from delivery managers up to the CIO herself.

Support self-service and best practices over governance

One of the biggest pivots that we’ve made with InnerSource is to switch from a governance model to a self-service model. Initially, teams were required to setup a meeting with a group of InnerSource Coordinators to review their project for eligibility and to have their repo inspected for required files. Projects weren’t added to our list of InnerSource projects until they met these requirements.

As you can imagine, this wasn’t the most enticing or scalable setup.

During the second year of our journey we created our internal InnerSource Marketplace and moved to a self-service model where engineers were able to innersource their code by simply adding an “innersource” topic to their Github repo. Best practices are still recommended but it’s up to the team to implement them if they want participation on their projects. This has lowered the barrier to entry and enabled new projects to start popping up immediately.

Highlighting real examples makes a huge difference

In addition to the promoting and positioning of InnerSource, one of the concepts that has helped us gain traction has been focusing on real examples inside of the company.

When InnerSource is new to an organization there are things that are talked about hypothetically. “You should break this out into a separate piece of reusable code!” is a nice thought that nobody disagrees with, but the question remains how to do it. “Projects should re-use things from other projects!” – OK… what type of things?

We’ve found that having tangible internal examples made it easier for people to see opportunities in their own area. We’re still in the process of figuring out how to best highlight the success stories as they happen. From promoting them in our chat tool, to finding better ways to highlighting them in our Marketplace, to sharing them during guilds/learning sessions – we’re striving to highlight the great examples so engineers can learn from them and be inspired.

InnerSource today at American Airlines

As I’m writing this post there are 37 projects in our InnerSource Marketplace. We’ve just passed the two-year mark and I’m looking forward to seeing what that project number is by the time we hit three years. Even more than that, I’m looking forward to seeing how InnerSource can continue to change the way that we deliver software here at American.