Hi! Fineract-CN hasn't managed to get a community that would actively push it forward. It could happen in the future or it could never happen.
Anyway - rather than changing CN to a radically different direction I would rather advise to gather interested parties together and start from a clean perspective and name it something else - Fineract NS (New Start) or whatever. This doesn't mean it couldn't borrow code from Fineract-CN if needed. Also we have the ability to spin up new apache/fineract-* Github repositories whenever needed. The new start could only work if there is critical mass of interested parties on board from the start and they work together. If there is only one company outsourcing its work (without others having much say what technologies to use etc) then it won't be the apache way to build new software and thus not a very sustainable model. Juhan Kontakt James Dailey (<jamespdai...@gmail.com>) kirjutas kuupƤeval L, 26. september 2020 kell 19:30: > Thanks Saransh for bringing this conversation forward and on-list. I > believe we need more ideas about fineract-CN, and I agree that a key > 'story' is accessibility of the code to developers and avoiding the > monolithic code base trap. > > I'll note that recently fineract 1.4 was released, a major improvement. > That needed our strong focus and is a community success. > > fineract-CN has not yet had the same level of focus, but I believe that > it should. > > It's important that we also have those with fineract CN in production to > help drive the roadmap. There are several and some of those folks have > proposed new directions as well. So, this is an active discussion. > > Previously we discussed on list the importance of the 'minimal set' of > microservices. Can you say whether you have the same list or a smaller > set? Or larger set as the required microservices for a 'release'? > > Or how should we think about composability? > > In terms of your re-architecting ideas, I look forward to learning more. > > @jdailey > > On Fri, Sep 25, 2020, 3:44 AM Saransh Sharma <sara...@muellners.org> > wrote: > >> Hey folks out there , this email is intended for Fineract CN improvement, >> before setting the ground i would like to clear up a few things ; one this >> is not a separate project , this concerns overall change from ground up and >> possible variation of the existing project out there. >> >> Possible scenario >> >> We would like to propose fundamental changes to bring forward >> contribution that has been (if some of us are still wanting to contribute >> please come forward) >> >> Another possible design issue we could not figure out anything at first >> glance. >> >> Developer experience, we would like to contribute back to the community >> the finest development exp. >> >> Architectural change to fit close to the nature of Microservices >> >> I have created a Jira ticket š« let me know if anyone wish to discuss >> this and get it through this >> >> Possible Solution >> >> To get contribution back we need automation at the templating side (We >> would like to share our automated generator experience so far) >> >> Another important thing is the architecture needs to suit the needs of >> the partner and developers to quickly integrate with any services. >> >> Grouping these services from the partners together and making them >> available with existing solutions . >> >> Some Blockers >> Need to evolve from the idea of monolithic to to true Microservices >> approach >> >> Reference >> https://issues.apache.org/jira/browse/FINCN-239 >> -- >> Thanks and regards, >> >> Saransh Sharma >> Research Partner >> >> This mail is governed by MuellnersĀ® IT policy. >> The information contained in this e-mail and any accompanying documents >> may contain information that is confidential or otherwise protected from >> disclosure. If you are not the intended recipient of this message, or if >> this message has been addressed to you in error, please immediately alert >> the sender by reply e-mail and then delete this message, including any >> attachments. Any dissemination, distribution or other use of the contents >> of this message by anyone other than the intended recipient is strictly >> prohibited. All messages sent to and from this e-mail address may be >> monitored as permitted by applicable law and regulations to ensure >> compliance with our internal policies and to protect our business. E-mails >> are not secure and cannot be guaranteed to be error free as they can be >> intercepted, amended, lost or destroyed, or contain viruses. You are deemed >> to have accepted these risks if you communicate with us by e-mail. >> >
