If the organization is committed to open source, modify it and send it back to the community as PR, best practices and debate will go to the source code itself. By experience if you go to implement a new big feature or vice versa a small change, anyone in the community will implement it and then the code in the source code could be refactored leaving your code with conflicts or hard to upgrade, i.e. today morning someone was facing an issue about the MySQL/MariaDB database creation and now the PR is ready to be reviewed/merged. For sure it is better to send back the changes and receive feedback as soon as possible.
If your organization has a lot of FTE working on new features, changes, improvements in your fork/branch... the same proportional effort (most of the time, effort is measured in hours) will be invested to do the merge/upgrade to a new Apache Fineract release. If there are intellectual property reasons or limitations by a regulator or authority then... create a plugin or another external microservice without touching the code base. I have written a lot of "if" because of a lack of details about the roadmap of your implementation. You can look at https://www.apache.org/theapacheway/ El mar, 10 ene 2023 a las 21:27, Shashwat Srivastava (<[email protected]>) escribió: > Hi everyone, > > I have been going through the Fineract codebase for our organization > recently. And I had a fundamental question. If I want to customise specific > behaviour, for instance, add a new allocation priority order or change how > the repayment schedule is generated. Is there a recommended way of doing > such customisations to ensure that you don't modify the original codebase? > Is there any documentation around this? Please share. > > Cheers, > Shashwat > >
