Open source projects need to communicate their vision and do it in a way that brings people together.  I think that includes framing up both WHY you are doing the project, and HOW you are doing the project.  The WHY for Fineract is to enable everyone to have access to financial services on stable, secure and forward looking platforms. The HOW are the many ways in which the project seeks contributions of code by volunteers who have a "scratch to itch".  It is also important to make the project: 

Accessible - as in, understandable to the interested person who wants to Contribute; 

Maintainable - as in, abundantly clear documentation and code such that a new person of reasonable skill is not confused by the approach 

Expandable - as in, flexible in the right ways to allow for new contributions as the needs arise / "extensible" is another word for it perhaps 


When these things are present and the project participants are able to understand its direction how they can get on board, then we can see the virtuous cycle where new contributions are given, the code quality improves, and new users (in our case deployment or implementation companies) use the code and support the developers to continue to do so. 


Today we are trying to do some important improvements to the Fineract platform (fineract1.x) and we are trying to bring Fineract-CN to a full release.  The Fineract1.x releases are improving constantly and it seems that many entities are happy to continue to use it. Fineract-CN needs some finishing to get past the finish line.  Once the Fineract-CN target is ready, then we can proceed with the idea of building a migration path from Fineract1.x to Fineract-CN.  It could be that the migration path and tools are built only once and that fineract1.x becomes a stable but non-active codebase, or, it may be that over time the two code bases will converge in some way.  

It's an exciting time for the project. 

  • No labels