In a recent issue, Chris proposed to factor out part of the code base into
a stand-alone CPAN release (which would IMO mean into a more-or-less stand
alone project). The same happened some years ago when he factored out
DBObject into PGObject, so, we have precedence here. The other way around
(refactored our code to use releases from CPAN) has happened as well.
From my perspective, the reasons to refactor our code
to make use of
(pre-existing) CPAN code are clear:
* Using pre-existing code from CPAN outsources maintenance (to an external
* Opens up opportunities for wider use in our own code base, because
usually replaces specific with generic code
* Ensures better testing of code in a wide variety of settings (hopefully
* Improves code-sharing in the wider Perl community (hopefully free-ing up
resources to take Perl and its modules a step further)
To me, the other way around would roughly work the same way. Meaning, that
we should be thinking about placing our code on CPAN, if:
* Our code is sufficiently generic to solve problems for others
* Others can depend on us to do the maintenance of the code
* Our code comes with sufficient quality assurance measures to be helpful
* Our code is sufficiently stable not to require large refactorings to the
projects (which would mean that people can't really depend on the code -
Especially the last point - I think - is tricky: when largish refactorings
are in order, the fact that part of the code being refactored is loaded
onto Travis CI through CPAN is a major limitation on the speed that can be
had during the refactoring. The recent PGObject 1.x->PGObject 2.x
refactoring showed that.
I'm wondering: Is there anything else to be considered? (Reasons to factor
out, problems to be met after having separated, etc...)
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.