Here's the situation: You want to use a piece of open source software, but you can't because it has a show stopping bug. What do you do? If you said 'make a fix and send in a pull-request,' Congratulations! You're right. Here's another: You're running a piece of open source software in production, and discovered a show stopping bug. What do you do? What if you can't wait for upstream to merge the fix? You're in the business of maintaing and deploying a downstream fork of the sofware. It's very common, it's not bad, and it happens with software projects of any size at companies of all sizes.

I've done this 'fork maintenance and syncing' job at three different employers and with mulitple code bases. I'm going to tell you everything I know about the problem space, how to do it well, where the tradeoffs are, and where some danger lurks.

Briefly, this includes:

• Bringing down latest upstream changes
• Applying and merging local changes
• Submitting and shepherding local changes to upstream as pull requests
• Handling when a local change is merged upstream and needs to be brought down
• Producing testable/deployable code snapshots/artifacts
• Automation of the pipeline

After this talk, you should understand the benefit and necessity of deploying open source code from local forks and not from upstream. And you should understand some of the methods of managing and syncing those local forks with the upstream code base, as well as the tradeoff between complexity and flexibility in those methods.