I am tagging all the “historic” members of the OpenMRS community and new leadership to raise publicly a fear that I have been talking about in the last 18 months but to which there is no public commitment to addressing.
I have been part of the community for the last 4 years, and there has been no “core technical development” efforts happening in OpenMRS, to move the platform and RefApp forward at least for the last 18 months
This has been due to an exodus of “core devs” paid & focusing to work on moving the platform forward, and currently these efforts have been left to implementations to fund and try out on their own. GSoC, GCI etc can only take the changes so far, there is no “heavy lifting” as existed before.
This model has not been proven to work in any open source community, and while unseen to the leadership, there is “atrophy” in the platform, and everything is hard to use or to extend, with no support, my personal experiences:
Sync 2.0 (does not work in the field) - we had a generally failed sprint despite the valiant efforts of the new members of the community who did not have technical support & backup
FHIR: cannot be used for even simple use-cases - I have asked in the Slack channel with no responses
Webservices REST still a pain to extend and add custom end-points
Reporting: still a pain to use and not simplified in the least
Speaking from the UgandaEMR implementation where we are working feverishly to meet our ambitious goals, there is little “core” support to help us get over the line
My call to you the leadership, is to act now, act soon solve the technical challenges save the platform, otherwise the gains over the last couple of years will be lost as implementors start to look for and will find alternatives.
Stephen, just wanted to let you know that I saw and read your email! I am not sure the best way to respond as I know that there are a lot of exciting things happening within the community… but it sounds like there are some core functionalities that you or UgandaEMR would like to see addressed that aren’t being addressed. Perhaps this is something which can be addressed through discussion on the S&O call this week?
@ssmusoke, I’m glad that you’re keeping this front and center.
As I reflect on those specific issues you mention, it occurs to me that this goes beyond engaging core developers. It’s also about tapping into and coordinating a variety of resources - and doing this in a way that complements work being done by others in the community. For some projects, this may mean finding an additional dev or harvesting work done by another implementation. For other projects like Sync 2.0, it could be finding a product owner or a tester. In some cases, like OCL for OpenMRS, it may very well be a combination of these.
The Product Change Committee and the Technical Action Committee are a couple of the exciting things happening in the community that @akanter mentioned. These two groups play key roles in defining our approach and priorities for our technical products. In turn, their work can inform discussions and decisions on SO meetings about resources. Knowing what our priorities are and what resources they need is a starting place.
As @akanter says and from your previous post about the Ref App, it’s clear that there are some key things that you would like to see. Does the Product Change Committee know what specific features you are looking for next? If you’re unsure, chime in on their Talk thread or join them during their weekly Wednesday meeting. And I hope you’ll actively bring your technical recommendations to the Technical Acton Committee’s discussions in the coming weeks.
And I know you and @dkayiwa have been busy at the UgandaEMR hackathon, however, have you had a chance to check out what the new FHIR Squad is up to? Feel free to join them as they discuss what is next for the FHIR module.
OpenMRS is at the crossroads of amazing opportunity, but the real secret to success in this transition is finding a way to support the OpenMRS public good in sustainable ways.
There are many countries transitioning to OpenMRS for national level implementations, and as a result, there are considerable resources being spent on OpenMRS implementations by philanthropies. However, there has been insufficient understanding by those same philanthropies as to how best support the underpinning/core of that work.
The good news is: they are starting to become more aware of what it’ll take. We’ve been working hard to have them consider new working models that match implementation growth around the world with increased support for the core.
There are new people coming into “the core”, and hopefully implementations soon will be resourced and expected by philanthropies to work in the OpenMRS community in ways that strengthen the center.
Are you familiar with the tragedy of the commons?
This is what we’re working to resolve at the moment.
Give that some thought in your role as a leader of a large-scale implementation, and thanks in advance for your support while we work through this important transition.
Doesn’t Ubuntu mean: I am who I am because of who we all are?
I had been meaning to respond to this but hadn’t gotten a chance, but I joined the TAC call today, and it reminded me that I needed to.
I think this is key… for a long time, we generally had about 3 developers funded to work on OpenMRS, but for at least the past year it’s been down to 1.
On the Technical Action Committee call today (and as a side note I want to thank @jennifer for pulling this and the Product Change Committee together) I talked a little about a chicken-and-egg problem: a roadmap/plan is critical to guiding those who want to contribute, and also as a vision for fundraising, but with progress being so slow over the past few years we feel less motivated to take part in these committees (ie “is this really going to lead anywhere?”).
IMO, it’s key to have a core, dedicated technical team to work on the product. And I think you’d have stronger participation on committees if there was a belief that there was a team dedicated to actioning proposals from the committees.
That being said, it’s worth noting that “OpenMRS” has never hired core devs. We are OpenMRS, and we were fortunate to have developers from a particular organization that were pretty much tasked to work on OpenMRS full-time (or at least that is my understanding, I’m not sure of the details).
An argument could be made that the organizations who benefit most from OpenMRS should pick up the slack and provide resources that could be seconded full-time to OpenMRS. But, realistically, this hasn’t happened over the years (beyond the aforementioned developers) and I don’t see that changing in the future. (For my organization in particular, we have a dev working part-time on the microfrontends project, but I don’t see us having the bandwidth to commit more than that currently).
Understanding this, we’ve lobbied hard in the past that “OpenMRS” should recruit and hire a (small) core development team. If nothing else, I would love OpenMRS to have a strong technical architect who could spend their time forced solely on OpenMRS big picture issues without the distractions of day-to-day implementation challenges that seem to drain our time so often.
But this has never happened, and I think there are a few reasons for this:
The issue with non-profits being unable to take part in software development without losing their non-profit status
Lack of funds
No one taking the lead on recruiting and hiring
Pushing back on hiring developers because of the believe that OpenMRS should stay “lean”
I would definitely be interested in talking further about how we could overcome some of these hurdles… (I haven’t been on many calls of late, so apologies if there are developments in these areas that I’m not aware of).
Also, for anybody who hasn’t read it, I suggest this thread which basically discusses these same issues:
Thanks @mogoodrich for taking the time to respond as one in the midst of multiple implementations. There are lots of committees, road maps, plans etc, but no actual work being done, while plans are great, non-executed plans well are no-good to anyone and are just a drain on everyone.
With all due respect, @ssmusoke… in order for the commons to work, those who benefit from it’s efforts must reciprocate back… or else we collectively deplete the public good:
That being said, I know you specifically are not well positioned to fix that problem, but as I meet here in Ethiopia with the Ugandan MOH and CDC Uganda, I can take this up with them.
In the meantime, it’d be helpful as a leader of OpenMRS if you could work alongside us to help those around you understand what it takes to sustain a global public good.
Thanks, @mogoodrich, for adding some great context to this issue. I know from my own experience as an implementer that funding has become increasingly constrained over the past several years. This certainly makes it difficult to meet deliverables as they are, let alone dedicate developer time to community priorities as compared to the past.
Seems like one of the key questions we’re grappling with is: How do we set ourselves up to do the actual work and build out what is on our roadmap so that it is more of a shared endeavor? As we make improvements to how we actually get the work on community/core priorities done, we can do at least some joint planning and prioritizing to point us in the right direction.
So I’m looking to committees and plans to provide the vision and technical direction that some are asking for outright - not to get the actual work done.
Right now, the actual work is happening in one of three spaces: in implementations, by squads, or by individual contributors picking up tickets and working on sprints. Having small development groups or squads working on core, shared priorities worked for us in the past and is happening now. There are improvements that we probably want to make so they are more flexible and can work quickly. If we want to make sure we share the lift, then it’s a question of working together to be more intentional about who is on the squad. So I’m interested in how we form, set up, and support squads to do community/core work successfully.
@mogoodrich, what do you think about having a pool of community BAs, developers, testers, PMs, etc who become part of different squads rather than a dedicated “core” development team? I ask as I’ve also seen instances where a single, siloed team takes on a community priority - and then it’s taken much more time than everyone likes and then needs additional work in order for the module to really be useful to multiple implementations. What sort flexibility can this give us (and squads)?
@paul for reciprocity to happen there must be a move by the core which in this case is OpenMRS Inc to move the critical pieces forward which the implementors cannot.
In my native tongue there is a proverb that says an “elephant cannot fail to carry its own tasks”, so in this case OpenMRS Inc, has the fiduciary duty and responsibility to carry the core forward which has not happened over the last 18 months.
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
It is disappointing that you are looking at implementors as “free riders” on the common good yet they drive the direction the platform is going, maybe this link would be good reading to alter your perspective Open source beyond the market - Signal v. Noise
Learning a lot from all your submissions. So keep them flowing.
Am doing some research on this, by exploring the various options being suggested. It is basing on this background that i would like to ask @mksd, who is the lead of @MekomSolutions. What has enabled your organisation to become the current top most contributor to the OpenMRS core platform? Do you just have a big budget? Is it a difference in mindset? Or is it something else? Contributing Organisation of the season - Mekom Solutions!
First remember that @MekomSolutions’s work spans across OpenMRS and Bahmni. So there is a number of things that we do that people on this thread do not even see because they look only at OpenMRS which is a mistake IMO. I personally hate the distinction OpenMRS vs Bahmni, it doesn’t make any sense to us. Bahmni is a distribution of OpenMRS, full stop, work on Bahmni benefits OpenMRS directly.
By the way the Bahmni Coalition suffers from the exact same issues: what’s the roadmap? who supports the core product? … etc etc. Cc @pradiptakundu@angshuonline
We come across as a successful and productive contributor OpenMRS/Bahmni for a couple of reasons:
Our top management is made of tech guys. What speaks to us is to advance the tech, the rest flies over our heads.
All our team members are OpenMRS lovers and contributors. This is a huge additional constraint on our capacity to grow staff.
We sell our products and services under the constraint that the work done must be community-friendly and community-compliant. Another huge constraint, some clients/projects do not want to hear of this, it flies over their heads… and a couple of OpenMRS/Bahmni paid-for service providers out there do not care about this at all which is the worst thing that can happen to the community. The biggest disservice to all our goals really.
So @dkayiwa to answer your question, if you combine the above points with the access to appropriate funding, then you get the winning cocktail IMHO. But that’s a lot of factors to come into play.
I think that would be great, but I still think there needs to be a core (albeit potentially small) development team including a strong technical architect to guide that work.
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.
That being said, I’d emphasize again that we are OpenMRS. So I’d not say that “OpenMRS Inc.” needs to find a way to build out that core team, but can we build a core development team that can work on OpenMRS and be protected from the diversions of specific immediate implementation needs and emergencies. In the for-profit world, of course, we’d be paying a company for the software and those funds would be used to hire developer… in our model, can we furnish donations from member organizations, or get truly seconded resources?
It’s tough… and the free model hurts us in that extent. I know at my organization we are constantly pushing the amount we can do with the limited funds we have, and so if there’s a “donation” we don’t have to make, it will likely be cut when it’s that versus hard goods or resources that need to be purchased. But maybe that’s a failure of my team to promote and lobby hard enough within our organization.
Could we come up with recommended donations? ie, if you are serving x numbers of patients, we recommend your organization donate y amount per year to OpenMRS? Maybe a pipe dream (and I assume that we’d be running into the open-source/non-profit status/hiring programmers issue, but hopefully we could work that out), but worth considering. It’s frustrating to me when I think about the amount our organization pays yearly for a commercial PACS system that has an impact that is much smaller than OpenMRS.
Also, from what @paul says it sounds like we are approaching this from the angle of the philanthropies funding our organizations, which makes sense to me:
I’d also be interested in feedback from @joeldenning based on this quote from another post:
I think the OpenMRS community is unusual / distinctive when compared with other open source communities for the following reasons:
There is no core team of developers working on OpenMRS. Which is highly unusual for a project with such longevity and # of users.
Open source software projects usually have a much more clearly defined scope. “Vue is a UI framework,” “webpack is a bundler”, “Python is a programming language.” But the size and scope of OpenMRS is very much up for interpretation. You can fill in the blank with a lot of answers: “OpenMRS is a _____”
Open source projects usually provide tools for developers, not features for end-users. A reason for this is that no single end-user feature can satisfy all groups using the open source project.
I assume the way core developers are funded on other project
My guess is that other open source projects are able to have a team of core developers is because:
The are used by for-profit companies with deep pockets who are able to contribute a lot more
As these are generally tools for developers, not end users, it’s easier for developers to contribute as part of their day-to-day jobs (and therefore easier for organizations to second resources and see the immediate benefit) and it’s easier to coalesce around a shared feature-set
… but Joel if you have any other insights I’d love to hear them.
Friend: WE are the core. OpenMRS Inc. is a recently developed organization as compared to the OpenMRS community. It wasn’t created to just take over the development responsibilities of OpenMRS. It was created to sustain the ongoing work of the community.
All I am trying to say (and I think it’s better to have this conversation face-to-face over drinks/beers), is that we need to support core development in a way that relates the beneficiaries in some way with the support responsibility. Whether that’s our collective approach of philanthropies or coming up with a pooled engineering support model of the core (which is what we’ve historically done). I honestly am beginning to wonder if people don’t understand the history that got us here.
We can’t just expect “everyone else” to worry about making the core product robust.
@ssmusoke, you are a friend and an ally. Please don’t misunderstand my pointer to the “free rider phenomenon” as anything other than an attempt to explain my point.
Hi friend, this is another way of making my core point:
None of us has the full responsibility for moving OpenMRS forward, but on the other hand… all of us have that responsibility. We are a community, and will only go as far as our efforts will allow. We collectively “own” OpenMRS, and we collectively have to grow OpenMRS.
You are describing “free riders” above, which is not a disparaging name, it’s a well-described economic phenomenon.
Looking forward to seeing you all in Mozambique, hopefully.
100% agree. I don’t think anyone disagrees on goals… I think some of us might disagree on how we get there.
That’s right. Most of the money that’s spent within the OpenMRS community is within implementations of OpenMRS. All I am suggesting is that we figure out a way to align those considerable resources in such a way that contributes to the core in the process. We can’t just spend ~100% of those resources on implementation alone. That perpetuates the tragedy of the commons.
Our organization (Regenstrief) worked to support the inaugural core development team for OpenMRS because we benefitted from it within our AMPATH implementation. I suspect you’ll hear more from @jdick on this front at the Mozambique meeting
But I’m trying to be provocative here for a reason: we have to collectively own the responsibility of this going forward… it’s not just up to Regenstrief or PIH, especially given the vast majority of implementations today have nothing to do with either organization.
Have the issues with the FHIR Sync module been documented anywhere? I know that there was a successful demonstration of using this to interface with DHIS2, and though I have heard that there were problems, I have not seen yet seen anything specific to address. Any information in this regard would be much appreciated as then we can work to address them. Thanks in advance.
Tangent: my current org in my day job works in a way that has some relevance to OpenMRS. (Obviously some things are very different.)
(First caveat, this is working on an application one level up from an open source platform.)
We combine loose coupling of implementation with strong coordinating around vision/direction.
There are multiple teams working on different deliverables at any given time. There is no “core” team: each team builds and delivers its part of the application. Teams are allowed to diverge a lot in the short term to meet delivery goals (much more so than I would have expected).
There is a strong central Product Manager function which works across teams (and of course we’re a company so there is a manager above all this who ultimately approves plans).
But I want to highlight the PM piece. Ultimately a small number of people provide authoritative statements of staged customer requirements for all teams. (E.g. “it’s okay for this beta release to support only this one network topology”) PM doesn’t specify any architecture/engineering, that’s up to the individual teams.
We tried to include a very similar function in the Bahmni Product Architecture Team: it could basically give pre-approval to an implementation that “if you build your feature satisfying XYZ high level requirements (which were focused on generalizability), then you can merge it to the core product”. (I don’t know how this is actually working in practice today.)
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
I hope this reflects the way the micro front ends squad is working these days.
It’s always going to be extremely hard to resource the universe of things that OpenMRS encompasses.
It would be great to have a core team explicitly working on shared pieces, and at times OpenMRS has had that (donated by a specific org). And hopefully funders come around on this someday.
But another way is to consolidate around a much smaller number of front end applications, to focus a limited amount of funding on a smaller surface area. And then to organize such that independently funded teams do end to end feature development within an application, reaching down to the core platform.
When I was last paying close attention, I thought that Bahmni was the right vehicle for this. Whatever it turns out to be, I would suggest that it’s in almost every org’s medium term self interest to make pretty big sacrifices to get down to just one application.
Thanks, Darius, your experience and thoughts are much welcome!
I wondered about the tension between the flexibility to meet short term needs and the overall architecture/platform question. It would seem that also having a strong architect to act as a resource for the application teams during design time would go a long way to improving the likelihood of a successful reintegration. Do you have that?
Andy
P.S. Miss your presence terribly with the OpenMRS and OCL work
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).
(Something that’s different for me is when someone takes a short term hack and commits to fixing it on the long run, it does have a high likelihood of actually being fixed vs in OpenMRS, due to higher overall resourcing.)
You want that role to be a problem solver for teams, versus a gatekeeper.
