Paul -
Basically we try to create breadcrumbs everywhere we can in the project and
build on previous work. (Less homework than context setting ).
And, partly I’m trying to link your framing of the problem with previous or
existing efforts.
Interested in your take on our priorities given your background in product
development.
Keep in mind that one key objective is to try to encourage contributions
while another is to have downstream users that remain on the code such that
they don’t fork the code. Ie if we provide too much functionality out of
the box, it encourages a “take and fork it” approach, unless improvements
including security updates, are coming rapidly.
Thanks
James
On Fri, Mar 28, 2025 at 8:23 AM Paul <pchristi...@gmail.com> wrote:
> Thanks for "homework" links . . . I've been intrigued and loosely
> following Fineract / MIFOS for years . . . and thought I would try to get
> a little deeper into the community participation.
>
> On Fri, Mar 28, 2025 at 9:57 AM James Dailey <jdai...@apache.org> wrote:
>
>> 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
>>>
>>
>
> --
> --
> Paul
>
