Hi Paul. - Welcome.
You raised important points that go beyond this discussion about MCP and I
think we would have this thread.
There is an internal debate, longstanding, as to the product vision. I see
the debate as between "provide everything" and "provide just an essential
common core". Fineract is one of the "highest in the stack" open source
projects you'll find - not underlying tech but significant
END-user-interaction logic, which makes this complex.
We haven't had a Product Roadmap call in over two years, so perhaps now is
a prime moment to get that going. Zoom call ? You can find some of our
deliberations on the listserv archive {search "roadmap") at
https://lists.apache.org/list?dev@fineract.apache.org:gte=1d:roadmap
and
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=231117062
You can also find it in our Fineract Significant Improvement Projects
(FSIPs) which is a sort of "apache software norm" i.e. a pattern for
project development prioritization.
https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Significant+Improvement+Proposals
Someone proposes an area of work, if it is significant enough that it
could impact downstream users we have a full discussion and hold a vote to
approve the direction.
To get a sense of the community and some roadmap achievements, you may also
want to peruse the Quarterly reports to the Board of Apache Software
Foundation. (ASF).
https://cwiki.apache.org/confluence/display/FINERACT/Fineract+PMC+Reports+to+Apache+Software+Foundation+%28ASF%29+Board
The challenge is often in understanding/recognizing/promoting/influencing
what the community wants and what the community is willing to work on -
open source as a "Bazaar" not a "Cathedral" - basically, if you contribute
it, then it gets done. If not, then, nice idea. And, to add to the
complexity, the software is in production in several financial institutions
and it is important that the code remains sufficiently well tested and free
from defects.
I would welcome more discussion on this and your points about the
self-service data access model.
Thanks,
James Dailey
PMC Member and Current Chair
On Fri, Mar 28, 2025 at 2:07 AM Paul <pchristi...@gmail.com> wrote:
> To clarify, it appears Victor's queries around MCP isn't about replacing
> Postgre. Instead, it's about providing robust, documented API connectivity
> – a need that directly aligns my desire for improved 'self-service'
> capabilities. MCP's abstract database complexities present data in an
> LLM-digestible format leveraging APIs. (The same fundamental requirement by
> dozens of others); Accessible, user-friendly API interfaces, not raw
> backend exposure.
>
> From a business standpoint, the current state of documentation
> significantly hinders Fineract's potential for wider adoption and organic
> growth beyond the immediate community. Enabling wider adoption can rapidly
> amplify Fineract's functionality and innovation, while allowing the core
> community to maintain its focus on stability and accessibility.
>
> Legacy systems, whether open or closed source struggle with the challenge
> on innovation versus technical deficiencies. It's difficult, complex and
> requires intent plus a lot of cooperation to cure.
>
> While I don't possess coding skills, I deeply admire those who can
> efficiently resolve technical issues. Adam and others have been crushing
> issues. The 'theory nerd' in me ponders the value added if accumulated
> efforts are strategically focused. I strongly encourage formulating process
> to accept and prioritize work, grounded in a mutually agreed and understood
> product vision. I see "how" discussion is ongoing on the topic.
>
> Consider a simple framework for leveraging product vision in
> prioritization:
>
> 1. *Establish and Communicate a Clear Product Vision:* Ensure the
> vision is well-defined, accepted, and understood by all contributors.
> 2. *Implement a Standardized Decision-Making Process:* Develop a
> simple, consistent method to evaluate product suggestions, yielding a clear
> 'yes' or 'no' accepting work based on alignment with the vision.
> 3. *Define Effort Allocation Targets:* Leadership / community should
> agree on percentage-based goals for addressing technical debt (ensuring
> existing stable functionality, relevance, and documentation) versus
> pursuing innovation.
> 4. *Define Innovation:* Innovation should be carefully defined.
> Conversely, investing in a stable, bug-free, and well-documented core will
> empower external contributions, accelerating genuine, agile innovation.
>
> *In essence, by prioritizing API accessibility, curing documentation gaps,
> and adhering to a clear product vision, Fineract can achieve both stability
> and accelerated growth through increased contributions.*
>
> Regards
>
> On Fri, Mar 28, 2025 at 1:37 AM Naphlin Peter <starna...@gmail.com> wrote:
>
>> Hi Victor,
>>
>> I have read the write up you have shared on Apache Doris, how would this
>> be different from for example using a generic postgres or mysql MCP server
>> that are already available and open?
>>
>> Regards,
>>
>> Naphlin Peter Akena,
>> Kampala,
>> Uganda
>>
>> tel:+256777110054
>> skype: *napho.peter*
>>
>>
>> On Thu, Mar 27, 2025 at 11:02 PM VICTOR MANUEL ROMERO RODRIGUEZ <
>> victor.rom...@fintecheando.mx> wrote:
>>
>>> Hello Apache Fineract Community,
>>>
>>> Question:
>>>
>>> Is there any interest in the Apache Fineract Community to integrate a
>>> MCP Server ?
>>>
>>> There are other Apache Projects that are integrating this feature, i.e
>>> Apache Doris.
>>>
>>> https://www.linkedin.com/pulse/apache-doris-mcp-server-mingyu-chen-4k95c/
>>>
>>> We have already made it por specific use cases like KCY and Loan
>>> origination.
>>>
>>> But it could be useful if all the Apache Fineract APIs could be mapped.
>>>
>>> The MCP implementation tasks could be easier if we could have OpenApi
>>> (swagger) updated and well documented and maybe this is the first step for
>>> the MCP tool.
>>>
>>> I will be glad to hear your thoughts on this matter.
>>>
>>> Regards
>>>
>>> Victor Romero
>>>
>>
>
> --
> --
> Paul
>
