My take on this....

I like the recognition that we need to grow the community, and I like the
realization that we can not support infinite source code with a volunteer
community that does not grow.  I think there are some good kernels of ideas
in this discussion.  In general Pekko could support external development
that may or may not become part of core by providing a page that links to
projects that are extending Pekko but not part of Pekko core.   In this
case the code mongo persistence library would be mentioned on that page.
This gives external projects a chance to develop a supporting community and
show that there is demand for the component.  I also think there is an
opportunity here to invite the mongo persistence developer to come help get
the rest of the modules up to snuff and out the door as released so we can
take the time to consider the mongo persistence module properly.  So in
short, if someone comes with a package give them an opportunity to show
they are committed to Pekko and give them a place to show that there is a
community behind their contribution.

I have to agree with earlier writers in this thread that there is just not
the band width to take on another module at this point in the Pekko
development. cycle.

I also wonder if we should take some sort of poll or have some metric to
determine which of the remaining modules has the most demand/support.  In
my opinion if an existing module (pekko-foo) has lower demand than the
demand for mongo-persistence then I think mongo-persistence should come in
before pekko-foo.  This paragraph all hypothetical because we don't have a
measure of demand/support (that I know of).

So in short, encourage the mongo-persistence developer to join the work to
get core out while evaluating whether there is enough demand/support for
mongo-persistence to include it.

Claude

Reply via email to