Before we get started…

There’s a very real chance that some of you won’t even finish this sentence before saying “too long; didn’t read” so here’s a brief summary to try and capture your interest:

TL;DR: American has been tiptoeing into the world of Open Source through our involvement in student hackathons and through our “lessons learned” from our InnerSource community. Now we’re ready to start tackling larger projects, both via projects we maintain and projects we contribute to.

Interested? Awesome. I’ll do what I can to prevent you from regretting this decision later.

Not for you? I doubt you’re still reading this. But if you are, feel free to go watch videos of cats who yell, pop some bubble wrap, or find an equally productive way to use the time you just saved.

Hackathons: the best way to become sleep deprived

Hackathons are a huge component of American’s culture. Each year, we host a thousand-person hackathon called HackWars that features 50+ sponsors and 100 teams who compete over a 24-hour period to create innovative ideas that improve the experience of our employees or our passengers. HackWars has had a tremendous positive impact on our company’s culture and year after year, we expand the number of seats available only to sell out once more. Hackathons are positive for morale and for team building, which inherently makes them amazing for keeping people excited about what they do, making them passionate about new tech, and distracting them from other job offers.

Unsurprisingly, these excited and passionate attendees of our internal hackathon are among the best developers at American. Also, it’s very difficult to recruit new talent that has that same passion and excitement for technology. There is, however, one incredibly consistent method of identifying new talent that meets our high standard for new devs: student hackathons. We decided to attend our first student hackathon a few years ago, and each year since we’ve expanded our attendance to new hacks (although our VP of Customer Technology, Steven Leist, would argue that Texas A&M’s TAMUHack is the only hack we need).

Making students think you’re cool

We’ve found the right talent, but how do we get them to come work for us? Recruiting at student events is actually quite similar to fishing. First, you have to find a good spot where the fish like to hang out. Then, you need to find something that catches their eye. And finally, you need to convince them that what you have is worth committing to. Unfortunately, that’s the best analogy I could come up with, so let’s just roll with it 🎣

What’s the best way of getting the interest of a fish student? The answer is rather simple: practice what you preach. You’re at an event that purely focuses on building awesome new projects with new tech – at a minimum, you need to show up with modern tools and leverage technology to help you during the event. Our first step towards modernization was to move away from having a text snippet about our challenge on the hack website and instead leverage GitHub. We started out by simply hosting detailed challenge docs in a wiki but quickly realized that for students to hack on airline-related projects, they needed airline data. This need for airline data became the inspiration of American Airlines’ first Open Source project: AA Mock Engine.

We started with a Node.js app built with Swagger to create a simple API students could explore and then bake into their hack. The app initially needed an absurd amount of mock json files and featured an incredibly fast app start time of just 5 minutes. Later, we needed to completely refactor the mock data creation because we only had data for a single year. This project was, without a doubt, perfect for students and reflected the sheer, unmatched technical prowess of American’s developers.

Let it be known that I accept full responsibility for all the students we confused. I hope they continued to study computer science and went on to make their very own terrible mistakes which they may one day write about in a blog post.

We started over. Clean slate. No tech debt. We decided to use Node.js again and one of my co-hackers, John Kahn, came up with an ingenious method of creating mock data on-the-fly without needing a database. I did, however, document this wizardry, therefore, I claim full credit for the functionality. We saw far fewer glazed-over eyes and meaningless head nods at our next few hacks. At this point, we had all our event documentation in GitHub and we had an Open Source app that both provided flight data and could be extended to act as a project’s only backend. coolness++

You can always look cooler 😎

Students saw the American team using tech for everything they did at the hack and we got quite a few compliments. With this increase in attention came an increase in interest as well as an increase in the number of quality candidates who submitted their resumes. This was a great start, but there were still plenty of behind-the-scenes event tasks that were hindered by no-tech solutions.

At each hack we attended, we had to manually keep track of which teams were competing for our challenge and we had to check in with them periodically by walking to their table. Students would also occasionally come to ask for help or get feedback, however, this often took place with many teams all at once which led some teams to leave without receiving the help they sought. We decided it was time to build something that would fill these gaps all while making us look super cool. We designed Hangar, a student hackathon sponsorship platform that provides sponsors with a suite of tools to engage with students.

Hangar provides students with easy access to challenge information. It allows them to request technical help or sign up for a slot to come and pitch their idea. It even helps sponsors judge competing teams. The end result was that nearly every task we had to perform at student hackathons was now being powered by technology. Awesome.

While it’s important to us to find top talent at these events, the most important outcomes for hackathons are that the students have fun and that they make connections that help land them a job after graduation. Hangar drastically reduces the barrier to sponsoring a hackathon (your finance department will likely disagree with this statement), which means more sponsors at hacks and more jobs for students. We Open Sourced the project.

From InnerSource to Outer Open Source

Although we’d already started our journey into the world of Open Source, we were doing so with a lot of help and lessons learned through our InnerSource community. Fostering a successful InnerSource community is a massive undertaking; one that requires strategy, passion, and - above all else - patience. In the early days of our InnerSource community, any given day was filled with a tremendous amount of moving pieces and potential opportunities. There were patterns to establish to aid in collaboration, documents to create and promote as standards, and workshops to organize to help attract more people to join the community. Looking back, I’m thrilled with the decisions we made and how we built the foundation of our community, but NONE of it was perfect. Every piece of the InnerSource puzzle was trial and error.

Each time we made a decision and later reflected on it, we gained a tremendous amount of insight into how to organize a rather ambiguous group of onlookers. We found better and more efficient ways to communicate with them, to entice them to contribute, and get them to become more active members within the community. All of this information helped us build on what we’d already built within our InnerSource community, but it also gave us valuable insight into how to continue to build our Open Source community.

To make it as easy as possible for others to get involved, we used the knowledge gained through building our InnerSource community and prioritized documentation and the use of GitHub functionality like Issue and Pull Request Templates. We also made sure to add CONTRIBUTING documents to our Open Source repos to make it easier for others to get started without needing to ask for help. We made sure to add issues of all sizes and difficulties to give community members a chance to join in at their own pace. Finally, we focused on creating solid READMEs that had clearly defined sections with the right information for those who need it.

While it’s tremendously important to make your project welcoming, we learned from our InnerSource community that the quality of projects is equally important. We knew we needed high-quality projects in order to garner and retain interest, so solid code quality became another top priority. When we Open Sourced new projects, we made sure to focus on good test coverage and adding GitHub Actions to our repos to prevent merges with untested changes. We also added tools like Codecov (free for Open Source) to provide code coverage updates within PRs and lgtm (also free for Open Source) to scan our code for vulnerabilities.

We’re very proud of the quality of our Open Source projects. Sure, we still have plenty we can improve upon, but we’re still learning and constantly reflecting on what’s worked internally to see if the same patterns would be a good fit for our Open Source projects.

Making Open Source part of our culture

As we continue our journey into the world of Open Source, its relevance is increasingly becoming front of mind. As we continue to identify pain points for our developers and our teams, we’re getting into the habit of asking ourselves “Would this be a good Open Source project?” Recently, asking this question has yielded results for two different purposes and we have two new additions to our Open Source community.

Culture is critical at American and we are always looking for ways to make our team members happier. Recently, that focus lead us to Open Source a project that helps our team members feel psychologically safer at work. Chat platforms are a huge part of how we work and it’s made our communication incredibly simple. But occasionally, our team members may feel anxious about asking questions about topics that might make them seem less knowledgeable. For example, let’s say a senior developer has never touched CI/CD before and was tasked with fixing a part of their pipeline. They may feel afraid to ask for help out of fear that others will judge their lack of knowledge. Although our culture emphasizes how the act of trusting others and asking for help should be celebrated, it’s still a logical concern. Sometimes it may prevent our team members from asking completely valid questions (many of which would benefit others who had the same question). We decided to build Asking for a Friend, which is an app to increase psychological safety within our Slack workspace.

After building Asking for a Friend and launching it internally, we remembered to ask ourselves “Would this be a good Open Source project?” American isn’t the only employer using Slack that also struggles with the occasional fear of asking questions, so we felt this would make a great contribution to the Open Source community. We’ve gotten great feedback so far and it’s highlighted the value we gain by considering projects for Open Source as part of our development process.

Another great example of how we’re incorporating Open Source into our culture stems from our adoption of TypeScript. TypeScript’s presence within American has increased tremendously in 2020 and while we’re still in the early stages of using Node.js backends for production applications, we’re quickly identifying patterns that can cause headaches for our devs. One such headache is caused by the use of environment variables. There are quite a few Open Source projects, like dotenv, that make using environment variables rather simple. However, we have yet to see a project that adds features like type safety and autocomplete in a scalable and user friendly way. We decided to fix this problem by Open Sourcing simple-env, an intuitive, strongly-typed, and scalable way to retrieve environment variables. Although this project is still very new, we’re very excited about it and looking forward to seeing how it evolves.

We aren’t just creating new Open Source projects, we’re also contributing to existing projects maintained by other awesome companies. A few years ago, we started our first collaboration via Open Source with Capital One by making contributions to Hygieia. Hygieia is now widely adopted internally as a DevOps dashboard which provides our teams with additional transparency into their builds and deployments.

More recently, we’ve worked with Spotify to make contributions to Backstage. Backstage, or “Runway” as we call it internally, has quickly become a central hub for creating new projects and has helped us radically streamline project creation. We’ve also used it to make day-to-day tasks easier, removing red tape and manual processes in favor of automation.

Finally, we’ve recently started to work with Google to contribute to Fastlane, a tool our mobile app team uses to help speed up releases.

This is only the beginning…

We’ve only just begun to scratch the surface of Open Source and what it might mean for many facets of our company and our culture. We’re committed to exploring it, using it to break sluggish patterns and cut red tape, and we’re in it for the long haul.

Keep an eye out for new Open Source projects on the American Airlines GitHub Org and stay tuned for future posts about what we’re doing to make Open Source a larger component of how we work.