The daily or weekly household chores – the unending litany of small tasks that never really go away. Sometimes, it’s tempting to just avoid them. It’s so much easier to grab a fresh glass from the cabinet than cleaning the one in the sink. But if you consistently ignore those small tasks, they quickly pile up – and suddenly you face a nightmare of work. A pile of dishes, a mountain of laundry, a houseful of cleaning in front of you. True in life, true in software development. When you ignore software “housekeeping” or maintenance tasks, you quickly accumulate a mountain of technical debt.
What is technical debt? No, it’s not falling behind on the latest social media app, nor is it your ballooning backlog of unread emails. Specifically, technical debt is the backlog of change or lack of change that you assume responsibility for.
Technical debt is really the price of progress and change. And software is nothing but accumulated change. It’s nearly impossible to avoid carrying some amount of technical debt – the real challenge is understanding how much you have, and establishing a strategy for managing it. Not every change needs to be dealt with immediately, but technical debt gathers interest – and in short order, you may be faced with more than just a minor update. Your patches have patches and your dependencies are broken. You might find yourself so far from current (or source) that the once small job of updating is now a significant project on its own.
For a commercial product, technical debt is kept at bay through the many updates pushed out by vendors to its users. If you’ve been to the App Store lately to update your phone apps, you’re clearing out technical debt. For many, it’s automatic and taken care of in the background while you’re away or asleep. For major system updates in an IT setting, updates are planned events – not taken lightly or without careful thought. In both cases, the old is brushed aside and the new is put in its place. Not unlike a fresh tablecloth on the kitchen table.
But in the open source world, technical debt can be more challenging and less automatic – and something to proactively monitor. When you “inbound” open source code and incorporate it into your project, product or processes, you should strive to keep your copy of that code current with the original, or canonical version. When you stray, your technical debt balance starts to grow. Here are two simplified scenarios that result in increasing technical debt.
Scenario 1: Consuming open source
You’ve forked open source code and included it in your product or processes. And you’ve made some changes to that code to improve it. However, you neglect to push those changes back to the original source (upstream). Congratulations, you just created technical debt. You now have a unique version of that code that you get to maintain. And your improvement can only be enjoyed by you – the rest of the community doesn’t benefit. And your solution risks being very narrow in purpose and fragile, for a community of experts won’t be able to help you make it better. In sum, it’s a costly, selfish and closed approach to open source.
Scenario 2: Static stasis
Like scenario 1, you’ve included open source your project, product or process. It’s perfect, and you don’t make any changes to it. However, you’re so content that you lose track of the original project and fail to update your code. For a very long time. You miss patches, bug fixes and more. The next time you look, you’re so far behind you barely recognize the two sets of code as even related. This too is technical debt – accumulated by your lack of change.
Tips to tackle the challenge
Both situations result in added technical debt. How much debt you and your organization are willing to carry depends on your situation. But technical debt must eventually be paid down, sooner or later. In some cases, the decision to carry technical debt and drift from the original code is purposeful – there’s a business and technical strategy associated with it. But many times, it’s inadvertent, and stumbled into without really understanding the true costs. Here are some tips to keep in mind:
Operate in “upstream first” mode
Whenever you make a change, prepare to contribute your change back to the project. The more you give back, the more you benefit. You’ll not only reduce your maintenance burden, you’d be giving back to the project and establishing yourself in the open source community. Linux Kernel maintainer Steven Rostedt shares his tips on getting your code upstream and notes that your change “will be maintained at a higher standard than you would likely be able to achieve alone. It’s hard to think of a circumstance in which code can’t benefit from external review.” In sum, the more eyes on the code, the better.
Avoid becoming an “accidental project maintainer”
You didn’t see it coming… you forked a project… you changed it… and changed it again. And suddenly, the fork has drifted so far from the original project, you find yourself the sole maintainer of an internal project. Keeping it to yourself, for yourself means you miss out on the potential active contributions of the open source community. They spot issues and fix them. They add features and support them. That’s the superpower of the community. Now your time is increasingly diverted to code maintenance rather than creating the next “big thing.” And that defeats the very reason you chose to include open source at the outset: to avoid building or maintaining a thing that’s already standard or commodity-like so that you can spend more time creating differentiated code.
Keep it Current and Mind your Dependencies
When you adopt open source code for any purpose, stay close to the source – track it upstream. Know when it changes and why – watch for important patches, updates and changes. Establish processes to keep your local source mirror current with the upstream will ensure you have the latest bug fixes and security patches, as well as encourage careful management of any changes you carry on top of this ever evolving base. Always understand the impact – monitor your dependencies to ensure you know the consequences of an update or patch. Unlike a software subscription or license agreement, no one will reach out to you and remind you to update – that’s your responsibility.
According to Darren Hart, Sr. Director of VMware’s Open Source Technology Center, “… technical debt is the maintenance burden that accrues when we fail to acknowledge the operational cost of choosing open source components and don’t deliberately commit to keeping them current.” He goes on to say, “When you choose open source, you also carry the obligation to yourself, your users/customers and the community to engage with the project community by reporting issues, sharing use cases and upstreaming your fixes.”
Using open source generally means contributing and assuming responsibility for staying current – tracking to upstream. And that’s a good thing. By giving back, you do yourself a favor (reduce your technical debt) while helping the community. It’s a win-win. But if that’s not a commitment you’re convinced you can keep, know the impact and be prepared to reconsider your decision to use open source software. You may be better served by proprietary software or a vendor-supported distribution of an open source solution.
