Devs -
I would like to share some thoughts on the development of a Roadmap, and
some proposals:
1. A roadmap is a collective activity to try to anticipate what work can
be done by the community of volunteers and to try to organize our approach
2. In an open source project, a good roadmap includes both what we want
to develop and what parts we do not want to develop (anti-roadmap)
1. Anti-roadmap seeks to avoid feature-creep that muddy the
application
2. Anti-roadmap in an open source project also provides the "missing"
components that vendors can then develop as a deeper solution.
There are a number of companies using Fineract and running it in
production. At Apache Fineract, our goal is to allow for individuals to
make contributions. Those individuals are called "volunteers". Those
volunteers can be paid by their companies to do the development on the open
source project. But, individuals make contributions and work to ensure the
project is ideally developed. If your company is using Fineract but you are
not contributing, please consider why.
My belief is that it is at least partly because it is far easier to hack a
solution for a near term solution than to take the better design approach.
This means that many implementations out there are on heavily customized if
not entirely forked projects. They are unable to contribute upstream
because they are hundreds of commits behind.
This is a problem and our roadmap should be focused on this topic: How to
ensure a virtuous cycle of contribution through code approachability and
extensibility.
In this direction, I call attention to the work around separating the
components into almost "composable" jar files as well as drop in java
classes. These probably need more development and to be highlighted for
devs. @Aleksandar Vidakovic <al...@apache.org> is leading much of this.
To ensure that our development processes and priorities are understandable
we also need to limit the number of open tickets as a first step:
- We are closing old tickets (more than 2 years old) to ensure we are
focussed on the right things and to let go of things we don't need or for
which there is no one to do the development. We may pick a few items from
that list of old tickets.
To ensure that the project quality is enhanced continuously, I think we
need better test coverage across the board. At a minimum as mentioned in
the thread about commits. (Review then Commit), we should not
accept commits without sufficient test coverage.
Proposed priority #1 and #2:
1. Fix the "build on top of" and maintainability of the project ,
enabling outside vendors to stay upstream while giving them flexibility to
do custom code when needed - i.e. create the pattern for that.
2. Fix the testing so that we have "enough" for quality and security
In terms of features and functionality, I have some ideas as well and
suggest we move to a confluence page.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=231117062.
I offer these as a starting point for on list discussion.
Jdailey
