Cleaning up OpenMRS repositories

Continuing the discussion from Our process for repository management depends on you!:

I’d like to take advantage of the fact that someone (@darius) agrees that we should strive to have less under the OpenMRS organization in GitHub.

  • We currently have nearly 200 repos under OpenMRS.
  • Almost half haven’t been updated in a year (25 haven’t been touched in >2 years)
  • ~50 repos have only 1 or 2 contributors and have only a couple forks

Our current culture of “repos need to go under OpenMRS or they aren’t really OpenMRS repos” has a few problems:

  • It creates unnecessary bureaucracy. If Jane wants to create an awesome OpenMRS module, she shouldn’t need the community’s permission to host an “official” version wherever she pleases.
  • It doesn’t scale.
  • Over time, the OpenMRS organization has more archived repos than active ones.

The one benefit of putting nearly all repos under OpenMRS is for searching; however, you can usually get the same (or better) results by doing a global search of GitHub with the term “openmrs” (e.g., search GitHub for opemrs core).

Proposal

  • We create an “openmrs-archive” organization and move inactive repos into it. We don’t need long debates on what should go into the archive. Any repo that is active or someone wants to reactivate can easily be migrated back.

  • We adopt a culture of having people host “official” versions of OpenMRS repos under their own account by default – i.e., having the “official” fork for a module under an individual’s account would not be surprising to anyone.

  • Repos are hosted under the OpenMRS organization are:

  • Active

  • Need to be writable by the community (e.g., enough people are collaborating on the repo that it’s a pain for an individual to manage permissions)

Thoughts?

2 Likes

I agree with the idea of moving some/many things out of the openmrs github org, and setting the expectation that it’s fine and normal for modules (including commonly-used ones) to have their repo outside the openmrs org.

I’m not sure how I feel about the specific proposal, and I think we should have some more concrete guidelines about what belongs under /openmrs, and and see how this applies to particular examples.

For example, we might say that all bundled modules (in the Platform or Reference Application) should live under /openmrs. If we don’t say that, would you be suggesting that xforms should live under /dkayiwa and reporting should live under /mseaton?

My initial reaction is that I don’t like active as the primary driver, but rather I’d want having a module under /openmrs imply some level of (community) support. I said on the other thread:

Rather than “openmrs-archive” I would suggest something more like “openmrs-universe” (inspired by Ubuntu).

I agree with Darius and don’t think activity is the best measure.

The problem with personal repos is that it implies a single person is the primary one owning/supporting a given module. Putting something under OpenMRS is a way to communicate an intentionality that a module is being written and maintained as a community asset, and granting the community some amount of oversight and decision-making authority as needed.

The approach we generally take at PIH is:

  • Put something under OpenMRS if it is general purpose and of value to the community beyond a PIH implementation
  • Put something under PIH if it is designed with our PIH team as the target audience or it is for specific PIH project(s) or implementation(s)
  • Put something under your personal repository if something is … personal … or a spike or very specific, short-term tool

I’m not really sure what value there is in moving from openmrs to openmrs-universe (I don’t like “archive”).

Mike

Makes sense. By “active” I didn’t mean just actively developed, but also actively used (i.e., a stable module not requiring active changes but still distributed and used widely would be “active” in my book). So, I think we agree here.

I like that too.

The problem is one of scale. When every developer expects their general purpose solution to be under github.com/openmrs, then we end up with hundreds as we have now (eventually thousands) of repos, many of which are not being used or maintained. The proposal is to distinguish between those repos that are meant to be shared with the community and those that are actually being used & supported by the community. For PIH, this would have little effect, since most of the contributions are widely used and community supported, but if a repo (like simplelabentry, if it was no longer being actively developed, distributed, and use in the community was waning) might be migrated to github.com/openmrs-universe.

Which of the 174 repos in github.com/openmrs is the community supporting? For example, openmrs-module-rest and dozens of other historic repos may be causing more confusion than adding value under github.com/openmrs.

1 Like

Thanks @burke, I’m not opposed. But we should consider whether github segregation is the right solution to that problem, or if this is just a symptom of the continued sad lack of an OpenMRS “app store” or other online forum in which module activity, support, reviews, and commentary is available. I’d love to see this prioritized and see where that leads us.

Ya I am agreed with burke But We can not select any repo based on last activity.

My community management perspective:

Centralized organizations are good for our most active collectively-developed projects, but are of limited to no value otherwise. GitHub was created to democratize FOSS development, and part of that system is allowing maintainers to host unlimited public repositories themselves on a single site where work could be easily discovered. (Indeed, this is why we standardized on the “openmrs-module-xyz” etc. naming scheme to make OpenMRS repositories quickly findable through search.) Even in its primitive form, our modules directory at https://modules.openmrs.org/ allows a URL to link people to a repo, README, or otherwise direct them to where to find the code.

My opinion: We must become more focused on naming individuals as chief maintainers of projects. If we don’t, we will continue to be stuck in the “if everyone’s responsible for making decisions, no one’s responsible for making decisions” that has held us back for years. When an individual is ready to step down, the repo can be transferred to a new maintainer.

So, in other words, I fully support Burke’s plan. :slightly_smiling: (Although please remember a second OpenMRS “Archive” organization means a second set of management configuration, groups to manage, etc.)

1 Like