Continuing a conversation I was having over email with @sunbiz and @judywawira…
I support LibreHealth’s desire to set up a an umbrella org with good governance and SOPs for multiple FOSS Health projects. This is a great idea; there’s a ton of work to be done in the Health IT space, and making it easier to start up new good-practice FOSS projects will help a lot.
But I don’t understand why you feel the need to fork the openmrs-core codebase into lh-toolkit to carry out this mission. Rather, it makes a lot more sense to use openmrs-core directly in LibreHealth projects, and to contribute changes to it as needed in the context of those projects.
The Bahmni project (a distribution of OpenMRS, by ThoughtWorks) is an example of how this can work. Bahmni is an independent project, with its own team, its own governance, and its own roadmap. But it uses openmrs-core, and when it requires a new feature or bugfix, the Bahmni dev team makes that change (using its own processes), and submits a pull request. Bahmni has a 6-week release cycle, paying clients, and the technical resources to fork openmrs-core, but it hasn’t seen the need or value in doing so.
I would expect a project like the LH Radiology project to want to follow a similar model: it would organize and govern itself through LH channels; it would also use a piece of MPLv2-licensed OpenMRS code as one of its upstream components, and occasionally contribute changes there.
OpenMRS always welcomes code contributions, and we’ve always worked with people to try to get those merged as efficiently as possible given their timelines and constraints.
If you had run into a situation where an LH project tried to contribute code to openmrs-core, and it got rejected, then forking would obviously makes sense for you. But I don’t understand why you’d want to fork this (widely-used!) codebase without having first tried to make the code changes you’d like to see happen.
Help me understand the reasoning. The obvious downside to forking is that downstream software will generally not be compatible with both OpenMRS and LH Toolkit. This divides the contributions of (too few!) people working in the FOSS Health space, and it leaves resource-limited implementations of one or the other software facing a fragmented ecosystem.
As mentioned in our announcement, we’re building a new lineup of software solutions for healthcare. Our earliest community members have deep experience in the field from their work on the OpenEMR & OpenMRS projects, and we’ll be building upon many things those projects have released under open source licenses over the years. We anticipate both projects will continue to move forward with their own plans, and we’ll also do our best to offer our work back upstream to those projects as bug fixes and other changes, as may be appropriate. We have extended public invitations to those still contributing to both OpenMRS & OpenEMR to collaborate with us on LibreHealth initiatives, and look forward to the opportunity to work alongside them in the future.
This is pretty clear and I don’t think we need to answer further. However (and I do not speak for everyone on the Steering Committee), that fundamentally — we don’t agree with how OpenMRS is being run as a project. That is why I believe we forked. The lack of transparency and accountability has been already publicly addressed and I can freely probably list that as two of the reasons without hesitation, but it’s far from the only one in my opinion.
@sunbiz may have more to say, however I believe that forking and leaving toolkit as it is, is the way to go. As the FAQ said, we will contribute back upstream when approriate.
@djazayeri thanks for your post … after AMIA, i am even more convinced that we made the right decision to fork the code
I can tell you that the next iteration of toolkit will be very different in architecture from Openmrs core and the reason why we will be able to do this is because we don’t have many users – this is a luxury that Openmrs doesn’t have any more because of the wide use
Given out new direction to move the architecture of the project in a new dimension , we wouldn’t have the resources to keep backward compatibility but hope that in future Openmrs and companies like thoughtworks (bhamni) may try to get some of the best practices that we learn from the librehealth projects
I wish to remphasize that we are building a core community and ecosystem – this would be very difficult to keep maintaining two projects especially given how young we are , and I think what we can do is wait and probably review this topic in the future once we have had a chance to get our feet wet with some of the action
Personally the core right now is too over bloated with unnecessary code and has become nearly impossible to work with even in a sub project like radiology
I want to make sure that you’re really considering all the options here, because the path you’re describing means that you do need to “maintain two projects” (i.e. you need to maintain lh-toolkit, and also the radiology system on top of it). But you can build a community and an ecosystem without having to own every code component that you use. As I mentioned, the Bahmni project shows a template for how an independent team and community can have its own identity, roadmap, and processes, without needing to fork openmrs-core.
It’s easy to fork, and hard to unfork.
This does not imply that you need to fork openmrs-core.
If you describe the new architectural approach that you’d like to take, maybe OpenMRS will be perfectly open to it! If not, then do go ahead and fork.
Please share the details of this. If this is the case, it’s feedback that would help OpenMRS improve! (As a side-note, I suspect the bloat you’re thinking of is not in openmrs-core, that I’m specifically talking about.)
But even if so, forking the code does not make it easier to remove bloated unnecessary code. You’re still going to have to refactor, and personally I would want to first try doing this in coordination with more people historically familiar with the code.
I’m sorry if I’m sounding repetitive here, but you may not have to fork openmrs-core.
It costs you nothing to propose the (big, sweeping) changes that you want to make to openmrs-core, and decide whether to fork based on the reaction to this.
Deciding up front that you’ll fork, and you won’t be backwards-compatible, without having first floated the architectural changes to the community you’re forking code from, seems like a mistake to me.
[meta]
@downey, changing the title of the topic without explanation, so that it no longer reflects the point I’m making, does not make me feel like a valued participant whose ideas will be listened to.
“No need to fork openmrs-core” exactly captures the message I’m sending in this thread. You may think I’m wrong, but but “Rationale for starting from an openmrs-core fork” is not clearer.
[/meta]
Editorial freedom has always infringed on author’s freedom. The best way is often to find a middle ground and convince either the editor or author, that an idea is better expressed with choices of words. When you said “No need to fork openmrs-core”, it sounds like a belief statement you made, instead of a topic on which you want discussion. We want to discuss the topic, and so I think the present title conveys a valid question that requires discussion.
Thank you for your support, and I assume it is an acknowledgment that OpenMRS organizationally lacks good governance, SOPs for the wide varied of work that community members are doing.
I’ve said this a few times in our past conversations, but lets discuss the subtleties of this topic. My primary assumption is that humans embed themselves in the technology they create, the choices that they make and the reasons for the choices that they make… @judywawira has said this and let me repeat it - Our users are the last mile clinician and patients. OpenMRS for long (and probably serves it well?) has catered to aid agencies model of development, where implementers deploy an imported technology and users for it are the implementers. Because we cater to a different set of users, we want to build a product that meets their needs. The openmrs-platform wants to cater to its users and similarly Bahmni wants to cater to its users. Thoughtworks and you (and Bahmni developers) seem to believe that your users are a subset of openmrs-platform users. We believe lh-toolkit users lie in a venn-diagram space that overlaps in some parts with users of openmrs-platform (which is why we forked), but there is a large set that lies outside the space that openmrs-platform provides. Do you think we should cram our users to fit into openmrs-platform user space?
With this logic, let me give concrete examples.
Our last mile clinician or patient doesn’t have technical skills to write HTML, CSS and JavaScript. openmrs-platform or reference application’s customizability requires implementers to have those skills to use HTMLFormEntry. There is the xforms module, but HTMLFormEntry gets priority because your user has those skills.
Our users want easy separation of their records from other users, but openmrs-platform developers seem to know that their users do not want this. Hence this features that has been requested multiple times, has not been developed.
I feel the same about 2FA or LDAP and other authentication methods.
Off course, your argument could be that if users really wanted it, they would have built it. Our users want it and so we are building it. You will say that openmrs-platform users want it too and so you should build it for them too. My point is, if there are more features that we are building that openmrs-platform users need, why are they not lh-toolkit users? It seems they are using the wrong product for their needs.
I hope you get the drift… So that brings me to my conclusion. We should all build products (particularly in the FOSS space) that meets user needs. We believe in development as freedom. i.e. development is best achieved when we provide more freedom and remove unfreedoms. If a user, after evaluating their needs, realizes that their needs are better met with another product, it contributes to development. It should be our objective (openmrs, librehealth, openemr or whoever is working in the development space) to provide this freedom. Do you think that we shouldn’t provide this freedom?
OpenMRS focuses specifically on patient medical record systems, but the Health IT domain is larger than this. I support an umbrella org that makes it easier to start FOSS projects in the space more broadly. Sometimes people say “we need something like DHIS2 and OpenMRS, but for XYZ” and I would be happy to point them in the direction of a mechanism that makes starting such a project easier.
@sunbiz, it sounds like we’re talking past each other here, and if you are 100% dead-set on forking the openmrs-core codebase, just say so, and I won’t bother trying to convince you otherwise.
But before replying to specific points, let me try to rephrase on the main idea I’m trying to communicate:
You want to create end-user products like LH Radiology, and these are made up of various components. One of these components is a back-end platform. It’s still consistent with your mission to use openmrs-core (without forking) as one of the underlying components to those products.
You could try using openmrs-core, but then fork based on some real-world event, like a pull request isn’t handled to your liking, or some proposed architectural change is not accepted. But I think that deciding to fork that code before something like this has happened is a mistake.
Note that I am specifically suggesting that you should use openmrs-core, even if you want a different community and ecosystem.
An analogy would be that Red Hat Linux vs Ubuntu Linux have different target users, and the end-user experience of the OS is different, but they don’t maintain incompatible forks of the Linux kernel.
So, to some of your specific points…
I applaud your desire to focus on the last mile clinician and patients. Personally I have a lot of trouble envisioning how to effect change at scale by connecting developers to end-users without working through implementers, ministries of health, etc.
But I am honestly hopeful to see you prove me wrong and succeed at this, and I’m not telling you not to try it. I’m just suggesting that you’re mistaken to decide up front that you must fork the openmrs-core repo to build this product.
Particularly, last-mile clinicians and patients are the users of the applications but they only incidentally use the back-end platform components. I assume the changes you’d want to make to a back-end platform are entirely consistent with changes I would also want to see in openmrs-core.
ThoughtWorks and Bahmni do not believe their users are a subset of openmrs-platform users. Per what I wrote above, I suggest you consider your end-user-facing application and the back-end platform as two different components.
The former is the one your end-users choose to use, the latter is a side-effect.
Bahmni is a hospital system, and it chose to build the application on top of OpenMRS components and some other FOSS systems. Users sometimes come to Bahmni without knowing anything about OpenMRS; if they install Bahmni, they do also get openmrs-core, but they also get Spring, and Hibernate, and this doesn’t make them “users” in a meaningful sense.
LH Radiology or LH EHR could take a similar approach, focusing on the application-level value add to your end users, regardless of having a fork of an underlying component or not.
A large OpenMRS contributor, Partners In Health, chose to focus on HFE, and added key features that they needed to build and deploy their application. This did not remove or compromise any functionality from XForms, or openmrs-core. (And it enhanced the platform by its contributions to Metadata Sharing.)
But, big-picture, XForms and HTML Form Entry are both add-on modules, not part of openmrs-core. Hypothetically if 5 years ago there had been an LH Radiology that used openmrs-core and XForms, the fact that some other contributor focused on HTML Forms instead would have had zero negative impact on LH.
This is unfair. There are many worthwhile features, including these, that languish in a backlog. But this is not because of something nefarious (“openmrs-platform developers seem to know that their users do not want this”), but because of the entirely mundane fact of limited resources, as experienced by every FOSS project ever. If a pull request for any of these features had showed up, it would have gotten merged as a priority!
(You were a core committer to OpenMRS during this whole time; but you had other things that took precedence over these, just like I did, and just like others did.)
Going forwards, if you were building LH Radiology using openmrs-core, and decided that 2FA was a key requirement, you could just send a PR, and it would get merged.
The entire reason that I’m spending so many words here is because forking the back-end platform hurts the end-consumers of the platform. There’s no need for “it” to be built twice. An openmrs-core user wants multi-tenant hosting, or 2fa, just as much as an lh-toolkit user does. And an lh-toolkit user wants care plans and decision-support as much as an openmrs-core user does. So give them a chance to both benefit from all the work going on in the ecosystem, don’t preemptively decide to fork openmrs-core before sharing the big architectural changes you want to see. Judy alluded to these in her post, but I still don’t know what they are.
I accept that you have a set of users in mind who you want to interact with in a different way. And I’m not trying to dissuade you from building a different product, in a different community.
I’m saying just one things (repetitively, I know): try building that product using openmrs-core (not a fork); then fork if you see a practical need to. Don’t assume ahead of time that openmrs-core won’t be very receptive to the changes you think it needs.
As you said, your “last mile clinician or patient doesn’t have technical skills to write HTML, CSS and JavaScript”. They don’t care if lh-toolkit is a fork of openmrs-core or not, or if the back-end they don’t see is a monolith or microservices, etc.
That XYZ is exactly what I was talking about. I am not sure why you think we are talking past each other. LibreHealth, including lh-toolkit is targeting a different user, and I was articulating our user in my previous reply.
We are indeed dead-set on forking with my reasons towards the end of this post. I am not sure why you thought otherwise, besides stating your belief statement in the original topic title. But I also want to understand the logic behind your belief statement. Do you think that the platform that OpenMRS has built in the last 12yrs is the only one that should exist? Does it in your experience serve all needs and purposes of Health IT platforms? I explained in my previous reply, where I think it doesn’t meet the needs.
Let me give you an analogy. Imagine if all ministries of health and aid agencies were forcing a distribution of Linux on all citizens of a country. Without such a diktat, the citizens of the world have chosen the multiple OS platforms and a large number of distros that meet user needs. This I think is a good thing, and may be you disagree?
I have believed this to be right architecture for a very long time, and hence OWA, REST, Raxa etc… I think the reference app that you have built, is on the contrary tightly bound between end-user-facing and back-end platform. The platform needs changes that make it appropriate for the front-end application and hence we call it a toolkit and not platform. Like I’ve said, OpenMRS needs to take the code changes from lh-toolkit, instead of us sending pull request. It is for OpenMRS architects to decide whether the changes we make are appropriate for its users. We will update all of you about any breaking changes or what we believe your users might need. But you have to take it, if you want it. That I believe is truly the DVCS way of working.
Since you pointed contributions and architectural decisions, let me point out to some history that truly affected how I contributed to OpenMRS platform. I was building the webservices.REST module, in a way that I felt was appropriate using Apache CXF. This would have been JSR-339 and JSR-311 compatible. OpenMRS architects had a secret, unpublished call with architects from Thoughtworks. After the call, I was told my implementation was too SOAPy. My approach instead of being “Entity=Resource”, was more service driven. i.e. representations of tasks that apps perform and using REST calls, should be able to do those tasks, off-course using Resources, but without one-to-one mapping with Entities. My strongly opinionated view then, and today is that OpenMRS proprietary REST services is too chatty because that decision. But what pained me back then, and continues to pain me even more now, that decisions are made on private calls. I’ve been on OpenMRS leadership meetings and calls for 2 years and everyone in the LibreHealth Steering Committee unequivocally thinks that OpenMRS makes decisions and then tells the community, instead of getting feedback from the community. This is what I mean, when I say that governance (processes) and people shape the software that they build.
This is in my opinion the most important task in software development. So I dont think this is unfair. They languish in the backlog, while other features get built, because you did not listen to users. I’ve shown you examples where things were built, but OpenMRS wants pull requests and not explore contributions by extracting features from innovations in the fringes. This is the same policy, when you tell us that lh-toolkit should send pull requests, instead of OpenMRS cherry picking from us.
PIH is the openmrs-platform user for whom the platform is built. That is exactly what I am saying. Like I said in the other thread, openmrs-platform, as a platform has focused on flexibility. We are focusing on usability, for the platform (we call it toolkit because we are not building a generic, one-size fits all platform)… You seem to believe that applications focus on usability and platforms don’t. I am challenging you to follow our development for the next few quarters to realize that platforms can indeed focus on usability.
Like I’ve said, we are not assuming anything ahead of time, because we’ve spent a LOT of time, trying to fix OpenMRS’ way of working. OpenMRS isn’t ready to change… and so we are forking very much “non-preemptively”. I request you to not tell us that we are doing the wrong thing and that we are being pre-emptive. We have tried and failed inside OpenMRS. We want to try again in a different setting.
Chevy vs. Ford?
Obviously without each other, we would have been stuck with 7:1 compression pushrod flathead engines even today. The reality is that neither engine we are working with (lh-toolkit or LibreEHR) is a Chevy or Ford 350 or 351. They are more like a Bugatti engine. It is a waste of time designing a truck around a whizz-bang engine that needs modifications before you get the modified engine. That ain’t the way things are built young feller. Production lines need control on component sources.
I am pretty sure they are considering the front end as well as the back end when starting this here new production line. What they are saying is that their passenger compartment will be requiring something much different.
Instead of worrying what engine they are building this new vehicle around, why don’t you start worrying about making sure they are both capable of using the same fuel, stereos, GPS, tires and other stuff that matter to the end-user supply chain? After all, 10-20 years down the road, if we have not been worrying about being able to freely consume data from any source anywhere, then offer it back up, these products will be long gone from the market.
In the meantime, this drive for innovation in the engine will improve all products around it. If you are not grabbing from LibreHealth, you will at least be seeing what goes on here. Instead of having to hash out slight differences of opinion, you can grab what they do here, tweak it the way you like, then use it elsewhere. This has been the model that the EHR product has seen. It was stuck in the rut of having a single authoritarian controlling and manipulating the show. The only way to get the project to change in a significant way was to challenge it, as change in policy was subverted from the inside time and again. Once the fork was underway, Just about every innovation added was instantly grabbed (despite fighting for these changes for years) as soon or before the fork got it integrated. The original product looks (on the outside anyway) totally different than it did six months ago.
This is driving innovation. If you like, think of it as vaporware. Just an innocent little fork floating around out there. After all, there must be lots of forks of OpenMRS floating around, right? Should it matter that some tribe members want to set up camp further away from the rest of the tribe? Instead of coming to hunt them with spears (the usual, historical violent reaction to schism), why don’t you just wish them well and ask for visiting rights? You might find the schism faction has a better survival scheme. I honestly think that the tendency for groups to drive off splinter factions is a survival skill built into our genetics. There has to be a reason why we produce so many tribal chiefs that no-one can stand.