I appreciate the direction your pushing, but I’m not sure it’s a naming problem.
Platform
Question:
What do AMPATH’s AMRS, PIH’s Mirebalais, Bahmni’s distribution, Haggstrom’s Cancer Patient Portal, CHICA, Regenstrief’s NCD, OpenMRS in Rwanda, OpenMRS in Philippines, Google and MSF’s Ebola solutions, someone downloading & running OpenMRS Reference Application 2.3, and every site that is or has been on the OpenMRS Atlas have in common?
Answer:
They all use the OpenMRS Platform. They may be using different versions of the platform, but they are all using a version of the same, shared platform.
The Platform is what we are all sharing – i.e., every implementation is running the Platform.
The platform can and should grow by incorporating more shared functionality (e.g., idgen), but I think the platform needs to remain what is actually shared. While this may include some UI elements, I think this is more likely to be module & OWA administration ± optional admin functions. I would love to find a way for everyone to share some basic UI (e.g., login screen, framework, style guide), the variation in UI technologies makes this trickier.
Reference Application
As far as the Reference Platform goes, I agree with @mseaton’s key insight:
The Reference Application needs to be modular.
Modularity (e.g. extension points in the UI, built to allow extensibility) was just as critical for adoption of 1.x reference application as modularity was for the platform.
Community Distribution
From my standpoint, a Community Distribution (the “complete” EMR) can be built on the reference application. Regardless, as @darius suggests, it’s going to take a large investment to make a complete EMR. If it’s not modular, then it will just be one more distribution alongside the others. If it’s modular (building on the reference application’s architecture), then there’s a chance other distributions can be created from it.
The Fundamental Issue
OpenMRS is a community of implementations.
We’ve been very successful by sharing a platform, but it’s not a surprise that we’ve hit limits on how much can be shared across all of our implementations. It’s also not a surprise, that a community of implementations has not prioritized nor had the luxury of spare resources to create a distribution that none of them are using in the hopes that it will get widely adopted.
If the community believes the best strategy for the community is to build a “complete” solution that many/most in the community will be able to migrate into, then we need to find the significant resources to make that happen (e.g., a development team of at least 8-10 people dedicated for 2 years toward this task). If that’s the case, perhaps this defines the operational plan for the Objective #2.