We are moving towards the AddOns, and all modules and OWAs are hosted at there to serve as the OpenMRS AddOns store. When I used it recently, I was able to notice that we are showing some taga like “DEPRECATED” and “INACTIVE”.
In this way, Why don’t we introduce a tag as " OpenMRS Verified Addon"?
The reasons for this idea are,
Custom add-ons may use some other third party dependencies which could have some serious vulnerabilities. So it may lead to some issues for the implementers.
All of the OpenMRS implementers trust the AddOns Manager and download the various add-ons to extend their platform. So if we allow them to break their systems by installing a module from AddOns will down the impact on us. So indicating the user about the verification will help them to search more about that module before installing.
Some modules in the AddOns caused the installation failures and other dependency problems which lead to immediate system down while installing the modules. So the user may need to manually remove that module from the directory and restart the system. Sometimes I also faced this issue and removed that module manually from the server module’s directory
Most of the app stores follow this way to improve their user experiences (See play store, windows store and IOS App Store for their module verification). So it is a common aspect of the app stores around the world.
Some module implemented by the developers which addressed only some use cases, and it failed to address some other most wanted use cases. So when other implementers try to use those modules faced some problems to overcome from those bugs.
And there can be a lot of reasons which can support this idea
If we wish to introduce this into OpenMRS AddOns, then we can introduce a method to get the OpenMRS Verifications for the add-ons. Simple Idea to make this would be,
The developer should request the OpenMRS to get the verification for the custom modules
Module should be worked without any faults and should be tested by two or three other developers inside the OpenMRS
Documentation about the module should be created inside the OpenMRS Wiki
It shouldn’t contain any vulnerabilities or broken dependencies.
The module development should follow the OpenMRS standards.
Developers should update the OpenMRS verification during the major OpenMRS platform changes (1.x to 2.x)
Any ideas or comments on this will help to make the AddOns more powerful
The advantages of having such a tag are many as mentioned by you.
Having said that, here is my qualm regarding the same:
Every module developer would like to get their module OpenMRS verified. To ensure the quality of the modules tested, we will have to test every aspect of the module from the quality of the code to its conformity with the OpenMRS standards. This, in my opinion, would be a slow process and we would probably need to have a few devs who will be looking into this.
Module verification is a continuous process i.e. suppose we have a module A whose v1.0 runs well with Ref App 2.6. The suppose, Ref App 2.8 is released and the development of Module A has stopped and no longer works with this new release. The right thing to do in such a case would be to remove the OpenMRS verified tag. However, we currently have about 300 modules on AddOns and this list is growing each day. Won’t it be extremely tedious to keep a track of what happens to each module individually?
Having said that, my solution to the abovementioned would be to either:
Only add such a tag or a (Ref app module) tag to the ones released as part of a particular ref app release.
or
We can possibly follow the approach taken by the popular app stores and review the modules with the highest number of downloads each quarter/month.
If you have any further solutions/points to the points mentioned above, do let me know
@suthagar23 I like the suggestion in theory, but in practice, like @reubenv says, this isn’t feasible to do since it would require a substantial effort to actually have people review and test modules. Further “OpenMRS Verified” implies a strong quality guarantee, so we’d need an even higher level of review.
Now we could definitely introduce other tags that give this same kind of info to the consumer, like maybe “Community Supported”, “supports Platform 2.x”, or “Tested on RefApp 2.7.0”. Someone still has to do the testing and add these tags, but that seems more feasible.
Another thing that we could automate is to show some indication of “freshness”, e.g. put a green/yellow/red based on things like if there has been a release in the last year, or if there’s any recent github activity.
Just to second the above, I agree that these metrics would be helpful but having an “OpenMRS Verified” flag has complexity.
What really makes something verified to me is if actual implementations run these modules in a production environment within a particular implementation/distribution, and on what version of that platform. I think it would be more straightforward to say that “PIH” endorses a particular module (because they run it in their Haiti, LIberia, and Malawi implementations), or that “Bahmni” endorses a particular module because it is part of the Bahmni distro.
Ideally we’d be able to get real usage data from Atlas, but sadly I don’t think it’s used very consistently.
This sounds like a nice approach, and it would fit well with the design approach of Add-On Index (i.e. that we index things published elsewhere).
If PIH published a file in the distro.properties format (e.g. just by having it on github or somewhere else on the web), we could have an entry in Add-On Index’s config like
So it would be good to leverage the SDK functionality for the distro to get the latest configured modules for a distribution which would change to using UgandaEMR as an example:
Which also gets me wondering, all this information is actually in or can be included in the openmrs-distro.properties file, shouldn’t it just be sufficient to just read all the info from that file
I was thinking that it would be the responsibility of PIH and UgandaEMR to publish a distro.properties file including the real version numbers. (Not that the Addons server should be fetching things from maven and/or doing sdk builds.)
But let’s take a step back from solutioning. There are several workable ideas on this thread:
Have editors (of some sort) in the OpenMRS community review some of the most popular modules. (Just a few, so it’s not too much work.)
Have a green/yellow/red light and/or badges that indicate freshness and/or existence of security issues from Snyk or similar
Implementations can publish what modules they’re using. We display the number of implementations using a particular module (in search results) and the list of those implementations (on the show module screen).
Do people (users?) have thoughts about what it makes sense to pursue?
OpenMRS Verified Addon"?
