[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 -->

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

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:


   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”)

   Merge and review - rather than review and merge should be adopted by the

   Releases must be scrutinized but the “tip” or “head” of dev can be
   merges that may be subject to review and revert-backs

   If you break it, you unmerge it  (tests coverage is your friend!!)

For more information on project maturity at Apache, please read


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


Board Chair, Mifos