I’ve been writing and using open source software for 20 years. My earliest memory of an open source upgrade is Ubuntu 5.04 in 2006. Back then upgrades were so unstable that I spent an evening backing my laptop up to a few dozen CDs in case something went wrong.
As OSS has evolved from a social movement for user freedom to dominating commercial software development, the relationship between open source maintainers and the companies that rely on them has grown more complicated. Open source software is constantly changing. Maintainers release new versions for bug fixes, security patches, and new features. Documentation may be lacking, or non-existent. Upgrading these dependencies is toilsome work.
I spent a year as a consultant helping teams with large, outdated apps. I upgraded their apps and set them up with ongoing maintenance programs to stay up to date going forward. I found myself doing the same things over and over. The right way to tackle a large framework upgrade is to break it apart into a series of small steps that are individually safe and accumulate in being upgraded. Breaking upgrades apart lets you parallelize them, reducing drag on the team. It’s also safer - making these changes individually ahead of time makes it much easier to identify a regression, decreases the blast radius of any missed breaking change, and lowers the chance that your final framework upgrade goes wrong.
But breaking major upgrades apart is hard planning work that includes risky unknowns - things like other blocking dependencies that might need to be upgraded first, breaking changes you weren’t aware of, and abandoned dependencies that may be incompatible with the newer version you’re targeting. It can also be completely overwhelming. Many teams that have fallen several major versions behind don’t know where to start. Though it takes an engineer to do this work, very little of it is actually coding.
We founded Infield with the mission to make open source software as easy to upgrade as Chrome. Today, we’re launching our upgrade management system and releasing our first automated upgrade product, which we call Upgrade Path.
Upgrade Path breaks complex upgrades into incremental, safe steps. We do this by connecting to your code, reading the changelog for every package you rely on, and running an optimization algorithm that solves for the best path. The result is a plan not just for your framework (e.g., Rails) but also for all your other dependencies that need to be upgraded along the way.
Upgrade Path takes care of all the planning and research work involved in upgrading. By unblocking engineers from the toilsome work of ordering and releasing upgrades, they are free to spend more time on feature development.
Upgrade Path also serves as a project management and coordination tool for teams across the organization - the Product, Security, and Platform Engineering teams that rely on each other to maintain and ship apps. Each team can view the upgrades that need to be done and those that have been completed, and they can make notes on how the work that Upgrade Path suggests applies to their specific codebase. In this way it serves as a record of the upgrades that have been done over time, showing progress toward making the enterprise more secure, agile, and ready to make use of the latest and greatest that open source has to offer.
Over time, we hope to automate away more and more of the toil involved in keeping open source dependencies on their latest versions. In this way we can make our own contribution to the world I first entered 20 years ago, and make open source a more sustainable and reliable part of every company’s codebase.
Top comments (0)