By way of "disclosure", i am a current contributor on another open-source MIS for microfinance, but (to avoid distraction) more about my credentials later.
Every crisis is also an opportunity for change, and i hope Mifos will emerge stronger from the current one. This post is directed primarily at developers and users. I decided on a new post rather than add to the excellent discussion on 'What's after Maya G?' Microfinance as an industry never had access to a competitive market for MIS and related technology. The open-source approach to developing and providing high-quality applications in a sustainable and transparent manner to the largest possible audience holds the most promise to change that for the better. Its time to ask some tough questions about whether Mifos (as the product that was, until recently most likely to deliver to this promise) is living up to these responsibilities. This post has three parts to it. Part one...i have tremendous respect for the developer community, and to them, i'd like to address some pragmatic suggestions with respect to the roadmap for Mifos. IMHO, the real problems that Mifos as a product and its users and developers have struggled with are just a few: a) The lack of integrated and flexible reporting This is the elephant in the room no one wants to speak about. It is preposterous to tell users to find, install, configure, and learn to use a whole new component, server, or toolset (a BIRT/Pentaho/Jasper) to just get to their own data and do some sensible reporting with it. b) Problems with the current codebase that hang about Mifos' neck like an albatross and have resisted attempts at re-factoring. This deadweight has been dragging down Mifos too much, too long c) The failure to release early and often Once every quarter is an eternity in the age of github d) The failure to publish, and promote common standards for application integration and services Mifos did not adopt simple industry standards for data exchange and expose an API that walks the talk, though ironically it is in the most admirable position to do so. Its not surprising that no less than four different efforts to integrate a mobile app with Mifos were mentioned recently, yet, in the absence of an API, i can bet no two of them integrate with Mifos in the same way. Plainspeak for the users: If you like any of these mobile apps, and want to run them, its probably a new effort to integrate their use for every single one of you. It probably also means you can't switch to another app without repeating the effort! And that's just the tip of the iceberg... e) The failure to get as many people on board and get them cracking on the code I hear that a dozen people today have commit rights. Why isn't that number orders of magnitude higher in a world bursting at the seams with Java developers? Part two...my suggestions for the roadmap for Mifos are as follows: the road back to vitality of Mifos lies through the hearts of customers. 1) We move all customers to their own branches, and liberate them to continue to pursue their own needs, while (most importantly) staying abreast of core product evolution. Mifos is yet to realize the consummate ease with which branching and merging can be performed with Git. For those who gasp at the "challenge" of keeping branches in sync with product evolution: this is no longer a problem. Git makes it absurdly simple. (In fact, Git does not even really have a "branch" in the conventional sense, its just some set of commits) Let me say this once again: it is easy to ensure individual customers get their own needs met, while the product evolves in parallel; AND to ensure they continue to receive updates as the core product evolves. This step will ensure Mifos can start responding immediately to customer needs, wherever they may be, and they can each release as often as they needed to This also means that customers in markets "neglected" earlier by Mifos (such as North America!) can decide in favor of Mifos with lower risk. This is a win-win situation that gives a fresh lease of life to customer deployments, brings the community much-needed participation and funds, and liberates product evolution Anyone in the whole wide world, including people that customers can find; can begin fulfilling these needs, perhaps for cash. It is likely these needs are served best by individuals or teams, local or remote; that are already in the ecosystem. They can voluntarily agree to donating back to the product. Surely, this is a better alternative to shutting down one's Mifos shop We will certainly find a wealth of additions on customer branches, these can be cherry-picked (yum!) into the product. I am more than confident we will evolve "master" as well as customer branches in parallel; without sacrificing any choices or assuming un-necessary risks. I can also bet everyone will release more frequently, and customers will lag less in terms of upgrades 2) i am somewhat alarmed by efforts to re-write the product when that might detract from this renewed focus on meeting customer needs. i think that the heavy-hitters on Mifos today should show the way with meeting these customer needs. While doing so, they can agree on spending a fair amount of time to improving the product with the necessary refactoring, or commission a smaller team to retreat into a cave with this express mission. Perhaps the changes needed can happen in a "creeping" fashion, but i don't know enough at the moment to vote in favor of an alternative big-bang approach 3) Any resources that serve the Mifos product and its customers well (such as customer relationships, goodwill, unused sources of funding, and 'softer' assets like domain names, infrastructure, services, etc.) should be handed over to the community. The "nominal ownership" of these resources should be split among volunteers from the community and such ownership should be rotated at regular intervals for all the right reasons. Conflicts of interest are inevitable, but the open-source world has a lot of mileage in disclosing and dealing with these. Ed has already asked for volunteers for the care and feeding of these resources. However, this proposal is *NOT* limited to administration. It insists on securing ownership of these resources, so the community can obtain a measure of self-determination. The community can raise funds in more ways than one, but hopefully, we will do so from happy customers that open their purses for better service To summarize, we must re-assure customers and continue to meet their needs with a lot more urgency, bring in the largest number of developers to participate, and the current committers must show them how. In doing so, a more sustainable business model must be created to meet costs The last part is addressed to the so-called "management" team. To me, management is someone that makes decisions by fiat, and not by participation 1) Grameen Foundation (hereinafter GF), as a 'steward' of Mifos till date has now failed in this role. We have yet to see any introspection from GF on why it did not evolve a sustainable model for Mifos, on what really worked well, and what did not work well while they were at it. I request GF to kindly share these thoughts with us as we stare at the task ahead. 2) More than a few large microfinance organizations rely on Mifos to run the show: a brilliant demonstration of its overall success. However, large microfinance organizations in more than one instance have failed to either scale, or re-architect MIS over time, or adopt another one that may be better suited to their growing needs. The big five of micofinance in India, each exceeding several thousand branches continue to struggle with a branch-based MIS legacy they did not scale in time, and then failed (many times over) to migrate to a more scalable model. We have not seen a plan published for continuity of businesses that rely on the evolution of Mifos. It is likely GF has suggested some plans to Mifos customers it had contractual support agreements with. If so, will you please share them here? (just as maintainers on every respectable open-source project do when they step out) 3) Mifos failed to empower developers and contributors to the extent it could have. What is it in any new proposals to lead Mifos out of these straits that will empower developers to directly serve the needs of users? If you wish to understand my contributions to, and interest in Mifos, see below: * Communicated an RFC for progressive inclusion of full support for accounting in Mifos to the Lead Developer almost a couple of years ago * Contributed to open-source the first tool for integration of accounting packages (such as Tally) with Mifos (see http://mibooks.sourceforge.net/) * Wrote the first HOW-TO run Mifos on the 'cloud' (see http://mifosforge.jira.com/wiki/display/MIFOS/Install+Mifos+on+an+Amazon+EC2+instance) * Assisted more than one microfinance organization pro bono to setup and run Mifos * Participated in the user manual sprint on FLOSS Manuals Please feel free to reach me by any means -- Regards, Krishnan Mani, (email) [email protected] (skype) krishnanm75 (cell) +91 98 500 540 37 ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Mifos-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mifos-users
