Kevin Cussen (Deactivated): Premised with the two biggest pieces of feedback from the memo. CHAI wanted to share more granularity about proposed projects. Rather than just dependence on the re-arch, they would have liked to share budget as well as timelines. Ashraf believes that we need to mature the process for vetting project further.

Lakshmi Balachandran: CHAI's belief is that BMGF needs a more complete picture of the budget, timelines, (too much background noise - Lakshmi agreed to relocate)

Ashraf Islam (Unlicensed): We (as a committee) were scrambling to get the memo out. If we had more clear objectives and a more defined process, this wouldn't be the case. After we submitted the memo, Sarah Jackson said she would inform of feedback from BMGF. Do we have that update?

Kevin Cussen (Deactivated): No update yet, I can follow-up later today. Did you have any specific feedback on how we can update the process to be more rigorous?

Ashraf Islam (Unlicensed): From my point of year, 1 year for the the re-write option seems very optimistic. How did you come to this? We were not involved in this discussion. Specifically, what will happen to countries that have specific modules. According to your doc, these countries will need to re-write their modules to take advantage of this new version. This is all with time and money they don't have. Countries should be involved in the discussion on a re-architecture.

Kevin Cussen (Deactivated): Discussed where the 1 year came from - hypothetical situation posed from BMGF where resourcing is not an issue. Both the incremental re-architecture, and the complete re-write are on the table still. We had estimated 18 - 45 months for an incremental re-architecture. This number is heavily influenced by how regularly extension points are requested by the community.

Ashraf Islam (Unlicensed): Countries aren't the funders, the dynamics are different. I think the 1 year is still optimistic. You can't just double the number of developers and half the time to deliver. If you look back on the original OpenLMIS team, there were 20+ members and it still took more than a year. Right now we're at 3.5 years of development on OpenLMIS and there are still feature gaps.

Kevin Cussen (Deactivated): 2 things about a re-write. Based on the feature variability matrix, we'll have a roadmap of where things are constant and what things are changing regularly. This will guide our approach during a re-architecture. Since our team has a lot of familiarity with the platform, this will be our second take on the software - which according to "write once, throw away" is where you get a lot of time and quality benefits. Second, the domain of a re-write will be much smaller than the current feature footprint.

Ashraf Islam (Unlicensed): There are existing shortfalls in functionality that continue to be unaddressed, should be addressed now rather than doing a re-write.

Kevin Cussen (Deactivated): If we continue to add features to the current version of OpenLMIS, we're running towards a wall. Shared contribution / shared benefit is incredibly hard given the current architecture. Several software projects both in the HIS space and commercially have had to write a modular re-architecture (see mifos, OpenMRS, etc.). All software systems have a lifespan, and that lifespan needs to be taken into account when you implement a new system. That system won't last forever in stasis. Regarding process, do you have specific feedback on what process you want to see put in place that was not for the BMGF memo?

Ashraf Islam (Unlicensed): Jeff from TW presented a framework at the community meeting. He said it was preliminary, and now you're saying this is what we're doing.

Kevin Cussen (Deactivated): We are not defining the technical re-architecture. We as the product committee are defining what the end-state looks like. For the several meetings after the community meeting in September, this is what we worked on and you can find the outcomes here.

Ashraf Islam (Unlicensed): By defining the outcomes and giving free reign to the tech team, we're showing a lot of faith that these people can execute.

Kevin Cussen (Deactivated): That's true. That's a big part of the reason we're working mostly with our internal team and for the purposes of a re-write we're speaking to partners we or someone in the community has background with. Lakshmi, perhaps if you're back on the call and have reduced background noise you can speak to CHAI's agenda.

Lakshmi Balachandran: In discussions with BMGF, they are looking to understand not only dependencies but also timeframe and budget implications so that can prioritize. Both BMGF and the donor community. How would the white label app be developed in parallel with the re-arch, does it effect budget and timeline for one or either? Has there been any feedback from BMGF? Should we put together a follow-up?

Kevin Cussen (Deactivated): I can follow-up today on feedback. Anything else regarding Lakshmi's comments? I'll follow-up later today and we can formulate a response on that chain and determine if a follow-up to the BMGF is necessary.

2.0 Release

Kevin Cussen (Deactivated): The 2.0 release will be happening this week. We'll be releasing several goodies:

A new master release
A demo server running a default copy of 2.0
A demo server running a copy of 2.0 with everything toggled on
An OpenLMIS Release doc describing toggle functionality, a complete list of features that have been toggled on/off and why
An update log containing changes / bugfixes
The feature variability matrix

Feature Variability Matrix Recap

Kevin Cussen (Deactivated): The feature variability matrix is a document that gives an easily digestable view to where feature variability has happened. Each row is a feature or sub feature and each column is an implementation. You can use the doc to quickly scan whether there has been a lot of variability for say "requisitions". I've merged in changes from TW, JSI returned the document late last night so I'll be merging them today.

Renee Orser (Unlicensed): TW created a column for the CHAI / TW android app in Mozambique. Largely filled out the "in use" column rather than adding rows.

Ashraf Islam (Unlicensed): Because of the design of the feature matrix, it's very high level. More detail would be more helpful.

Kevin Cussen (Deactivated): We did wrestle with how to make it consumable. The original document I made to guide our developers was much more granular and low level and ultimately not digestable by a general audience. Based on a recommendation from our new Director, we decided to construct the feature variability matrix which I think is a good mix of detail and consumability. Feedback on future iterations is welcome.

Kevin Cussen (Deactivated): Lastly, for next our next call I'll be reserving some time for community members to join and give feedback on the default scope of the 2.0 release. That is, what features have been toggled on and off. As part of the release doc, we've invited the community to come voice their opinions on the product committee. If there are no pieces of feedback on the FVR... other topics... AOB, then thank you for your time.

RECORDING

ADDITIONAL READING