For over a dozen years of participating in GSoC, we’ve reached out the community to drum up a collection of interesting projects. I’d like to propose a slightly different approach this year. What if, instead of taking whatever ideas come to mind, we created a coordinate set of projects that together could be a substantial gift to the OpenMRS Community?
I’ve been working on a draft for Modernizing Administration functions for OpenMRS. In short, this is building a new, modern version of our administration functions. It’s not a small undertaking and would likely require at least half a dozen or more GSoC projects. Here are some of my motivations:
- We need pragmatic ways to begin migrating countries, organizations, implementations away from using server-side rendering (JSPs and GSPs) in new development and build capacity & excitement in the way web applications are built today (client-side applications against REST APIs – most often FHIR – in medical applications). It’s 2021.
- Nearly every distribution and implementation of OpenMRS in the world today is still using the JSP-based administration functions that were introduced over 15 years ago (commonly via the Legacy UI module).
- The work on a new frontend framework within the Micro Frontend squad is reaching critical mass where there’s enough framework & conventions in place against which new features can be built.
- We could produce an “Admin 3.0” module to serve up these Micro Frontend-based administration functions that could effectively be a drop-in replacement for the Legacy UI module. If we pulled it off, many implementations would choose Admin 3.0 over Legacy UI because it looks & works better and be using Micro Frontends without even realizing it.
- One of our first project proposal for GSoC 2021 is itself administration functions (FHIR metadata administration)
- Several of our admin features do not (yet) expose a REST API, so there would, in many cases, need to be some Java-based work to add these features. We could divide projects up by functions and have students responsible for both backend & frontend development OR we could have some projects responsible for filling in gaps in the backend (mostly Java work) and other projects focused on frontend (mostly React & TypeScript work) OR we could mix & match based on student’s interests & skills.
- We would need to develop an extensible admin screen as the parent for administration functions with the extension point(s) and conventions necessary to make it easy for projects to add new administration features (precedent for this already exists in the existing Micro Frontends work). Ideally, we’d have this in place before GSoC begins, so students would be plugging new admin functions into it.
- While a 100% “complete” Admin 3.0 module (i.e., at least capable of replacing the Legacy UI module) would be dependent on the success of all projects, the modular approach of admin functions would allow us to deliver any percentage of the admin functions and be well on our way (even if we have to finish up some functions post-GSoC to get it completed).
- One of my least favorite aspects of recent years of GSoC has been the relative lack of interaction between students and reduced exposure to the community. A coordinated project like this would promote lots of knowledge sharing & teaching amongst students and provide plenty (even weekly) opportunities for community showcases.
We’d need to get buy-in from the Micro Frontends Squad. This would certainly draw a lot of attention of incoming GSoC candidates to want to help out with Micro Frontend tickets (both a curse & a blessing… but likely more of the latter).
We’d also want to get input from implementations & organizations on the relative priority/value of the various administration functions. For example, how many people are using Forms Management or HL7 management? If they only routinely use 3-4 functions from the “Advanced Administration” screens, which are they?
Thoughts? Is this madness or a bad idea? Or do you think we could pull it off?
Cheers,
-Burke 