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

Re: fineract'ers

Hey all,

Just FYI, I forwarded James Dailey's mail to Ross, and here was his
response.  (There's a little plug in there for ApacheCon as well.
Anyone who hasn't registered yet: there's still time. : o)

"Thanks Myrle,

You are correct I do not actively follow the Fineract dev list
anymore. Feel free to share this back to the broader community list if
it helps.

The below email from James is a good summary of our conversation at
OSCON. This conversation was a general one about “The Apache Way” and
how Apache projects deal with growing pains as their code matures. I
cannot comment on how well James has applied those general lessons to
Fineract today, but I certainly see plenty of good content within this

If I were to summarize that general guidance in a few sentences it
would be to remove as much friction from the contribution process
(code reviews, merit recognition, community alignment) as possible.
Generally speaking the lower the barriers to contribution the faster
the community will grow. This does depend on people actively
monitoring the project, but monitoring is less work than gate-keeping.

Adopting things like Lazy Consensus can be key

In the days of SVN we were forced by the tooling to operate with a
branching model. This works really well. All changes are visible in
one place. Work in progress can be easily discovered and reviewed. It
means those monitoring the project have the opportunity to review work
as it happens, thus enabling them to raise concerns about a design
decision or implementation weakness early in the process. This in turn
meant that when it was time to consider a merge most of the rough
edges had ben talked about *before* they had become deeply imbedded in
finished code. It was easier to fix and people would work together to
design a fix that worked for everyone.

As James indicates Git does not force this way of working. It has
excellent support for the SVN concept of branching, unfortunately
GitHub has driven most people to click “fork” (mostly invisible to the
community) rather than branch. GitHub, therefore, has encouraged us to
work privately then issue a pull request for review when the work is
“finished”. This often means people are not keen to redo their
implementation to satisfy the broader needs of the community. They
will blame the community for “blocking” their improvements.

I am a strong believer in doing as much as possible in the open at all
times and reducing barriers to collaboration.

Interestingly, I have a talk on this topic at ApacheCon this year, if
only I’d written it already

On Wed, Jul 25, 2018 at 7:00 PM James Dailey <jamespdailey@xxxxxxxxx> wrote:
> 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