diff --git a/ExistingProjects.mdwn b/ExistingProjects.mdwn
index 3bb833a78134e0f27e8b0e58a6b31067f565b0d9..6dc2fd8a5ecd26f050e0f755a84cc812b73b96b0 100644
--- a/ExistingProjects.mdwn
+++ b/ExistingProjects.mdwn
@@ -14,7 +14,6 @@ evaluate these projects to the UseCases we've collected so far.
* [[ExistingProjects/Bookyt]]
* [[ExistingProjects/ERP5]]
* [[ExistingProjects/ERPNext]]
-* [[ExistingProjects/Frontaccounting]]
* [[ExistingProjects/Garradin]]
* [[ExistingProjects/GNUEnterprise]]
* [[ExistingProjects/GNUCash]]
@@ -29,3 +28,17 @@ evaluate these projects to the UseCases we've collected so far.
* [[ExistingProjects/SQLLedger]]
* [[ExistingProjects/Tryton]]
* [[ExistingProjects/webERP]]: NOTE: [[Frontaccounting|ExistingProjects/Frontaccounting]] is a fork of webERP.
+
+
+## Projects Rejected
+
+These projects have been evaluated as part of this effort and rejected, both
+for a basis of this project or for any code reuse. A few of the primary
+reasons are given on this page, but the whole evaluation can be read on the
+linked page.
+
+* [[ExistingProjects/Frontaccounting#final-eval]]
+ * Straight PHP with no framework
+ * Data model somewhat messy, accounting not clearly separated.
+ * Only one or two developers.
+ * Workflow not easily configured.
diff --git a/ExistingProjects/Frontaccounting.mdwn b/ExistingProjects/Frontaccounting.mdwn
index a4c92bf8f8399212affe10d590534bdc77afcf62..b4b3621687f9e725b3e6a323fa395bf76f9d99e6 100644
--- a/ExistingProjects/Frontaccounting.mdwn
+++ b/ExistingProjects/Frontaccounting.mdwn
@@ -104,3 +104,40 @@ Again, SQL appears to be the only way to interact with the storage of
double-entry data. Double-entry data does not appear to be segmented away
from the other information.
+### Evaluation of the [[Community Health|UseCases/CommunityHealth]]
+- Is the
+ [[license both determined as Free Software by FSF and OSI-approved|USeCases/CommunityHealth#license-approved]]?
+ Yes, it's GPL'ed.
+- Is the [[license GPL-compatible||UseCases/CommunityHealth#gpl-compatible]]? Yes.
+- Does the project
+ [[require assignment of copyright or a CLA to get code upstreamed|UseCases/CommunityHealth#no-cla-for-profit]]?
+ Doesn't seem to require that.
+- How many
+ [[active developers/companies contribute to the project||USeCases/CommunityHealth#dev-count]]?
+ Likely two, as two developers made 98% of the commits:
+ hg log|egrep '^user'|sort | uniq
+ * If there aren't many, how hard would it be to take over the project if
+ needed? Does not seem that easy given how it's designed.
+- Is there good
+ [[developer documentation|UseCases/CommunityHealth#dev-docs]]?
+ There's a
+ [bit on the wiki](http://frontaccounting.com/fawiki/index.php?n=Devel.Devel)
+ but not much.
+- How easy it to [[engage as a developer with the community|UseCases/CommunityHealth#dev-welcoming]]?
+ [Developers mailing list](http://sourceforge.net/mailarchive/forum.php?forum_name=frontaccounting-fa_list)
+ is barely active.
+
+## Final Evaluation
+
+
+Frontaccounting seems to be a project kept alive by just two people who
+presumably have deployments that are driving their work, but generally, there
+is not much unique about this codebase, and the design doesn't seem to have
+many reusuable components. Converting it for use with non-profits would be
+an uphill battle. While the system clearly works, and is in fact very easy
+to install, it has many assumptions about workflow that are likely specific
+to its current deployments and inappropriate for non-profits.
+
+Finally, The use of straight PHP without a framework, and use of deprecated
+techniques and APIs means that it will be difficult to attract new
+developers.