Hi Arnold, no, it is exactly the opposite - the bigger impact the better.
Since fineract might require a huge volume of data and the transactions might be time-sensitive, it is a perfect project to show our expertise. This is why I am asking for a real challenge, not a few outdated tickets. Regarding a minimal effort focusing on quick gains - I've been selected Star Contributor of the Month for January 2010 (more than 15 years ago) in Mifos (predecessor of Fineract) and I am still supporting many open source projects since then. Arnold, are you aware of any real business problem that can be addressed in Fineract? Regards, Jakub. On Fri, Apr 4, 2025 at 9:58 AM Arnold Galovics <arn...@apache.org> wrote: > Hi Jakub, > > May I ask why you chose Fineract for this? I feel like you just wanna get > through this with as minimal effort as possible so that you can make a case > study out of it without making any real impact on Fineract - and I hope you > don't get offended by this because it wasn't meant to be. > > Best, > Arnold > > On Fri, Apr 4, 2025 at 9:07 AM Jakub Sławiński > <jslawin...@soldevelo.com.invalid> wrote: > >> Hi James, >> >> I think I was not clear enough in the previous email, maybe due to the >> list's moderator that is blocking links. >> >> The success case I am looking for is exactly about focusing on one >> perspective - the most painful performance related problem you have. >> >> Please take a look at the other cases we have published: >> - Not every optimization takes months: openIMIS performance improved by >> over 95% in just one week! >> - Not every optimization takes months: How we boosted a key API endpoint >> by 56% in just one week >> - How we improved OpenLMIS import performance by over 90% >> >> I would like to have one more about Fineract. >> >> Are you able to identify such a place? >> >> >> Regards, >> Jakub. >> >> On Fri, Apr 4, 2025 at 2:14 AM James Dailey <jdai...@apache.org> wrote: >> >>> Jakub - Thanks for sharing the perspective. >>> >>> I think the challenge is that from a project perspective, having another >>> audit is useful but doesn't actually advance the project if we don't have >>> the follow up. It is a form of contribution, so I am supportive of it.... >>> but ... >>> >>> With a number of people looking at the code and project and identifying >>> a myriad of issues over a long period of time, it's pretty clear that >>> identifying more issues isn't the solution. >>> >>> What might be useful is to run a code "audit" and focus on one >>> perspective - such as making the code more maintainable and approachable. >>> The "performance" gain we need is speed of developer onboarding, test >>> environments, speed of builds. It could be a good baseline audit, and >>> could focus attention on an important area of improvement which could then >>> speed up addressing other issues. >>> >>> Also, any "audit" results may result in some security issue >>> identification - so please follow best practice and send those to >>> <security AT fineract.apache.org> private list. >>> >>> Thanks, >>> James >>> PMC >>> >>> >>> >>> On Thu, Apr 3, 2025 at 12:24 PM Jakub Sławiński >>> <jslawin...@soldevelo.com.invalid> wrote: >>> >>>> >>>> Hi, >>>> >>>> Unfortunately, it is not what I am looking for. >>>> The set of old issues from the backlog, general areas for improvement >>>> or challenges older than a decade - these do not sound like something >>>> important or valuable to anyone. >>>> >>>> I think I haven't shared the bigger context with the community. >>>> >>>> What we are looking for is to get one more success case for the service >>>> we are currently tuning up: Java Performance Scalability Audit >>>> >>>> What business problems are we targeting? For example: >>>> 🚀 *Performance-Related Issues* >>>> >>>> 1. >>>> >>>> *Slow Application Response Times* – Users experience delays, >>>> leading to frustration and lost engagement. >>>> 2. >>>> >>>> *High Server Costs Due to Inefficiencies* – Unoptimized code leads >>>> to excessive resource consumption, increasing infrastructure expenses. >>>> 3. >>>> >>>> *Frequent System Crashes or Downtime* – Poor memory management, >>>> threading issues, or resource leaks causing instability. >>>> 4. >>>> >>>> *Unoptimized Database Queries* – Slow or inefficient database >>>> operations causing bottlenecks. >>>> 5. >>>> >>>> *Poor User Experience (UX) Due to Lag* – Slow interactions drive >>>> users away and harm customer retention. >>>> >>>> 📈 *Scalability Challenges* >>>> >>>> 6. >>>> >>>> *Inability to Handle Increasing User Load* – System struggles with >>>> growth, leading to degraded performance. >>>> 7. >>>> >>>> *Lack of Proper Load Balancing and Caching* – Inefficient resource >>>> distribution leading to slow responses under load. >>>> 8. >>>> >>>> *Unscalable Architecture* – Design flaws preventing efficient >>>> horizontal or vertical scaling. >>>> 9. >>>> >>>> *Microservices Bottlenecks* – Inter-service communication issues >>>> causing slowdowns or failures. >>>> 10. >>>> >>>> *High Latency in Distributed Systems* – Delays in API responses, >>>> messaging queues, or inter-service communication. >>>> >>>> 🔍 *Technical Debt & Code Maintainability* >>>> >>>> 11. >>>> >>>> *Legacy Code with Performance Bottlenecks* – Old, unoptimized code >>>> making enhancements difficult. >>>> 12. >>>> >>>> *Lack of Monitoring and Profiling* – No visibility into performance >>>> issues until they cause failures. >>>> 13. >>>> >>>> *Memory Leaks and Inefficient Garbage Collection* – Leading to >>>> crashes and sluggish performance over time. >>>> 14. >>>> >>>> *Threading and Concurrency Issues* – Poor multi-threading >>>> implementations causing deadlocks or slow execution. >>>> 15. >>>> >>>> *Security Risks Due to Inefficient Code* – Performance weaknesses >>>> that also expose vulnerabilities. >>>> >>>> 💰 *Business Impact & Cost Reduction* >>>> >>>> 16. >>>> >>>> *Lost Revenue Due to Performance Issues* – Sluggish applications >>>> reduce conversion rates and customer trust. >>>> 17. >>>> >>>> *Missed SLAs (Service Level Agreements)* – Performance problems >>>> leading to contractual penalties or lost clients. >>>> 18. >>>> >>>> *Unnecessary Infrastructure Scaling* – Overprovisioning cloud >>>> resources instead of optimizing code. >>>> 19. >>>> >>>> *Poor DevOps Efficiency* – Developers wasting time troubleshooting >>>> performance instead of building new features. >>>> 20. >>>> >>>> *Long Release Cycles Due to Performance Issues* – Slow debugging >>>> and testing caused by unoptimized code. >>>> >>>> >>>> >>>> What would I like to see as the results of this particular success >>>> story? For example: >>>> >>>> 1. Cut infrastructure costs by 50%. >>>> 2. Increase the number of clients/transactions handled in a stable >>>> manner without changing infrastructure by 100%. >>>> 3. Decrease the time needed by critical operations by 70%. >>>> >>>> What do you think? Are there any business problems we could help you >>>> with? >>>> >>>> Please contact me directly if you are ready to check our services. >>>> >>>> >>>> Regards, >>>> Jakub. >>>> >>>> >>>> -- >>>> >>>> *Jakub Sławiński* >>>> Chief Technical Officer >>>> jslawin...@soldevelo.com / +48 514 780 384 >>>> >>>> >>>> *SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com >>>> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland >>>> Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41 >>>> >>> >> >> -- >> >> *Jakub Sławiński* >> Chief Technical Officer >> jslawin...@soldevelo.com / +48 514 780 384 >> >> >> *SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com >> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland >> Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41 >> > -- *Jakub Sławiński* Chief Technical Officer jslawin...@soldevelo.com / +48 514 780 384 -- * SolDevelo* Sp. z o.o. [LLC] / www.soldevelo.com <http://www.soldevelo.com> Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41
