...
- To improve reliability, there is a tightly controlled OpenLMIS code set that has high test-coverage, high reliability, and changes relatively infrequently
- There is a straightforward way for developers to extend OpenLMIS without forking the code base
- Developing extensions to OpenLMIS is possible for junior developers with little formal software development training (low barrier to entry, minimize complexity where possible)
- The OpenLMIS user interface can be customized for specific implementations without forking the code base
- Extensions to the OpenLMIS code base can be made available to others that may want to use it
- Some extensions to the OpenLMIS code base can be deemed "community supported" (see below), with specific standards for code that the community will agree to support having been defined
- Implementors or System Admins can design reports (ideally) without writing code (possible?)
- The OpenLMIS "default" user interface continues to contain configurability features, such as the configurable R&R (or in the future a configurable stock card), such that implementors can set-up standard OpenLMIS features to match their countries forms and business process using configuration alone (note: we could set a threshold here such as "60% of customization needs can be met by configuration" if that would be useful)
- OpenLMIS continues to include a user interface, or a reference user interface that can be used as a starting point for customization
- Current OpenLMIS implementations have a migration path to the new version (it is not impossible), however it's understood that this will be costly and may not be pursued by every implementation
- Legacy code created for existing implementations can, over time, be migrated out of the core code based into community modules
- In the interim, legacy code created for existing implementations that is not desired for inclusion in core, is "turned off" such that new implementation do not have to use it (i.e. Dashboard home screen)
There is also a question of expectations regarding code reusability. After the re-architecture, it will be possible to clearly define to funders at the beginning of a project how reusable their investment will be, based on the target destination of the code to be created. In most cases, country specific implementation investments will results in community modules that are publicly available, but are likely not designed for easy deployment in additional countries. At the beginning of an OpenLMIS country implementation project, the project team would assess the requirements in coordination with the OpenLMIS Global Team and OpenLMIS Community to determine the target destination(s) for code that will be created and include this in the project plan provided to funders:
- Core: Code created for an implementation would rarely be added directly to core. The exception would be if there is something on the core product roadmap (for example, enhanced bar code support) that a country implementation is willing to fund. Any code generated that is targeted for core must be developed by the OpenLMIS global team, or closely coordinated with the OpenLMIS global team, and meet all standards for core code.
- Community Supported Module: Code created for community supported modules is intended for use across multiple countries, and the community has committed to ongoing support of the module. Requirements are generated across multiple geographies. The bar code library currently being created by PATH is an example of a piece of work that would, in the future, be a community supported module (if the community agrees to support it).
- Community Modules: Most software development done to support specific country implementation would be created as community modules. Community modules are modules created by anyone that are shared with the community. Community modules typically would contain features targeted at in-country stakeholders - the specific requirements of a certain MoH that can not be configured within OpenLMIS. Requirements are derived from a single country. There is no expectation that the code will be useful in other contexts, or that the code will be supported by the community. Community modules may be upgraded to communit- supported modules at a later date if they are deemed useful by the community.
This scenario implies two general funding options for OpenLMIS software development:
1) Ongoing Core Product Funding: The OpenLMIS global team is sufficiently funded to build out the OpenLMIS roadmap. When a country implementation needs something that is on the roadmap, the community can discuss reordering priorities to move the feature "up" on the roadmap. For example, with the VIMS product the OpenLMIS Global Team could have contributed a community-supported stock management module.
2) Project-Based Funding: At project outset, it is decide what (if any) portion of the code should be a community-support module. If so desired, the project funds one of the software development orgs active in the OpenLMIS community to create the community-supported module. Note that any code submitted by an organization for community support must be reviewed and approved by the community.