Hi Van - I missed this when it came through last month. Here are a few thoughts based on what I'm seeing so far in Africa:
>> 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. I agree with that hypothesis and i think you're dead on that it's gonna be hard - especially as the development time/energy on Mifos decreases in the future - to optimize for both/multiple audiences. The surveys/voting on features discussed on other threads is a good start at getting more MFIs engaged on direction setting for Mifos but I think we'll also have to take a decision as a community as to the overall strategic focus for Mifos. With fewer resources, Mifos can't be everything to everyone (it never could in the past either, but it's way more true now). I think the focus we had at Grameen Foundation - small to medium sized, visionary MFIs - was good. Doing the API development you talked about will also make it a lot easier (presumably) to build loosely coupled extensions to Mifos that don't necessarily have to be maintained by the full community, and hopefully would lower the QA/etc burden. > 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. I guess the question there is: do we (the community) have the resources to do a rewrite like that? It sounds good in theory but if it takes 3 years and all of the limited community resources, it may not be as good for MFIs as living with the existing codebase. Does it make sense to have a thread on what has already been rewritten that could be reused, and what would need to be rewritten? We could see how much of the old code functionality could be pared away if we were super focused on a particular class of MFI. I looked at Keith's doc that you linked to - wonder if the thing that's missing is what we could lose without killing Mifos altogether. That said, if you and Keith and others just wanna rewrite the thing over the summer that would solve the whole problem. I'd offer to help, but I suspect my code would be a net liability rather than an asset. :-) > 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 interesting, that sounds like a good place to start - especially in the "Projects" model that Ed was talking about. I won't likely be hiring engineers in Africa until September at the earliest, but this is super helpful in thinking about where we might focus efforts when/if the business/org I'm scoping out comes online. Cheers, -george George Conard US: +1 206 778 7429 Kenya: +254 (0) 705 038 704 Ghana: +233 (0) 54 975 4222 www.georgeconard.com [email protected] @GeorgeConard ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Mifos-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-users
