Great feedback, Felix, Zayyad.
I would like to share a perspective from history and why the big picture
approach and broader mission is so important.
There was a phrase in use when I was a baby. "Separate, but Equal." This
was a phrase used to justify keeping US school systems segregated by race.
"Separate but Equal" was a lie. The systems were never equal in funding,
quality or anything else.
Finance and access is the same.
*What does that have to do with Fineract?*
Mission solely dedicated to the unbanked shrinks the number of people
willing to join the community.
Others may be sympathetic, but won't directly participate by contributing.
I happen to be interested in the unbanked and personally support that
mission.
HOWEVER, my main interest in Fineract is to support a commercial enterprise
Open Source core banking system. A core banking system which integrates
embedds services anywhere, not just microfinance and money transfers.
When the Fineract mission was focused on the unbanked, it was seriously
under participated IMO. With its slight change in mission which is still
inclusive of the underbanked, participation is increasing and releases are
beginning to become more regular. The unbanked needs to be supported with a
system capable of full integration with the rest of the world, not a
"separate but equal system".
I hope my history story makes sense to at least support my POV.
*How Fineract works for the unbanked with its current mission statement. *
MIFOS is solely dedicated to the underserved and has the frontend to do so.
In my opinion, if collection sheets are still used in working with
unbanked, then MIFOS community should adopt and help maintain them them as
a current, modern, secure function so that the MIFOS frontend works with
the Fineract backend. MIFOS like all other users of Fineract get the
benefit of a stronger core banking system and vendors with dedicated
purpose work together to maintain their particular core channels within
Fineract.
The image is a generalization to convey the concept. (It may not be precise
as to the vendors and players, but should reinforce my POV.)
So, you, your interest or company wants a function or to maintain an
existing function? GREAT!
Step up! Own that solution within Fineract.
[image: image.png]
I speak solely for myself and my POV, but this approach will generate 10X
deeper support than segregated methods.
In the past, there was insufficient community, but I think there was also
"community orchestration" missing to a degree.
*Fail Model:*
Hoping it all gets done and telling the community at large "do something"
doesn't work.
*Success Model: *
When a platform is useful across a whole ecosystem, then it can be jointly
maintained with nominal management. People are willing to help. Just like
musicians want to play music, they want to work together. In RARE
circumstances, the community is so SINGLE minded, the build, like JAZZ,
happens spontaneously and all agree, its really cool.
*However, the bulk of the world needs direction and orchestration* to "make
music" of product delivery. Because of those many different interests,
Fineract needs process to harmonize and create results.
In the end, there also must be a binary decision, "yes or no" to support an
issue. It comes down to; " will a community member support a function
important to their channel?"
I'm not a developer, my useful skills are domain knowledge and
instructional orchestration (process). So I challenge all community members
to find a channel required to fulfill your channel or interest and
volunteer to "own it" through a date certain. Better yet, form a small team
of like minds and assure that function is ALWAYS current and secure.
This is a challenge to all community members and targeting no one.
Paul
On Sat, Aug 30, 2025 at 3:34 PM James Dailey <[email protected]> wrote:
Zayyad, Felix and others -
Indeed. And all of this was laid out for many years as the strategy.
When I was on the Board of Mifos (the non profit, not the project) we
decided to contribute the MifosX code to the ASF to ensure both:
a) a broader financial services industry approach, and
b) a more established foundational home for the core of the project.
There were other reasons, but those remain primary in my mind.
The concept was that Mifos org, which is a Vendor in the ASF parlance,
would continue its Financial Inclusion mission and make sure that the
releases that were coming out of the project would retain the flavor and
intent of the original mifos project (which I started and designed in
2001). The Mifos AdminUI /CommunityApp open source front end UI gave it a
place in the ecosystem and a way to ensure that alignment.
But, importantly, when we made this decision, we deliberately wanted to
see more financial institutions and fintechs use the backend system, AND
vitally, to help maintain it, with contributions upstream. That is the
sign of a healthy open source project.
I don't speak for Mifos, but I believe that the vision at Mifos remains
about financial inclusion. But the vision of Fineract and the mission of
the project is different. We actually VOTED on this revised statement as a
community, I think five years ago.
So, if you are seeing a difference between Mifos and Fineract, then we
have succeeded in an important goal. The two are NOT THE SAME. This is
NOT mifos.
This has been called out in many many Reports to the ASF Board. See the
wiki pages for those. The key theme is Vendor neutrality - we do not
privilege any vendor.
And, I would argue that this is the right healthy direction for this
Fineract project. Microfinance serves an important role in the world, and
continues despite many expecting it to decline or go away. And, the
mission of the original concept of Mifos was not about Microfinance but
about financial inclusion. However that happens.
And, fundamentally, I personally remain focused on this - disrupting the
financial industry with open source software that can functionally be the
basis of any bank or fintech globally. It should lower the cost of
financial inclusion, it should do that via any kind of institution at a
structural level. Unbanked and underbanked are included.
So, if you are not seeing what you want here, then you can invest more
time and resources to make it more of what you want, but I would also
suggest that the fundamental thing is to have healthy vendors that move the
project forward with lots of "built on top of" functionality that serve a
wide range of financial institutions. If those components are also open
source, that's ok, but it isn't essential.
** Deprecation process **
Deprecating features is a natural part of any system evolution - we need
to prune the tree from time to time. If users are demanding those features
then they should speak up - as this thread illustrated - and mechanisms
need to be put in place to "protect them". Here of course, I am referring
to my last email and testing, to start with.
And, we should do a better job of documenting the product roadmap, and
having clear discussions about deprecating features - Before they are
deprecated.
That starts with you listing your required feature set and documenting it
somewhere perhaps - or relying on the Vendor to speak up for your interests
if you don't.
And, this is a good discussion to have. Perhaps a community call on this
topic would be welcomed in coming weeks.
James
On Sat, Aug 30, 2025 at 3:13 AM Zayyad A. Said <
[email protected]> wrote:
Hello Fineract community,
I concur with the observations below from Felix.
We have been implementing Mifos since 2011 and we have seen the project
transitioning from Mifos 2.x to Mifos X and now with the new developments.
The current focus seems to have shifted from the original mission of
"Creating a world of 3 Billion Maries where each of the 2 billion poor and
unbanked has access to the financial resources needed to create a better
life for themselves and their family."
Group lending has been used for decades and Mifos was originally intended
for and served the model, the new features being introduced are geared
towards commercial use. We saw this coming and we had to maintain old fork
for our MFI clients where we continue to improve based on their needs.
While I have no problem with having new features, I seem not to
understand why we want to deprecate features of group lending that are
still being used even if with the minority of users globally yet they do no
harm to the security and overall performance of the project.
I suggest the leadership to rethink the idea of deprecating collection
sheet functionality and other key features used in group lending.
Best Regards,
Zayyad A. Said
Intrasoft Technologies Limited
*********
*Zayyad A. Said | Chief Executive Officer*
Suite H32, Delamere Flats - Milimani Road, Nairobi.
Cell No.: +254 716 615274 | Skype: *zsaid2011*
Email: [email protected]
Schedule Meetings: https://calendly.com/zayyadsaid
<https://calendly.com/zayyadsaid>
*" You can achieve what you want if you just help enough others get what
they want.."*
*Note: Save the environment, please don't print this email unless its
really necessary for you to do that.*
On Sat, Aug 30, 2025, 11:20 Felix van Hove <[email protected]>
wrote:
Let me chip in with a more personal perspective.
I'm following the development of the Mifos web app and - to a certain
extend - Fineract for a couple of months only. My impression from the
influx of new features in Fineract is that these are predominantly not
for microfinance or small entities, which Mifos once set out to support.
In fact - Fineract only states that its efforts are also "including the
unbanked and underbanked" - not its focus.
I see the deprecation of the Collection Sheet feature in this context.
How many new features have been added in the last 12 months that help
the "unbanked"? How many have been added that help larger commercial
entities and are of no benefit for "the unbanked"?
My personal contributions depend solely on Mifos/Fineract supporting
efforts for financial inclusion. I regard it as of utter importance
respective features don't come as a plugin, but first class citizens.
My knowledge regarding fintech is very limited. If I'm wrong or
misrespresent things, please tell me.
Felix
On 29/08/2025 21:01, James Dailey wrote:
Devs - Are we done with this?
First, I am NOT ruling out this functionality as important but if no
one is
actually demanding it, and no one is willing to maintain it, then it
doesn't get maintained. That is the nature of open source projects.
Second, it can happen that an outside vendor (e.g. Mifos) that relies
on this Collection Sheet functionality (or any functionality)
inadvertently
drops that from their front end release. Because the tests at
Fineract do
not cover this fully, no one at the Vendor and no one at the Fineract
project will see the functionality fail in a build until a customer or
implementer notices. So, tests are vital for ensuring ongoing
maintainability.
Third, if this type of thing isn't "naturally" part of the core - then
it
will make a lot more sense to have it be an outside extension - in
which
case the tests have to be written for the API calls, and a Vendor
should
try to get such tests contributed. I could be wrong about this, I
would
be happy to debate where this belongs.
@Edward Cable <[email protected]> - what is the assessment and status
of
needed functionality and where do you think it should live?
Thanks,
James
On Mon, Aug 18, 2025 at 8:21 AM James Dailey <[email protected]>
wrote:
Sifiso -
Do we have a way to reach the tens of thousands of institutions you
believe are there?
My belief (just anecdotal information) is that it’s more like a few
hundred institutions and that out of that number, less than 10% are
on a
recent release. And, of that smaller number, few, if any, are still
using
Collection Sheets. I could be wrong - I’d like the data! I’d say
that
vendors can show up with their data here to help make this vendor
neutral
space more informed.
If group lending and group-member lending and collection sheets are
still
needed, then perhaps those project volunteers can contribute the
needed
updates to keep the functionality useful.
Thanks
Thanks
On Mon, Aug 18, 2025 at 6:48 AM Sifiso Mtetwa <
[email protected]>
wrote:
Hi guys,
This is an interesting topic. I have been wondering why, in general,
we
seem to be deprecating more and more system functions. The individual
collection sheet has served us well over the years and still does, If
anything we could improve on its functionality by maybe adding a bulk
collection sheet template with little detail compared to a full loan
repayment bulk import template.
Fineract is used by tens of thousands of organisations throughout the
world and most of them are not on this listing and may not have a
voice to
air their concerns. Maybe we can find a way of exposing this thread
to
include more voters.
Regards,
*From:* James Dailey [mailto:[email protected]]
*Sent:* Saturday, 16 August 2025 02:53
*To:* [email protected]
*Subject:* Re: Collection Sheet Deprecation was [Re: Questions and
Observations on FINERACT-2290 (Collection Sheet API Refactor)]
Ed
I agree this needs to be discussed but it is important to acknowledge
that THIS Fineract listserv is the only official (and required)
discussion
space. It is not the intention to bury anything in “an email
thread”.
When I started up Mifos we spent a lot of time looking at Collection
Sheets and designing process flows around them. I fully know that
this
design direction was important back then in 2002-2006.
However if there is no one here asking for them to be retained
besides
you, then that is a sign that they have perhaps reached an end of
their
utility. Or, that the users are not actually here, which is a
different
problem.
So,… If there is a group using collection sheets in production AND
they
are not on some permanent forked (old) version, then now is the time
to
speak up. Here.
Generally, I’m fairly certain we can refactor this with an eye toward
extracting it from the core. Repeating the logic in two places
makes no
sense either. Collection sheets are kind of assembled from
constituent loans and savings. The balances and due payments should
be
calculated in the underlying components.
As the system gets restructured we need to decide to keep this at
all, to
keep it in a new place, or as some external concept/plug in. Why
wouldn’t
we want a separate component?
Cheers
On Thu, Aug 14, 2025 at 4:16 PM Ed Cable <[email protected]> wrote:
I'll leave the other thread for discussion of the API versioning and
refactoring related to Collection Sheet API but wanted to create a
separate
thread regarding the deprecation of the Collection Sheet.
In general, for this and removal of any functionality, it's something
that needs to be discussed openly with the community and with a vote
and
not a decision buried in a mailing list thread.
For the collection sheet specifically, more thought has to be given
to
its deprecation as the centrality and highly coupled nature of the
collection sheet is being understated as it isn't merely a report
that's to
be printed or a form filled out via a mobile application. It's a
significant portion of the user interface and highly coupled to many
of the
microfinance features around groups/centers/meeting scheduling, staff
assignment, etc.
I do agree that from a UI perspective, the collection sheet and other
microfinance-centric functionalities and flows should be viewable
based on
a configurable setting. As it doesn't lend itself to the optimal user
experience for a large portion of current Fineract user base.
I also am supportive of a strategy of slimming Fineract to its core
services and functionality above core Fineract services and APIs can
be
extracted out.
So I do think we should give thoughtful consideration to what
abstracting
out the collection sheet and corresponding microfinance
functionality would
look like and what that effort would entail to abstract it out
without
adversely impacting the original user base of the software but it's
not as
simple as deprecating these API.
I welcome others' thoughts and inputs as I know even with
microfinance
itself, the methodology has evolved and group lending and the
concept of a
collection sheet isn't as central as it once was
Thanks,
Ed
On Wed, Aug 13, 2025 at 6:36 PM Kapil Panchal <
[email protected]> wrote:
Hi James,
I can proceed by marking this feature as @Deprecated and/or
performing a
safe refactor to remove the API.
For API versioning I agree to Aleksandar Vidakovic's proposal on
adapting
to the SpringBoot v7/Spring Framework v4. If I may, Aleksandar
Vidakovic takes the lead on this project and I can help to support
the
conversion?
Thanks,
Kapil
On Thu, Aug 14, 2025 at 5:07 AM James Dailey <[email protected]>
wrote:
Hi Kapil
I might suggest looking at this as an opportunity to remove the
collection sheet entirely from the Fineract namespace. It’s a legacy
concept I and others designed a long time ago, originally in 2002
based on
collection sheets we gathered from a dozen countries. It is strongly
tied
to concepts in microfinance field operations, and especially when
there was
no data connectivity.
It belongs perhaps as a sort of external microservice - data loading
via
a bulk import could still be enabled.
The API versioning is a good idea but needs to be more holistic
across
the platform I think.
On Mon, Aug 11, 2025 at 4:43 AM Ádám Sághy <[email protected]>
wrote:
Hi Kapil,
Thank you for raising the concerns below. I’ll need some additional
details to fully understand your points:
1. *Collection Sheet API* – You mentioned it appears
non-functional
and contains several logical errors.
o If it’s indeed not working, that’s a separate, high-priority
discussion.
o Could you clarify which logical errors you were referring to,
and
what specifically makes you think it’s non-functional?
2. *Service annotations* – You noted that service methods are
not
annotated with @Service and that beans are defined manually.
o Are you referring to the
CollectionSheetWritePlatformServiceJpaRepositoryImpl bean being
defined
via configuration?
3. *Repository wrappers annotated with **@Service* – You
mentioned
that this mandates full unit test coverage but that they should
ideally be
annotated with @Component.
o Could you point out the exact classes you had in mind?
As for the other points, I agree we can refactor and remove redundant
logic—please feel free to suggest specific improvements or start
work on
them immediately!
However, be careful by moving anything into the fineract-core… We are
aiming to keep it as small as possible as everything is built on top
of
this module! If collection sheet are used for loans and savings - for
example - than the recommended move is NOT to move this logic into
core!
Either:
- we split the logic into fineract-loan and fineract-savings
- Move the logic into a new module
- Leave it in fineract-provider for now
Shall you have any questions, please let us know!
Regards,
Adam
On 2025. Aug 11., at 12:09, Kapil Panchal <
[email protected]> wrote:
Hi Adam,
I’m currently working on *FINERACT-2290* and have a few questions
before
I submit a pull request.
The *Collection Sheet API* in its current state appears
non-functional
and contains several logical errors. It seems there was an earlier
attempt
to convert from a JSON string request parameter to a class-based
request
object, but:
Certain fields are missing.
The serializer is not correctly populating the objects, which causes
the
conditional checks to be bypassed and results in incorrect (false)
responses.
This change set is *high risk* because it touches most of the loan
and
savings product logic. I’ve had to refactor almost all major methods.
Extensive integration and end-to-end testing will be required to
ensure
there are no regressions, especially in edge cases. At present,
there are
no unit or integration tests for this functionality, and test
creation is
outside the current ticket scope. I’ve been iterating on this for a
while,
and only today have I reached a stable state after several
experimental and
build-breaking attempts.
*Key Observations:*
Service methods are not annotated with @Service; instead, beans are
defined manually.
Repository wrappers are annotated with @Service. This mandates full
unit
test coverage for these methods, but they should ideally be
annotated with
@Component.
I agree with prior discussions on separating bean validation —
having a
dedicated @Component validation class allows the request object to
handle
checks independent of database queries.
Validation components can also perform database-related validations;
these can be injected into service classes for cleaner architecture.
Such validation components should be placed in *Fineract-Core* so
they
are reusable across modules, reducing future refactoring needs.
The current design of having commands in *Fineract-Core* and
handlers/services/repositories in respective modules is good — it
cleanly
decouples command definition from execution.
There is extensive use of this. in singleton contexts (API, Service,
Repository). While not harmful, it’s unnecessary boilerplate.
Multiple redundant intermediate DTOs exist where the request DTO
itself
could be reused for data transfer.
I found redundant logic — e.g., a for loop with a break statement
that
effectively executes only once; this can be simplified.
Some JDBC template queries use reserved SQL keywords, causing
exceptions.
Refactoring these queries resolves the issue and returns proper
response
objects.
*Suggestions:*
*Where appropriate, large tickets should be broken into subtasks to
manage complexity and reviewability.*
It may help to have a dedicated *developer-only Slack channel *for
technical discussions. This could complement other community spaces
if
there’s a need to keep certain conversations more focused.
What are your thoughts on the above?
Thanks,
Kapil
--
*Ed Cable*
President/CEO, Mifos Initiative
[email protected] | Skype: edcable | Mobile: +1.484.477.8649
*Collectively Creating a World of 3 Billion Maries | *
http://mifos.org
<http://facebook.com/mifos> <http://www.twitter.com/mifos>
