Hi all, As James suggested, I'm moving this discussion to the list. My original email about revolving loans (FINERACT-134) as a GSoC 2027 project and James's reply are below.
Taking James's point that GSoC projects shouldn't keep adding functionality to core, I'd like to propose it as a plug-in instead: a proof of concept for a revolving line of credit built as a custom module ( https://fineract.apache.org/docs/current/#_custom_modules) in a separate public repository, with an FSIP drafted and discussed on its own. A few questions: 1. Would a revolving line of credit proof of concept as a custom module, outside core, be a suitable GSoC 2027 project? 2. The custom module docs describe modules as a proof of concept. Can they support a new product type today, or would part of the project be extending that mechanism? 3. Would anyone be interested in mentoring it? Thanks, Abhishek P.S. Thank you James for the detailed reply. I'd love to dig in and find out just how entertainingly complex the FSIP turns out to be. ---------- Forwarded message --------- From: James Dailey <[email protected]> Date: Mon, 2 Nov 2026 at 01:30 Subject: Re: GSoC 2027: Revolving Loans in Apache Fineract To: Abhishek Chaudhary <[email protected]> My perspective is that while this kind of functionality *may* be useful, I also think it should be part of a plug and play approach into Fineract. I also think our community should focus primarily on Security and Stability projects in Fineract code: paying down technical debt, adding tests, improving performance, and pruning functional areas. I think the *core* Fineract project should have less functionality out of the box, not more. That's my general and entirely personal take. GSOC projects that constantly "ADD" functionality into Fineract core have the side effect of making it more complex and potentially less maintainable. Proof of concepts (on outside public forks for a student or in separate branches or repos) are more welcome, in my view, than projects intended to go upstream into a system used in *Production* in a number of places. An FSIP for revolving line of credit is perhaps useful as a project in itself. So, I am certainly open to you proposing something for discussion. I'll be upfront and say that I may not be able to give much mentoring to this. Your short list is scratching the surface - the multitude of edge cases are "horrendously" or "endlessly" or "entertainingly" complex (depending on your point of view). - James On Fri, Oct 30, 2026 at 8:50 PM Abhishek Chaudhary < [email protected]> wrote: > > In the community chat, Adam mentioned that revolving loans would be a > useful addition to Fineract, with an FSIP once there is a high-level design. > > I'd like to propose revolving loans as a potential GSoC 2027 project and > get your feedback before going deeper into the design. > > There is already some relevant groundwork: > - FINERACT-134 <https://issues.apache.org/jira/browse/FINERACT-134> asks > for revolving line of credit products, and James, your comment there > suggests an FSIP and outlines the main design concepts. > - FSIP-010 > <https://fineract.apache.org/docs/current/#_fsip_010_revenue_based_working_capital_loan_product> > shows > how the Working Capital Loan product was proposed as a new loan product > type. > - the Working Capital Loan documentation > <https://fineract.apache.org/docs/current/#_new_loan_product_type_working_capital_loan> > provides > a useful reference for the closest existing product. > > I have some initial thoughts on what the high-level design would need to > address: > - Credit limits and available credit > - Billing cycles, statements and minimum payments > - Interest calculation on revolving balances > - How the new product fits alongside the existing loan and working capital > loan modules > > A few questions I'd appreciate your thoughts on: > 1. Do you think revolving loans would be a suitable GSoC 2027 project? > 2. Would it make sense for me to work on the FSIP and high-level design > over the coming months, so that the GSoC project can focus on implementing > the first increment? > 3. What would be a sensible scope for that first increment? For example, a > basic credit line supporting drawdowns, repayments and available credit. > > > Getting the design right will require considerable research on my part, so > I wanted to get your thoughts on the direction and scope before investing > further in it. > > Thanks, > Abhishek > >
