I agree with the sentiments here that (a) building our own solution has not worked out for us, and (b) at a glance bintray looks like it has all the features we need.
(As a vote of confidence for that platform, Bahmni is using bintray to distribute its RPMs: https://bintray.com/bahmni.)
Two lessons that we all should learn from the module repository experience:
- If OpenMRS chooses to write its own code outside of the core MRS/EMR/EHR space, it’s imperative that the dev environment is trivial for someone new to set up, and that the deployment process is automated so that someone new can take it on.
- I know the module repo team actually spent a lot of time on making a dev environment available, but sadly the technology they were using disappeared. The sub-lesson is: if it can’t have a README based on solely industry-standard commands (docker, vagrant, git, mvn, gradle, npm, …), then we shouldn’t do it.
- If we think custom development is worthwhile, prefer a model where we outsource the bulk of the work to someone else’s hosted back-end that provides a REST API, and only write the OpenMRS-specific front end ourselves. For example, hypothetically:
- modules.openmrs.org could be a dashboard that shows highlighted and popular modules and OWAs, but then just passes you on to bintray for everything else
- have a custom “compatibility with my OpenMRS installation checker”
- have a custom “upload omod file” page that automates putting a file in the right place in bintray