Code Curation

1. Introduction

With any software project there is a point where the system is no longer being actively developed. A phrase I have heard a lot is that it has been put into maintenance mode. That often means the software is mature or feature complete, but it can also mean resources have simply been redirected elsewhere.

Work may still happen, but usually only in response to a bug or security issue. That reactive approach can sustain basic functionality in the short term, while allowing the software to decline quietly in the background.

Third-party dependencies, runtimes, hosting environments, and frameworks evolve quickly. Angular versions and Kubernetes releases can move out of support far sooner than people expect, leaving unmaintained systems exposed to obsolescence, security risk, and expensive catch-up work.

2. Core elements of code curation

2.1 Dependency analysis

One of the first steps in moving away from pure maintenance is understanding which dependencies are being used and what their lifecycles look like. This is useful even if you do not fully adopt code curation; any company providing a software system should understand the components it depends on.

This information becomes the basis of a Software Bill of Materials. Dependencies are not just third-party libraries; they include runtimes, hosting infrastructure, platform services, and anything else needed to provide the product to the end user.

The analysis needs to happen regularly because the information changes over time. A sensible approach is to review high-risk items monthly and low-risk items every six months. The same insight is also useful for actively developed projects because it gives teams real upgrade deadlines to plan around.

This should be a team exercise. Everyone involved in the product should understand the impact dependencies have on the system.

2.2 Regular code analysis

Automated dependency and code analysis is often wired into CI/CD pipelines. That works for active development, but it is not enough for maintenance mode. If the codebase does not change, a pipeline may not run, and new vulnerabilities can sit unnoticed for months.

Code curation makes analysis proactive. Scheduled scans should run even when the code has not changed, because the risk landscape can change independently of your repository. A dependency that was low risk during the last build can become high risk when a new vulnerability is published.

• Use scheduled jobs, GitHub Actions, serverless tasks, or cron to trigger scans.
• Use tools such as Snyk, OWASP Dependency-Check, Dependabot, and SonarQube.
• Alert on meaningful thresholds so teams are not flooded with noise.
• Review the results periodically and use them to adjust the curation plan.

2.3 Planning work from dependency insight

Dependency analysis only helps if it turns into work. The next step is to translate end-of-support dates, risk scores, known vulnerabilities, and impact assessments into a roadmap.

Prioritise high-risk items first: dependencies with known vulnerabilities, impending support deadlines, or broad impact across the product. Security fixes may need immediate attention, while lower-impact upgrades can be batched.

A practical roadmap might include weekly or bi-weekly checks for critical issues, monthly or quarterly work on medium-risk upgrades, and annual planning for major migrations. Each planned update should include testing and rollback thinking, especially for dependencies with a history of breaking changes.

3. Moving towards code curation

3.1 Planning the transition

Moving from reactive maintenance to code curation needs a deliberate rollout. Start by assessing the current codebase with dependency analysis, code quality metrics, and team workshops. Identify painful areas, unsupported components, high-maintenance dependencies, and legacy sections that regularly create defects.

Define measurable goals, such as reducing vulnerability exposure, pruning unused dependencies, or bringing critical frameworks back into support. Start small if needed: one repository, one module, or one service is enough to prove the habit.

A phased roadmap works well. Phase one introduces automated tooling and an initial audit. Phase two integrates curation into normal delivery work. Phase three establishes review cycles, metrics, documentation updates, and recurring ownership.

3.2 Securing management buy-in

Management support is often the deciding factor. Code curation can look like a nice-to-have when a system appears to be working, so the business case needs to connect it to risk, cost, efficiency, and optionality.

• Show how reactive maintenance leads to emergency fixes and expensive upgrades.
• Use dependency data to demonstrate real security, compliance, and support risks.
• Highlight quick wins from automated scans or unused dependency removal.
• Propose phased investment tied to measurable milestones.

Common objections are predictable. If curation feels too expensive, compare it with the cost of outage recovery, urgent migration, or a product that no longer builds. If the team is too busy, start with a pilot and prove that small regular work reduces future firefighting.

4. Summary

Code curation is a proactive alternative to reactive maintenance mode. It uses dependency analysis, scheduled code scanning, deliberate planning, and management support to keep mature software buildable, secure, and ready for change.

The approach requires upfront effort, but it reduces the long-term cost of technical debt, avoids unsupported dependency surprises, and protects the organisation from the quiet decay that can happen when software is treated as finished.

5. Final thoughts

There are always risks with software that is not constantly maintained. Code curation mitigates those risks with regular tasks that should not be too onerous. You do not want to discover that your product no longer builds at the exact moment you need to apply an urgent security update.

I have also found this thinking useful for actively maintained projects. Knowing the deadlines for upgrades is invaluable for planning, even when a product is still changing every week.