One of the things that you’ll find in the world of corporate open source is that we tend to talk a lot about money. This makes sense of course, since open source has had a significant and lasting financial impact on the economics of software development. At the same time it also provides a useful metaphor for why we do what we do.
These days, the Leveraged Development Model is pretty well understood: We all put a bit of development into a project, and in return we get to reap benefits far greater than the value of our own contribution. This dynamic is the main driver behind the saying, “Software is eating the world, and open source is eating software.” At this point, it’s virtually impossible to deliver a software product on time and within budget without open source; this is all the more true when your competitors are actively doing the same thing. Basically, you use open source components, or you get left behind.
How Technical Debt Accumulates
It continues to be a great time to be in open source software. However, we can’t spend all of our time building muscle without also pausing occasionally to take a bath. When developing product software, the tendency is often to use open source components, and then apply internally-developed patches for performance, custom features, and so on. Over time, this out-of-band code accumulates. If left unchecked it can result in an unwieldy codebase that is complicated to port forward to new products at best. In the worst case, the sheer complexity and communal knowledge required to maintain such patches can open up surprising and unexpected attack vectors.
The reason this code accumulates really comes down to three things.
- There are genuine changes that need to be made to make the complete product ready for market. Configuration for internal build systems and support for product-specific extensions are legitimate reasons to maintain out-of-band patches, particularly if they only apply to your product and won’t be accepted upstream.
- The development team is under pressure, and doesn’t have the time or skills to push their code upstream. This is a tricky one. Everybody is in a rush, and it’s rare to have an actual break in the product development cycle once the current product ships.
- The code has “always worked,” …and nobody is left who understands how. This is by far the worst possible scenario because it almost always leads to a house of cards situation, with patches on top of patches on top of hacks on top of workarounds. These software stacks tend to be both fragile and bloated: the last thing you want to deal with in a product on a tight release cycle.
All told, these are significant contributors to a product’s technical debt. And, much like financial debt, once it accumulates you can easily find yourself spending more time and money dealing with the interest, rather than paying down the principle.
Clear Technical Debt to Empower Product Teams
The typical advice in these situations is to simply contribute the code upstream. If it is good code and it improves the project, it’ll be accepted and taken into account as the project evolves. This means less out-of-band maintenance and fewer workarounds, particularly as the upstream project changes over time. This is solid advice, but it’s often easier said than done because the process can be intimidating and time-consuming the first time around.
This is where teams like Samsung’s Open Source Group comes in. Yes, we do have open source rockstars who write some pretty awesome code and maintain super-strategic community projects like Linux, Wayland, Gstreamer, and a bunch of others. But we also help other groups in Samsung flush their technical debt, so they can focus less on carrying out-of-band code forward, and more on features and optimizations.
In some cases, this means helping product teams refactor code into a proper patch series so that it can be accepted upstream. In others, we fly to Samsung’s global headquarters and hold in-person workshops on how to become good upstream contributors. Either way, an important part of our roles in the Open Source Group is to pass on what we know about getting code upstream. This helps both Samsung and the open source community by improving the open source technologies the company uses while increasing the the diversity of contributions and the overall functionality of the code base.
It’s easy to fall into the “We’re JUST going to do it one more time for this product,” technical debt trap. Thankfully, there’s typically a way out of it; it simply takes a little bit of planning and some help from people who have done it before. That’s why groups like ours exist and why numerous major technology companies have created dedicated open source development teams similar to us. Simply put, these companies have learned the value of direct involvement in open source communities and are putting the human infrastructure in place that’s necessary to be successful in this effort.