Technical debt can become endlessly depressing. But it does not have to be depressing. In fact it can be a good sign of project growth, and is manageable with the right skills. For an open source software, ideally your project will receive enough attention and volunteers to keep the levels of technical debt manageable.
For software products, technical debt accumulates when a software release takes priority over optimized code. If left unmanaged, it affects the ability for the project to continue to function. For open source projects, technical debt can appear unexpectedly. For instance, if volunteer developer numbers drop off, and there’s less consistency and maintenance of a project over time, then technical debt builds up.
For smaller open source projects, code that’s not optimized or managed over time, is not as big a deal. Especially if you’re managing or volunteering for a project in your time outside of work hours. However, larger projects providing critical infrastructure, like OpenSSL for instance, can run into major problems if technical debt is left unmanaged.
All projects, both private products and open source, have some kind of technical debt. If you don’t make a plan to manage that debt, small bugs build up overtime and can cause a codebase to run slowly, and test even more slowly. There are a range of other consequences that can build up when technical debt is left unmanaged.
Consequence of technical debt
In their book, Managing Technical Debt, Ipek Ozkaya and Robert Nord identify several stories of how technical debt slows down the innovation cycle and growth of different businesses. They identify some of the most common consequences of technical debt:
- A project filled with quick solutions that do not scale.
- Distribution of the library, with components scattered across repositories
- Little to no automated testing or documentation, which causes slow test runs and confusion
- Disorganization in applying team skills – unclear how to handover work, and delegate
A consideration here is that these examples all come from privately operated and large-scale projects. However, large-scale open source projects with many contributors can also run into these problems. Especially the problem of disorganization in team skills, and how the code repository is organized (or not organized in some cases).
To focus specifically on the team aspect, what makes technical debt management in open source projects differently challenging (as compared to private software), is volunteering. Why? Because volunteers bring with them a diverse range of skills and insights into the best ways to manage technical debt.
Remember how many volunteers run open source projects
Most open source projects run on volunteer effort, and therefore take different skill sets onboard. However, managing technical debt requires these skills:
- Time management
- Testing experience
- Code Architecture experience
- Establishing and improving contribution standards
- Regular auditing and review scheduling and management
If your project is experiencing growth, and you need to bring these skills to your project, then applying for or obtaining funding or another form of resources to support a project manager is a step in the right direction.
One method to obtain resources is getting and securing investment. GitHub established an investment program, and there is another method – supporting open source projects with an associated business.
Gathering resources to manage technical debt
Supporting an open source project with an associated business is another pathway you can explore for taking charge of technical debt. Using their own business as an example, Aaron Stannard (the CEO and founder of Petabridge) explains how that’s possible:
- Petabridge provides its expertise for businesses who are taking up and using Akka.net.
- Expertise services provide resources and funding to make Akka.net a sustainable open source project, and employ project managers to take charge of technical debt in the open source project.
- Akka.net can then continue to provide a software solution for distributed computer programming.
You don’t have to shape a business around your project to make it sustainable, but it represents a tested pathway toward managing technical debt.
Stannard introduced four criteria for defining an associated business to support an open source project’s success:
- Provide a service for technical complexity. If your project gets complex enough that it would not be feasible for customers to build it themselves, then provide support.
- Support multiple parts of the customer's business. Seek out a way for your project to provide support for more than one aspect of a business. This one can be hard to put into practice since open source projects can be singular in their design. Remember that additional services do not need to be as complex as the core service.
- Embody a major improvement. Your project can also offer a departure from current options available. As long as it provides a substantial change above what is available, incremental improvements to existing projects may not provide a strong solution for potential customers.
- Offer an understandable business value to end-users. This is where the narrative element comes into play. We’ve written a recent guide to applying the ABT storytelling model to projects you are working on to construct narrative. Clearly communicating the value of your project is vital.
Deciding how to handle technical debt
To decide if a change in resources is needed, consider your polling –- issues, pull requests, and stars. These metrics are all viable sources of feedback, and should be considered before making changes.
To reiterate, even if you don’t start a business out of your open source project (especially if you’re not creating a project for commerce and profit), the criteria can help your library or application become organized and direct. An organized and direct pitch makes communicating the value of your project easier. The result is you can attract contributors and build communities who can help you manage technical debt. It doesn’t have to be depressing, and you can gather resources and more support for your project. Your technical debt can become a sign of growth and expansion.
TinyMCE has always been an open source project, and you can see how TinyMCE is going on GitHub. And if you’re building an open source project that involves the TinyMCE rich text editor, you can contact us to find out more.
