Are we concentrating too much on technical improvements while not paying
adequate attention to new/improved features?
Technical improvements without any visible improvement to end-users - may
cause users to consider moving away from Mifos. I would like releases to be
a mix of new/improved functional features + a bunch of technical
improvements. I have had the chance to get a glimpse into some of our
competition and very soon our feature set is going to be insufficient, which
is heartbreaking ..
On technical improvements:
- would be good to include testing/handling of larger volumes - I have had a
couple of enquiries from large MFI's - one of them has 4+ million members
- on i18n, would be good to allow overriding of specific internationalized
labels look up from config folders - so that they do not get overwritten by
any upgrades. And also handle date formats consistently, especially in
reports.
Thanks
Binny
On Thu, Jun 30, 2011 at 10:33 AM, Van Mittal-Henkle <
va...@grameenfoundation.org> wrote:
> 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<http://mifosforge.jira.com/wiki/display/MIFOS/Technical+Roadmap+%28Post+%0AMaya+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
>
>
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Mifos-users mailing list
Mifos-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mifos-users
