A "Retirement Roadmap": Are there things should we consider end-of-life-ing?

Development
1

Just a food-for-thought post…

Today I learned about this concept of a “Reverse Roadmap” or rather a “Retirement/End-of-Life Raodmap” from this article: Delete to Accelerate: Transforming Your Product with a Reverse Roadmap | by John Utz | Oct, 2024 | Product Coalition

I was especially struck by these examples:

Adobe: Maintains a separate “retirement roadmap” that outlines its plans for discontinuing older software versions and services with clear end-of-life dates and migration options. Their hope? Better customer communication.

Atlassian: Has an “end of life” roadmap that covers plans for retiring older versions of their products such as JIRA server. This roadmap details when features will be sunset and when support, bug fixes, and security updates will end. Their hope? You plan to migrate to new, cloud-based offerings.

Salesforce: Provides “Salesforce Retirement” roadmaps that detail its plans for retiring legacy user interfaces. The Salesforce Classic Retirement roadmap, completed as far as I know, provided users with timelines and guidance to transition to the newer user experiences available. Their hope? A smooth transition from legacy to new user interfaces.

I’m curious: Do people think there are any particular things in OpenMRS (code or otherwise) which we should consider putting on a “Retirement Roadmap”?

We’ve actually done this several times in the last 2 years - two examples that come to mind:

  1. The initiative to vastly simplify the RefApp (EMR Distro) modules list - it used to be 44+ OMODs with each 2.x RefApp release, creating all kinds of dependency nightmares for implementers and maintainers. For a time we got this down to 11 OMODs; we are now at 29.
  2. The OCL-for-OpenMRS webapp - instead of maintaining a separate React frontend connected to the OCL TermBrowser, we switched our focus to using the OCL TermBrowser directly.
  3. The biggest one of all: The 2.x RefApp / O2 itself. We’re getting there, but I think we could be more clear, for example, about when exactly we plan to stop testing Platform releases against both O2 and O3. We have a general policy of backwards support for 2 major versions back, so given we are expecting the 3.2.0 release in the next few weeks, we’re almost at that magical line… What do you think @dkayiwa?
2

Our recent testing of the platform against O2 has not been a means of ensuring that we maintain support for it, but rather taking advantage of the modules in O2 to help test and catch any bugs that we may have introduced in the platform.

2 Likes