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.
Oh, they clearly do!! Read this… http://www.linuxquestions.org/questions/general-10/do-all-linux-distros-use-the-same-kernel-721906/ . I closely follow at least a couple of distros to know. Some maintainers do a very good job at letting the kernel folks cherry pick.
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.