@r0bby, I completely agree with you, but maybe that wasn’t clear, so let me be more explicit:
If we shift to hosting our modules externally (e.g. via bintray) then the current Modulus UI has very limited functionality that we’d want to preserve (basically, searching for in a simple UI). Also, the current codebase is not getting sufficient community maintenance.
Therefore, I suggest we should be dropping both modulus and modulus-ui, and instead starting from scratch with a new app that is lightweight and easier to maintain going forwards.
True, but I think this is a secondary cause and not the root cause of modulus not being maintained. The real issue is that it’s very hard to set up a modulus dev environment, so I personally stopped asking people to contribute to modulus until this was addressed.
The new application (at least as I’m envisioning it) will not suffer from this problem because (a) it should be a standard npm app, and (b) it will not depend on OpenMRS ID. And that will make all the difference to getting community support.
(I envision that the new application is a read-only index of omods and OWAs that may be hosted in various bintray accounts, or perhaps other places too. But you would actually upload, rate, comment, etc, via bintray directly. Hence no OpenMRS ID.)