SMP introduction

What is an SMP

A Software Management Plan (SMP) is a living document that outlines how research software will be developed, maintained, shared, and preserved throughout its lifecycle. It covers key aspects such as technical decisions, roles and responsibilities, licensing, documentation, and long-term sustainability. As the project evolves, the SMP can be updated to reflect changes in goals, technologies, or team members. By creating and maintaining an SMP, researchers can ensure that their software is well-organized, easily accessible, and adaptable for future use, contributing to its long-term impact and alignment with best practices, including the FAIR principles.

Why write it

An SMP is a tool for planning, organizing, and future-proofing your research software, not just a form to be filled in. The document is the by-product; the value is in the thoughts it encourages, and in having the answers written down where your future self and your colleagues can find them. Here's why:

• Avoid future headaches: Plan early for software maintenance and updates, so you’re not caught off guard when environments or dependencies change.
• Clear roles and responsibilities: Define early who handles maintenance, releases, and post-project support.
• Informed technical decisions: Make key choices about tools, programming languages, and resources up front, preventing costly changes later.

Additionally, an SMP is immensely helpful in aligning your software with the FAIR principles:

• An SMP encourages you to think about how your software will be documented, cited, and made available in appropriate repositories and registries with metadata, making it easier for others to find. → Findability: It motivates assigning unique identifiers (like DOIs) and creating rich metadata.

• By considering how your software and metadata will be stored and accessed, an SMP helps you plan for long-term availability, even as technologies or team members change. → Accessibility: Planning for software storage and retrieval ensures long-term accessibility for users.

• An SMP encourages you to adopt standards and formats that allow your software to work well with other research tools, datasets, or systems. → Interoperability: This improves the software’s ability to communicate and integrate with other tools, supporting interoperability.

• Planning for clear documentation, proper licensing, and explaining how the software can be used or adapted ensures that others can build on your work in future projects. → Reusability: Your software will be easier to modify, extend, and apply in different contexts.

Read more about the reasons, motivations, and considerations in the Software Sustainability Institute article Writing and using a software management plan.

When you need an SMP

Write an SMP if your software is at least one of:

• used by someone other than the original author;
• producing research results, figures, models, or publications that will be reported;
• expected to outlive the current student, postdoc, or grant;
• shared outside the immediate team;
• subject to funder, journal, institutional, or regulatory expectations.

You probably don't need one for one-line scripts, throwaway exploratory notebooks, or personal utilities you will never share. A practical test: if a future colleague would reasonably need instructions to understand, rerun, or maintain it, an SMP is warranted.

That test tells you whether to write an SMP — not whether the SMP is worth your attention. The questions it asks are simply good research software management practice: who maintains this, how is it licensed, where does it live, how would someone else rerun it. They are worth answering for any project, even one that never gets a plan of its own. Today's throwaway script is also tomorrow's shared tool more often than anyone expects, and the projects that age well are usually the ones whose authors had thought about these questions early.

SMP resources