Hi All - For the good of this project, I'd like to share some ideas gathered and shared in a side meeting at OSCON18 with Apache President Ross Gardler who was one of the champions of this project. You can read the official PMC reports that go to the Apache Board here --> https://cwiki.apache.org/confluence/display/FINERACT/Board+Reports
I am not a member of the PMC, nor a committer, but I have been involved from the beginnings of this in 2002. So, I am hoping to share both the short term and the long term view. As most of you know, the Mifos Initiative contributed the code to Apache and remains - as an external entity - highly interested in ensuring the continuation and growth of the project. In the Apache worldview, Mifos offers a kind of "productization" of the *project*, and the hope is that many more such entities - for profit companies in particular - will productize, and contribute back via the community of developers, requirements and ideas. In other projects we know within Apache, contributors can be paid by companies to make sure that their priorities get attention. Those companies and entities provide a kind of "wrapper" around the project and can provide things like dashboards, add-ons, and deployment scripts. Thus a virtuous cycle is born and supported. What we do not want, and must try to avoid, are hard forks by the users (entities that take the code and deploy in the real world), where they have long standing unmerged changes, and worst that these changes are incompatible with the upstream changes that are on the main fineract dev branch. This then leads to harder to maintain code at the users and more costly duplicative development for all. This is the opposite of the virtuous cycle. If there are large unmerged changes that can be proposed for either Fineract1.x or for Fineract-CN, I believe a key way forward would be to make those branches visible. Fortunately, and tongue firmly in cheek, there is a mechanism available in git conveniently called a "branch". I think the PMC should consider this approach to bring into the fold those outside entities that are on forks (via the individual contributors) and then to have a clear process by which a serious attempt to evaluate and accept such changes into the main branch are undertaken. It is probably naive of me to think that the point of forking is that clear based on a defined release, but one can hope. In any case, the project would be much assisted if code that is written for real world situations is made visible for merit-based evaluation and inclusion. That can, and probably should, exclude productizations (plug-ins, deployment scripts, UIs, report infrastructure) that give companies a differentiation in market. However, underlying code changes that make those things work better need to be contributed back so that the “wrappers” can be a kind of patch that is easily maintained on top of the fineract release. If you are part of one of those companies, please now do comment on what is holding you back, and make an attempt to move all of your infrastructure to the latest stable fineract release (identifying issues as they arise). The other thing that we should strive to avoid are PRs that sit around and remain un-merged. (as noted by PMC) This is an obvious problem made worse, I believe, by having some number of contributions that may not have anything to do with the needs of the broadest set of actual users. If the community is out of sync with the users, which is possible in a project that is NOT involved in a direct "scratching the itch" kind of thing. (referring to the axiom that most opensource projects are developers scratching the itch for software that works for their needs). To solve this problem, the Apache board recently heard about a cool innovation that seems obvious in retrospect: allow non-committers to review and comment on proposed Pull Requests, thereby determining their priority and earning the non-committer points and merit towards committership. Also, we should have a cultural project norm here where a few things can change around PRs: 1. Committers should be free to merge if no objection is heard (a time frame of 72 hrs is probably ok, to be set as “community norm”) 2. Merge and review - rather than review and merge should be adopted by the PMC 3. Releases must be scrutinized but the “tip” or “head” of dev can be merges that may be subject to review and revert-backs 4. If you break it, you unmerge it (tests coverage is your friend!!) For more information on project maturity at Apache, please read https://community.apache.org/apache-way/apache-project-maturity-model.html By the way, and now speaking with my non-profit Mifos hat on, a key intent of moving the code over from Mifos to Apache was to broaden the community and broaden the appeal. When I say "Mifos contributed" I also mean to say all of the contributors to the Mifos project, who worked on it as an open source project from 2005 to present, are part of that. It is accurate to say that the Mifos community was already an active one and a key accomplishment over the past two years is bringing over the code and the community to Apache. But more needs to be done to clarify. Mifos community code (also released under apache 2.0) is now a wrapper on top of fineract. Fineract can include binary releases for convenience but the code is the thing, not the productization. Mifos is also continuing to play an important role in organizing the community of financial inclusion around fineract - I submit that that is not inconsistent with the PMC trying to market fineract to both the financial inclusion community and the private sector interested in payments, banking, etc. As a non-profit, Mifos has much of the same operating imperatives as Apache, but with a narrower focus on financial inclusion. We probably need advice from our apache friends how to address this dual role. Finally, I am inspired by what so many have accomplished on the mifosX → now fineract 1.x codebase and what is promised by the fineract-CN code. I continue to envision fineract in the broadest and more inspiring terms. Opensource will eat the world and the financial world is only beginning to be heard from us. Please do comment on this post and suggest ways to operationalize or object and say why. THANK YOU!! James Dailey Fineract’r Board Chair, Mifos
