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

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

This is great information!

 

Can we connect these requests to who wants it?  It seems like one of the
missing pieces for making things work well in a community driven model
is a more direct connection between particular MFIs who want something
and the work that is done to deliver it.  

 

So far it doesn't seem like many MFIs have directly participated on the
Mifos lists (like this one).  Perhaps a better model is to have an
intermediary like Binny, Ed or others who are in direct contact with
MFIs to be their voice on the list.  As Keith has mentioned, somehow we
need to get a tighter feedback loop going between what MFIs want and the
work that is done.

 

The more directly an MFI can express their Mifos needs and desires the
better!

 

One of the things we need to do is develop a system for determining what
features will go into each upcoming release.   

 

Here's a sketch of how that might work:

*         An MFI (or the MFI's "voice" on the list) creates an issue in
Jira for the feature the MFI wants and associates it with the MFI.

*         Other MFIs express their interest in the issue by associating
their names to the issue.

*         As work begins on a release, issues with the most interest are
highlighted as good candidates for volunteer developers to work on.

*         If volunteer developers don't end up working on an issue that
is of interest to an MFI or MFIs, the MFIs with interest could choose to
hire a developer (or team) to implement it.

 

--Van

 

From: Binny Gopinath [mailto:bin...@gm...] 
Sent: Friday, July 01, 2011 9:15 AM
To: A good place to start for users or folks new to Mifos.
Cc: George Conard
Subject: Re: [Mifos-users] [Mifos-developer] Whats after Maya G?

 

Keith,

Here are the high-lelvel points I have gathered during my interactions
with Mifos users:

Priority 1:

Reporting and Dashboards - we have made good progress on this. But there
is still some work here to get a few more key reports created or fixed.
And also sort out some of the ETL related issues, make the ETL job
quicker, reduce installation complexity, integrate reporting UI with
Mifos etc. .. 
Flexibile loan scheduling - with facility for individual lending - Maya
G's allowing a member to have loans with differing frequencies takes
care of this partially. However, navigating to such individual loans
(members may not belong to groups) still will have some challenges in
Maya G
Accounting - there are 2 approaches that MFI's have been requesting in
India:
           a) Integrated accounting module - specifically for branch
level accounting
           Also we need to re-look into accrual accounting and a cash
book maintenance/cash management module
           b) Better integration with an existing accounting software
like Tally
Disbursement date flexibility - ability to specify a loan disbursement
date in the future and not just the meeting period immediately following
the current date
Data migration toolkit - facility for easily and cleanly getting past
member/group/loan data into Mifos - SunGard guys have developed a tool
for this. They did give me a demo of this. We should just test and adopt
this.

Priority 2:

Mobile devices and handheld device integration
Offline data entry - important if Mifos has to be adopted by larger
MFIs/SHGs who have better reach in rural areas (where internet
connectivity is poor and electricity is available only for 1 or 2 hours
on some days)
Adequate Support for Self Help Groups - where more details of each
groups linkage with their banks accounts can be managed, managing
linkage between savings and loans etc.
Support for large MFIs (> 1 million customers) - batch jobs and upgrades
and reporting becomes a challenge with some tables have millions of rows

Priority 3:

HR integration - attendance, user security etc.
Customer acquisition process - to schedule and manage the client
pre-enrollment process (Group trainings and group tests)
Customization of look and feel (logo, colors etc.) per installation -
move internationalization resource bundles to the configuration folder
so that it can be customized and deployed without being overwritten by
each upgrade
Integration with Credit Bureau / Identity verification systems

Thanks
Binny




On Fri, Jul 1, 2011 at 5:41 PM, Keith Woodlock <kei...@gm...>
wrote:

Binny,


> Are we concentrating too much on technical improvements while not
paying
> adequate attention to new/improved features?

Yes, this is the whole point of this email chain. I was asking for
input/feedback from the users about what to put into mifos after Maya
G. So far only george has offered some insight into what might be
useful going forward. From a technical point of view we know what we
need to do but theres no point in taking on that investment unless
customers out there want further features/improvements etc

regards,
Keith.


On Fri, Jul 1, 2011 at 5:50 AM, Binny Gopinath
<bin...@gm...> wrote:
>
> 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...@gr...> 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
>>
>> 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
> Mif...@li...
> https://lists.sourceforge.net/lists/listinfo/mifos-users
>
>