Host Intro (Gene Kim)

[00:00:07.130] Thank you, Bose, Rakesh, and Jennifer.

[00:00:10.880] Okay, next speaker.

[00:00:13.000] When I saw a video of the next speaker present at the 2019 Rails Conf conference late last year, I immediately started sending links to it to all my friends, especially Dr.

[00:00:23.520] Steven Magill, who I've been working with for two years, researching the dynamics of the software supply chain.

[00:00:30.480] One of the observations made in the information security community is that the best way to stay secure is to simply stay up to date on your software dependencies. It's easy to say, but difficult to operationalize, because so often when we update our dependencies, everything breaks, which is why developers avoid updating dependencies in their daily work, and then to discover that their production applications have significant vulnerabilities in them. Which is why I'm so excited that our next speaker is going to tell her story.

[00:01:00.340] Eileen Uchitelle was literally just promoted to become a principal engineer at GitHub. She will tell us about the seven-year journey of how GitHub finally migrated from Rails 2 to Rails 5, and the increasingly dire problems that necessitated it.

[00:01:17.260] She will tell us about all the amazing benefits that it also enabled.

[00:01:21.940] She has some lessons and very specific advice that every technology leader needs to hear, because the story she tells you is happening in every organization.

[00:01:32.320] I'll also mention this. I've been so blown away in every conversation I've had with her. She has elevated what I thought great engineers can achieve and has raised the bar on what I think all engineers need to do for their organizations.

[00:01:46.580] Here's Eileen.

Eileen M. Uchitelle

[00:01:53.500] Hi, everyone. I want to first say thank you to the organizers of DevOps Enterprise Summit for having me speak today. It's an honor to be one of your keynotes, and I hope that you've all enjoyed the conference so far. I'm Eileen Uchitelle, and you can find me anywhere on the internet @eileencodes.

[00:02:09.420] I'm a staff engineer at GitHub. My focus is on ensuring that the Rails framework and Ruby language support GitHub for the long term. I work on building features and fixing bugs upstream, but also working to improve the GitHub code base to remove technical debt and build up our resilience.

[00:02:27.020] In addition to my work at GitHub, I'm a maintainer and member of the Rails Core team. The Rails Core team consists of 12 people who work together to decide the future of the Rails framework. We work on what features will be supported or deprecated, when new releases will come out, and foster our community of contributors.

[00:02:44.600] Today, we're going to talk about the past, present, and future of Rails at GitHub. While this talk focuses on our history with Rails, and in particular, our massive upgrade, the majority of things I talk about here are applicable to any application written in any language or framework.

[00:03:01.860] The original GitHub application and the majority of the application that users interact with today is built on Ruby and Rails. Over the years, we didn't prioritize upgrading and staying on the latest version. At one point, years ago, we forked Rails and practically wrote our own. We fought against the framework, we deviated from the framework, and we even wondered if Rails was right for us at all. But at the end of the day, GitHub is successful because of Rails, and Rails is successful because of GitHub.

[00:03:31.760] Once we focused on upgrading Rails, we found that running on the latest version made it possible for us to use and invest in Rails for the long haul in a way that we had never been able to do before. We're now able to change and influence the framework for our needs, while also benefiting the broader Rails community and open source ecosystem. This story is part historical.

[00:03:53.080] We'll look back at the beginning at how GitHub ended up maintaining a custom fork of Rails. It's also part technical, exploring what compelled us to upgrade our process and why it was so difficult. We'll look at the cost of not upgrading and how technical debt accumulates in your application until it starts to work against your framework.

[00:04:12.740] Lastly, we'll dive into our effort at GitHub to clean up technical debt, our commitment to open source, and our responsibility to support Rails for the long haul. Let's go back in time to the beginning. In 2004, DHH announced a new web framework called Ruby on Rails. Immediately, Rails caught the attention of the Ruby community. At RubyConf that year, DHH talked about Rails' history, how it came to be, and why it was better than existing Ruby frameworks.

[00:04:40.600] He went on to talk about his philosophy in building the framework, stating that many frameworks fail because they're built without an application to influence the architecture. He said that frameworks are retrospectives. They should be extracted, not built.

[00:04:54.340] Rails was attractive and is successful because it was extracted from a real application, Basecamp. In the early years, Rails' complexity grew slowly, and Rails 1.0 was released in December of 2005. Two years later, Rails 1.2 was released.

[00:05:09.360] That same year, Tom Preston-Werner was at a Ruby meetup in San Francisco when he showed his friend, Chris Wanstrath, a tool called Grit. Grit was a Ruby tool that allowed you to view Git repositories in an object-oriented way. It would become the basis for Git repositories on GitHub.

[00:05:25.200] After seeing Grit, Chris was immediately hooked, and a few days later, the GitHub Rails application was born. GitHub was created using Rails 1.2.3, and after a short beta, GitHub was released to the public in April of 2008.

[00:05:39.780] The next day, the Rails framework moved off of their own SVN server to using Git on GitHub. In 2009, Rails 2.3 was released. In the early days when Rails would release a new version, GitHub would quickly upgrade to get the new features and bug fixes. But sometime between 2008 and 2009, GitHub forked Rails.

[00:06:00.880] Now, remember, this was the Wild West of Rails startups. No one really knew what the future of Rails or GitHub was going to be. We weren't yet talking about the importance of upgrades or staying current with Rails master. And honestly, Rails wasn't as stable as it is today.

[00:06:17.306] I don't want to go as far as to say that Rails didn't care about performance or stability at this time, but I know a lot of app developers felt that way. It definitely wasn't a concern the same way it is today. Maybe that's because we were all kind of inexperienced back then, or maybe it was because Rails was good enough for its most important user, Basecamp.

[00:06:35.676] Maybe it was because GitHub didn't contribute enough upstream. For whatever reason, the problem wasn't that GitHub just forked Rails and added a bug fix here, a performance improvement there. It wasn't just a fork with backports from upstream.

[00:06:50.236] GitHub's fork was Rails with custom code just for GitHub. It was Rails morphed into a different framework that was built for GitHub, the way Rails was built for Basecamp. And as GitHub doubled down on their fork and added more and more functionality, Rails, of course, continued to progress at a fast pace as well.

[00:07:06.936] At the time, no one could predict or understand the cost that forking Rails would have on GitHub's application or engineering team. In 2010, Rails 3 was released, but many applications didn't upgrade due to performance concerns. The performance issues in 3.0 were a big deal. Users saw an unacceptable increase in response times, some applications seeing requests taking as much as twice as long.

[00:07:29.256] Active Record in Rails 3 was found to be five times slower than Rails 2. Despite knowing about the performance concerns, a couple of GitHub engineers started to work on upgrading GitHub to Rails 3. Now, the Rails 3 upgrade wasn't pointing at Rails 3 upstream either.

[00:07:44.116] It was still a fork of Rails 3, with GitHub's custom patches added on top. In 2012, Rails 3.2 was released, and most of the performance concerns had been completely solved. In the same year, GitHub's progress on the Rails upgrade stalled.

[00:07:58.316] It had been two years since they started the 3.0 upgrade, and the engineering team began questioning whether the effort was worth it at all. They asked each other, why upgrade when this version isn't causing us pain? Why upgrade when Rails 3.0 isn't so great?

[00:08:11.916] Why upgrade when our fork has more features? Looking at these questions, the engineering team decided the upgrade wasn't worth their time and focused their attention on other projects. The truth is that at this time, GitHub wasn't yet feeling the pain of being on a fork, and it's difficult to convince a team to upgrade when they're still feeling productive.

[00:08:31.456] You make your tests faster when they feel too slow. You refactor the complexity of that class when you need to add new functionality. But when do you upgrade? What's the incentive if the new version isn't better and your current fork is working just fine?

[00:08:45.076] If you're not feeling the pain of being on a fork or an old version, you're just not going to be compelled to upgrade. But of course, eventually, it wasn't fine. All of those why should we upgrade questions started to become suffocating for the engineering team. It became harder to find where the framework ended and the application began, as GitHub engineers started to fight against the fork and the application. Security backports were a nightmare.

[00:09:08.296] Every time Rails announced a vulnerability, GitHub was forced to manually patch it. Hiring was becoming increasingly difficult. No one wants to work on a Rails 2.3 application that doesn't even resemble Rails 2. It's harder to get up to speed, and you can't Google search how to do anything.

[00:09:22.766] Dependencies were brittle and unsupported as gem authors focused on new versions of Rails. Development was slow and painful. Working with an application that's tied so heavily to a custom fork can make adding features or refactoring code incredibly difficult.

[00:09:37.176] We realized we needed to get off a fork, or that fork was going to suffocate the application and the engineering team. So in 2014, a team of four full-time engineers and a few volunteers banded together, wrote an upgrade plan, and got to work.

[00:09:50.296] It took the team six months of full-time coordinated effort to deploy Rails 3 to production. And it's important to remember that Rails 3 here is still a fork with GitHub custom patches added in. By this time, the Rails 3 series was only receiving severe security patches, so even though the upgrade was a success, the code base and fork were still very far behind.

[00:10:11.636] The effort put into upgrading from 2 to 3 was massive, and motivation dwindled after that. It would be another two years before the 4.0 upgrade was even started. That same year, Rails 5 came out. It felt like GitHub was just never going to catch up if Rails was constantly improving and consistently releasing new versions.

[00:10:30.416] If GitHub couldn't prioritize upgrading and get ahead, how would we ever get off a fork? But in 2017, I joined GitHub. At this point, the Rails 4 upgrade was not in a good place. There was no dedicated team working on it, and the upgrade had fallen by the wayside. When I ran the build to see how many failures needed to be fixed, I found out there were over 4,000 errors. Easy, right?

[00:10:51.856] It's hard to put on a timeline just how much work and effort went into this upgrade. It's one of the hardest things I've ever done, not from a technical perspective, but from a focused and determined perspective. Upgrades are lonely, difficult, and often thankless feats of mental strength.

[00:11:06.676] In March of 2018, a year and three months after I started at GitHub, we deployed our first of three major upgrades, the Rails 4.2 upgrade. After deploying 4.2 to production, we immediately started the Rails 5 upgrade, but this time with a larger team.

[00:11:20.196] We didn't want to lose momentum or fall behind like we did before. For the Rails 5 series, I led a team of four full-time engineers and spent time perfecting our dual-boot and issue assignment process. Because we had a dedicated team and a streamlined process, the upgrade from 4.2 to 5.2 took only five months, and in August of 2018, we deployed Rails 5.2 to production.

[00:11:40.676] Both of these deploys went out with zero downtime and no customer impact. This is a huge milestone. It was the first time in 10 years, 10 years, that GitHub wasn't on a fork of Rails. It was the first time in 10 years that GitHub was on the most recent version of Rails. That's 10 years of cumulative technical debt, 10 years of fighting our Rails fork and our application.

[00:12:02.786] We had finally started to pay some of our massive debt down. By upgrading, we of course don't eliminate technical debt, but it creates a starting off point for removing even more tech debt. It allowed us to find things that didn't belong in the application that could be upstreamed or remove infrastructure requirements that were already supported by Rails internals.

[00:12:20.952] I hope that learning about our upgrade and how long it took hasn't scared you into not doing your own upgrade. The point of this talk isn't to tell horror stories. It's to show you that there is a cost to not upgrading. Refusing to upgrade is more expensive and more risky than taking the time to upgrade.

[00:12:37.172] I won't lie to you and say that upgrading doesn't come with a cost. It is expensive, and it is time-consuming, but you can say, "This upgrade will take X number of engineers and Y number of dollars for Z number of hours." You can measure that cost and decide whether that's too expensive or not. But at the end of the day, it doesn't matter what the dollar value of upgrading your application will be because the cost of not upgrading is immeasurable. You cannot quantify the cost of not upgrading. We can't actually measure how much it costs GitHub to fork Rails and not upgrade, how many extra hours it took to figure out how to do something in that fork that could easily be done in a standard Rails version, how many extra hours it took to manually patch security vulnerabilities, how many potential hires we lost, how much time we spent re-engineering features that were in later versions of Rails already.

[00:13:23.072] Not upgrading your application will eventually cost more than any upgrade because of these reasons. This is true whether you're using Ruby or Elixir or Java. In addition to the high cost of not upgrading, often teams say they aren't upgrading because it's too much of a risk.

[00:13:39.292] My unpopular opinion after doing many upgrades is that upgrades are not inherently risky. We worry that changing the underlying foundation slightly will take everything down, but if we're careful, if our applications are well-tested, and we build up risk tolerance and confidence through incremental deploys, there is no reason to think that upgrading is higher risk than not upgrading.

[00:13:59.532] There's also no reason to think that upgrading is higher risk than any PR that anybody on your team is deploying right now. In many ways, not upgrading and falling behind is drastically riskier than staying up to date. When you don't upgrade your application, you have to become a security expert. Rails, like many other programming languages and platforms, drop support for fixing vulnerabilities in older versions because it becomes untenable to support them. Think about that.

[00:14:24.032] If the team that builds and maintains the software that you're using thinks a version is too old to accurately support security patches, why would you continue to use that version or think that you're able to do better? If you're using an unsupported version, your team ends up being responsible for understanding and patching that security vulnerability yourself.

[00:14:41.262] It's extremely hard to get this right. When you don't upgrade, you lose out on great talent. Bootcamp grads, college grads, people changing careers, people changing jobs, all kinds of engineers aren't learning Rails 2, and they definitely aren't learning your weird custom fork.

[00:14:56.412] These engineers not only don't want to work on an old version, they might not even have the knowledge of how it worked. Engineers will turn down the opportunity to work for you if you're on an old version because it doesn't let them contribute to open source, it's no longer Googleable, and it's 10 years old.

[00:15:11.012] When you don't upgrade, some of the libraries you rely on will get abandoned or deprecated, so you'll either have to live with bugs or fork yet another dependency. New gems may not support old versions of Rails, so you won't be able to use those if you're relying on an old unsupported version. This makes development harder.

[00:15:27.912] Every dependency becomes more difficult because you're so far behind. Maintaining old libraries on top of your old framework gets tedious really quickly, and you're going to lose engineers because of it. When we don't upgrade Rails, you end up building more and more infrastructure on top of your fragile application.

[00:15:45.252] I've seen this firsthand at GitHub. We have tons of infrastructure code in our app, multiple databases, CI tooling, our own job queue, and countless monkey patches. Ideally, your application would consist only of code that makes up your product.

[00:15:58.092] Because GitHub's value is not in that we have code that makes multiple databases work in Rails, our value is in our community, in our repos, in our issues. Of course, multiple databases allows us to keep our application up and running, but it's not why anybody would sign up for an account.

[00:16:14.552] The infrastructure code makes development more painful because of how tightly it couples an application to framework internals. Minor changes can easily turn into massive refactoring or abandoned projects altogether. But the biggest cost of not upgrading is that someday someone will decide that using Rails or whatever language you use was a mistake, and that it's time to do a full rewrite on your application.

[00:16:37.812] I don't care what language your application is written in. Regardless of the language, rewriting your application is extremely expensive. If anyone on your team says that an upgrade costs more than a rewrite, that person is lying to you.

[00:16:50.092] At this point, hopefully, I've convinced you that that upgrade that you're putting off is important and needs to be moved up into your goals for this quarter, not next quarter. But you're wondering how you're going to accomplish this Herculean task.

[00:17:01.832] The key to upgrading any application, regardless of language, is to incrementally pay off cumulative technical debt that you've incurred and figure out a plan to keep that debt paid down. I won't stand here and tell you that upgrading will be easy.

[00:17:14.212] I will leave that to the person on Hacker News who wondered why I couldn't do it faster if they did their upgrade in a weekend. The upgrade did take a long time, but it wasn't the only thing that I worked on. I worked on our technical debt. I deleted unused features.

[00:17:29.652] I rewrote our custom test framework so that we could be more confident in changes we were making. I improved our database handling for development and test. It's unfair for anyone to look at our upgrade timeline and decide that using Rails was a mistake, that it's too expensive.

[00:17:43.781] We made choices at GitHub over the years that made upgrading harder. You have also made choices over the years that will make your upgrade harder, regardless of language. But that doesn't mean that Rails is a bad choice. Technical debt is real, and you and your team need to make decisions about what debt is acceptable and what debt needs to be cleaned up.

[00:18:01.252] At GitHub, we decided being behind Rails master is no longer a technical debt we were willing to put up with. You can slowly work on technical debt and upgrade Rails to get your application in a better place. But there are a few things that you should consider when upgrading and many mistakes to avoid so that you don't end up doing a multi-year upgrade like we did at GitHub. The first most important step is to build out a team.

[00:18:23.652] Upgrades are difficult, and it helps to have a team that can support each other, bounce ideas off of, and to make sure momentum keeps up. If you have a one-person upgrade team and that person leaves the company, your upgrade is going to be stalled. Make sure to create redundancy and support for such a difficult and important task. And lastly, reward this work.

[00:18:41.462] Don't just reward feature development. Maintenance is far more important, because you don't get to develop features if your foundation is crumbling. Another thing that makes upgrades easier is take time to plan your upgrade.

[00:18:53.252] Look at release notes, plan for deprecations, identify unmaintained gems. There are clever ways to make upgrades easier and less painful. At GitHub, we built a dual-booting CI so that we could test all of the same code in the product for multiple Rails versions.

[00:19:06.652] This allowed us to prevent regressions in all new code while we fixed older code. These are things to consider. There are lots of things to consider before starting your upgrade, because upfront investment might save you time and money later.

[00:19:21.312] You can also make your upgrade easier by fixing deprecation warnings early. Don't ignore them for the next version to take care of, because then they're going to be errors. It's much easier to take care of deprecations when they're warnings, because you can do them at a slower pace.

[00:19:35.252] It'll make your upgrade go a lot smoother. Now, once you've upgraded to the most recent version, make a plan for future upgrades. How often are you going to upgrade in the future? Are you willing to test new releases in the beta or release candidate phase?

[00:19:47.472] This makes upgrades smoother, because you can tell maintainers what was hard and what broke so they can make the version more stable for next time. Maybe they'll even ask for your help even earlier than that. If you've invested in upgrading, then it makes sense to invest in future tooling that will help you keep out of upgrade debt in the future.

[00:20:05.892] So now that we've looked at some considerations that you should make when upgrading, we're going to look at some things that you will definitely regret if you do them. Something you will regret in the future is forking your framework.

[00:20:16.872] It doesn't matter whether it's Rails or Phoenix, forking is a terrible idea. Don't do it. I highly recommend that you do literally anything else besides fork. The choice to fork Rails and deviate from upstream was the single most expensive choice we made at GitHub in regards to our application.

[00:20:33.452] This had a compounding effect on the state of the codebase that made our upgrade take years. If we had just done it when the version was released, it would have taken less than a few months for each version. Another thing that you may regret down the road is falling behind on security releases. If you don't make sure your software is getting upgraded to the point where maintainers no longer provide security patches for your version, then you're going to have to do it yourself.

[00:20:58.732] This is really dangerous because you might not know how the vulnerability even works. Unless you have a security team intimately familiar with the software vulnerabilities, it's going to be really hard to make sure that you're patching all endpoints. And it's going to make your security audits a lot more difficult.

[00:21:15.872] It's much easier to verify that you're up to date than to explain that our app is way behind, but you definitely patched all those vulnerabilities manually. Lastly, you'll likely regret deprioritizing upgrades. In the past, I've given this talk to many individual contributors.

[00:21:29.592] I have never given this talk to an audience of mostly upper management and company leaders until today. So this section is for you. The only people at a company that can make sure upgrades are prioritized and properly staffed, rewarded, and supported are company leaders.

[00:21:43.992] It's up to you to make sure this kind of work is valued the same or more than product development, because the language your application is written on is your foundation. Failing to upgrade erodes that foundation and makes your application more brittle and more unstable. If I could go back in time to before I worked at GitHub and before we forked Rails, I would tell leadership to reconsider their decision to ignore the upgrade. I would tell them to staff a team and to make sure that upgrades happen all the time, as soon as possible. The best time to do an upgrade is immediately.

[00:22:15.672] Every day that you wait to upgrade, the more painful it will be, because the codebase is constantly evolving as your version falls behind. Hopefully by now I've convinced you that there are a lot of negative consequences to not upgrading. But what positive benefits do you get by prioritizing this work?

[00:22:34.212] Besides avoiding the pain, what kind of benefits are there? When you prioritize upgrades, you get access to improved APIs. Major version changes allow maintainers to rethink how previous features were designed and whether they can be improved for the next version.

[00:22:50.292] In Rails 6, we improved multiple databases by extracting all of the handling for that out of GitHub and putting it into Rails. Before Rails 6, adding multiple databases to an application was awful and really hard. You had to write a ton of code yourself, but in Rails 6, we've added new APIs for establishing and handling connections, as well as an improved API around Active Record database configurations.

[00:23:13.212] Without upgrading, you don't have access to these improvements. Upgrading to a new version also gives you access to security features. In addition to security upgrades being easier if you're not behind, each version adds new security features to protect your application and your users from bad actors. Since these are security features and not vulnerability patches, the only way to get them is to actually upgrade. They will never get backported.

[00:23:36.272] Upgrading often provides you with performance improvements. While most of this talk today has been about Rails upgrades, we recently did a Ruby 2.7 upgrade at GitHub. We found that running on this version reduced our production boot time from 90 seconds to 70 seconds.

[00:23:51.652] Performance improvements on the language level benefit the entire application in a way that one-off application-level performance improvements just can't. Upgrading also gets you access to new libraries. Rails 6 has shipped with brand-new libraries like Action Text, Action Mailbox, and Zeitwerk. By upgrading, you can rely on great new features in Rails without building your own infrastructure tooling into your application.

[00:24:14.292] As I said before, in an ideal world, your application would only contain code that pertains to your product. If your product isn't about sending mail, why should you have to write code that sends mail? Upgrading Rails keeps the line where Rails ends and your application begins crystal clear. And lastly, upgrading your application gives you a chance to contribute upstream. It's really difficult to fix bugs, add features, and influence the future of your language or framework from an old version. A lot of times we complain that our language isn't fast enough, or our framework is missing a feature, but that's the best part about open source is you can change it. If you don't like your language, fix it.

[00:24:51.822] While all of these are good reasons to upgrade, this is the one that kept me going. This is the reason that I spent a year and a half on the Rails upgrade. It was so that GitHub could influence the future of Rails. For GitHub, this is the biggest and most important reason to upgrade.

[00:25:07.502] By upstreaming features, fixing bugs, and supporting Rails' future, we support our future as well. When I look back at when I started the 3.2 to 5.2 upgrade, the thought of being on a modern version of Rails and actively contributing upstream felt like an unachievable fairy tale. We were so far behind, and I wasn't sure that I could finish it, at least not while maintaining most of my sanity.

[00:25:29.962] But now running on Rails master and supporting the future of Rails is GitHub's present and future state. Since upgrading Rails, GitHub engineers have sent over 200 pull requests that improve performance, fix bugs, and add major functionality to Rails. And many of these contributions were first time.

[00:25:46.522] Before we upgraded, we often were forced to add a monkey patch or work around bugs in overly complex ways. Using the most recent version of Rails has allowed us to not just contribute upstream, but to make choices that improve our application instead of hinder it.

[00:26:00.762] And anyone who uses Rails benefits from those changes as well. Our goal is to never fall behind again. We're investing in our application and in Rails by doing continuous upgrades. Every week, we bump our Rails gem and run all of GitHub's tests against the new version. We find regressions quickly, often within hours or days of when they were introduced to Rails, and get them fixed before anyone ever experiences them.

[00:26:24.742] This has created a symbiotic relationship between GitHub and Rails, where we develop the framework and code and applications side by side. Since we did the hard work of upgrading our major versions, this new process means that we never fall behind, and upgrades are easy because we're doing them as Rails changes instead of many years later.

[00:26:45.902] Continuous upgrades in our contributions to Rails are evidence that for the first time in GitHub's history, we're not just using Rails or simply building a Rails application. For the first time in GitHub's history, we're pioneering the future of Rails.

[00:26:58.002] GitHub and Rails are being co-developed together side by side. We're extracting code from GitHub, building new features that will help you scale Rails, and giving back to the open source community to support Rails for the long haul. It makes good sense for us to do this.

[00:27:13.142] Not only do we give back to the community, but it helps us keep our application focused on our product. We can reduce complexity and improve resilience, all while influencing the future of Rails. At GitHub, we not only need to do this for our application, we have a responsibility to support Rails.

[00:27:30.522] We owe part of our success to the Rails framework, and we have the influence, expertise, and application to help push Rails forward. Every single company in the world, big or small, is able to do this work. You can upgrade. You can influence your framework.

[00:27:43.862] You just have to make it a priority. Upgrading Rails was a huge investment. It wasn't cheap, but it was definitely worth it. Upgrading Rails has opened up a ton of possibilities for our future, and we have a bright path ahead of us. We're building features faster, we're more confident our code base is stable, we're improving the scalability of Rails, and we're giving back to the open source community.

[00:28:05.102] At a minimum, we went from being crushed by our application, Rails, and the decisions that we'd made, to building up our application, to building up Rails, to building up our community. Upgrading Rails gave us freedom and flexibility that we didn't have before.

[00:28:18.822] It empowers our engineers to build more and build better. In 2007, GitHub was born, and 11 years later, we're finally tracking Rails master. It took seven years from the day the 3.0 upgrade was started to the day that the 5.2 upgrade was complete.

[00:28:32.652] The future is bright, and I can't wait to see what the next 10 years allows us to extract from GitHub, build in Rails, and how the community thrives. At GitHub, we'll continue to invest in the future of Rails in our community because we have to, because we need to, because we want to.

[00:28:47.202] I hope that this talk has inspired you to make upgrading and investing in your language or framework a priority. It doesn't matter what language your application is written in. This is important work that needs to be supported and rewarded.

[00:28:58.822] Like I said before, if you don't like your framework or language, change it. This is how you build and maintain a strong foundation for your application and your company. For us at GitHub, we'll continue to invest in the future because GitHub and Rails are in it together for the long haul.

[00:29:14.182] Thank you.