Perspective is everything . . . I'm sure mine is very different with 90%
of my background in closed source.
My thoughts on Forking:
If the end user understands the "cost of ownership", forking is the last
thing they WANT to do.
It would probably be worth a brainstorming session followed member driven
research to determine where / what the dominant trigger points are that
might drive a Fork issue.
Customization in the closed source world is a near equal experience as
Forking in the open source one. I've notice over my career, customization
is driven more often from a "lack of confidence" in the future and more
often by the current cadence of the base product feature adaptation . . .
rarely is it about a genuine need to go a totally different direction.
My perspective is 90% closed sourced experience and only light personal
observation of open source behavior . . .
My Day to day is on the other end of the spectrum working with large banks
and lenders. Typically in the top 150 size and volume-wise, it's amazing
how similar pain points are to what I "think" I see here. Can easily see
where Open Source projects take a LOT more finase skill to manage than
closed projects . . .
Happy to learn more and share where its useful.
Regards
Paul
On Sun, Mar 30, 2025 at 4:49 PM James Dailey <jdai...@apache.org> wrote:
> 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
>>
>
--
--
Paul
