What is the OpenMRS Plan for Core Development

[jennifer (Jennifer Antilla)]

@ssmusoke

An implementor can contribute back only the parts they are interested in but there has to be a party that looks over and above the “implementor” & community needs seeing the forest rather than the individual trees

@mogoodrich

We need a team of people to see the forest from the trees, a team whose core focus day-to-day is how to make OpenMRS work better across implementations . These people can then work together with implementations to guide/harvest their development work. I think over the years we’ve seen that the idea of different organizations collaborating without that centralized guidance, while beneficial, has also lead to a lot of fractured development, etc. The nature of our work environment is one of resource scarcity, and as much as we’d like to collaborate, and do collaborate, I think the day-to-day demands of our organizations make it hard to do so at level required to make a viable, ongoing product .

@darius

In my org there are several high level tech leads that spend more time on big picture design, and do provide guard rails and guidance, kind of like you’re suggesting. It doesn’t have to be a single person (it isn’t for us).

Based on what’s coming out of this conversation, I hear that there’s a clear need for a group/team of people - including a technical architect - to provide the community (including implementations) with technical leadership and guidance.

The Product Change Committee and Technical Action Committee have been talking about doing some of these things as a part of their scope: watching over the platform/ref app/modules, providing technical guidance that will drive the evolution of the platform/endorsing or recommending technologies (like microfrontends, FHIR), identifying what modules can be harvested from implementations, etc. It sounds like they are headed in the right direction.

So then it comes down to having the right people involved - the technical lead/architect as well as technical leads from implementations. The more implementations get involved, the more likely the result will respond to challenges implementations are actually grappling with.

@darius

To summarize, there is a lot of power in:

• multiple teams working around one application
• those teams are loosely coupled, and given a lot of autonomy
• strong Product Management / Management function to grant that autonomy in a trusted way
• prioritize delivery over technical perfection

@darius, I would say that the MF Squad and now the FHIR Squad are moving towards working in this way. You also make a good point about the strong PM function. Within the context of the PCC+TAC and squads, the OpenMRS TPM ends up playing a critical role.