Re: [Mifos-users] [Mifos-developer] Whats after Maya G?

[Van Mittal-H. <va...@gr...>]

George,

I'm catching up on some of these threads after being out for a few days

> - there's a mobile revolution underway in sub-Saharan Africa; building
> both the APIs/hooks for connecting into a variety of mobile systems
> (from mobile money to mobile interfaces for clients and MFI staff to
> exchange of info with other systems that are running mobile apps) and
> also potentially getting a few sample/reference mobile apps running on
> Mifos (need to vet specific pain points so we don't build something
> just for the sake of building it)

If Mifos provided Restful or WSDL based APIs it would open up lots of
possibilities for building on Mifos for things like this.  Having stable
APIs for people to build on is one of the things we have been working
towards for some time.  A lot of KeithW's efforts in particular have
been around getting internals to a state where we could start layering
an API on them.  As mentioned, getting specific customers with specific
use cases to drive this is key.

> also for you and the other engineers who have worked on MIfos: in a
> community model if there's less oversight, is there under-the-covers
> work that should be prioritized which will help keep Mifos stable and
> scalable as it goes forward in the community?

Here's where some big questions come up.  

One hypothesis is that there are two classes of Mifos users-- Class 1:
larger MFIs who have a need for various extensions and customizations of
Mifos and who can take on some expense to do that and even host their
own infrastructure and Class 2: smaller MFIs who could likely manage
with fewer features and less extensibility and who would benefit most
from low cost hosted access to Mifos.

How to most effectively meet the needs of both users is tricky.

We've been challenged by the current code base being difficult and
expensive to extend and maintain.  We have made progress in improving
the code and certain areas of it are much easier to deal with now.
However, there is still a large amount of code left that needs
improvement.

The most cost effective way to deliver a solution that can be
effectively hosted at very low cost (supporting multi-tenancy for
example) at this point looks like a rewrite that would pull in reusable
parts of Mifos but redo the basics from the ground up to get things like
multi-tenancy, transaction management, auditing, clean i18n, layered
architecture, separation of concerns and manageable tests in place.  To
keep the cost of doing a rewrite low, it would help for the target
release to have fewer features and options than Mifos currently does.

On the other hand,  supporting larger existing and new MFIs and those
requiring the larger feature set currently supported by Mifos would
benefit from the current code base being extended and refined.  The
difficulty here is that the cost to continue maintaining the current
code is high as is the cost to refactor and improve it.  

Keith and I are in agreement on the things that he already laid out
here:
http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+
Maya+G+and+onwards%29

This is a good list of how the current code base could be moved forward.


Replacing the current Struts/JSP based UI code with Spring/Freemarker is
the biggest single enabler for lowering the cost of maintaining and
extending Mifos.  It leads to:
* API creation across the application (by achieving complete separation
of business logic from presentation code)
* simplified transaction management
* simplified i18n
* improvement of layered architecture
* reduction and simplification of test code

--Van