On Sun, Mar 30, 2025 at 4:42 PM Paul <pchristi...@gmail.com> wrote:
> 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. > My sense is that they don't.. .understand fully the "cost of ownership" that is,... and moreover, near term priorities are more easily solved by having your own code repo, rather than the "unknown" process of contributions. One may start with "I'll just make this one module here, and contribute it later...". and two years later you are 4000 commits out of sync with incompatible changes. > 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. > We've done this a few times, but sure... more is needed. We know only that those that take the code <silently> are unwilling to let us know exactly WHY they are forking. For those that tell us, we get back <customer is concerned about open source> or <our company doesn't have time for your process>, or <we've built new functionality that is our secret sauce, cannot share back, and the other changes are not isolated from that>, or <we don't see any reason to contribute back, why would we?>. > 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. > Right, lack of confidence... the other side of the coin, opposite of "fear of missing out". > > 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 . . . > yep. There is no budget allocation here. Just contributions. Project does not equal the product. https://www.apache.org/theapacheway/ <https://www.apache.org/theapacheway/> > 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 >
