- Title: Getting ready for the next 10 years (Openmrs 3.x)
- Project Idea/Benefits to the OpenMRS Community: Openmrs has been around for quite some time and has successfully enabled various groups to build solutions that support healthcare delivery around the world. openmrs-core is the foundation for those efforts, institutions/countries/communities/developers depend on it to build their custom EMR or other solutions. However, not enough time is spent on removing technical debt, upgrading outdated dependencies which not only pose potential security risks but it also leads to slower development and a higher barrier to entry for new members. Developers sometimes need to take care of things new libraries, technologies have already solved (for ex. Spring Data for the data access layer to DBs or other backends). We are currently on Java 8 but Java 10 is already out. Upgrading to Java 9 is not easily possible since outdated dependencies are holding us back. Spring 5.x, Hibernate 5.x are out. We are testing using Junit 4, Junit 5 is already out. Our mocking frameworks are out of date. Our logging library has long seen its end-of-life but its hard to update since its so entangled. Still 40% of our code is not tested. We mostly rely on integration tests which makes our build times rather long. We should adapt our testing strategy and promote more unit tests. The list goes on… Its not a hot topic but it has to be done otherwise the future will not look so bright for openmrs-core and thus for everyone building on top of it. I strongly urge we create a dedicated task force that establishes an actionable plan to tackle those issues. Everyone will benefit.
- Potential risks: I personally only see risks in ignoring this topic. The longer we wait the harder it will be.
- High level project plan/Estimated budget: I am happy to work on a more formal project proposal with other interested contributors.
Looking forward to hearing about the next steps needed to create a formal proposal and also to the communities thoughts on this 