Changeset - f7f9ee1bb775
[Not reviewed]
0 2 0
Bradley Kuhn (bkuhn) - 10 years ago 2013-11-15 19:10:00
bkuhn@ebb.org
Final evaluation of front accounting.
2 files changed with 51 insertions and 1 deletions:
0 comments (0 inline, 0 general)
ExistingProjects.mdwn
Show inline comments
...
 
@@ -5,27 +5,40 @@ There are a number of existing accounting projects. Some of these are listed und
 
These projects will be evaluated for suitability and/or adaptability.  We
 
have an [[template you can use|ExistingProjects/EvaluationTemplate]] to
 
evaluate these projects to the UseCases we've collected so far.
 

	
 
## List of projects under evaluation
 

	
 
* [[ExistingProjects/ADempiere]]
 
* [[ApacheOFBiz]]
 
* [[ExistingProjects/BeanBooks]]
 
* [[ExistingProjects/Bookyt]]
 
* [[ExistingProjects/ERP5]]
 
* [[ExistingProjects/ERPNext]]
 
* [[ExistingProjects/Frontaccounting]]
 
* [[ExistingProjects/Garradin]]
 
* [[ExistingProjects/GNUEnterprise]]
 
* [[ExistingProjects/GNUCash]]
 
* [[ExistingProjects/Kuali]]
 
* [[ExistingProjects/Ledger]]
 
* [[ExistingProjects/LedgerSMB]]
 
* [[ExistingProjects/npo-ledger-cli]]
 
* [[ExistingProjects/OpenERP]]
 
* [[ExistingProjects/OpenBravo]] : <http://www.openbravo.com/>
 
* [[ExistingProjects/OpenPetra]]
 
* [[ExistingProjects/Postbooks]]
 
* [[ExistingProjects/SQLLedger]]
 
* [[ExistingProjects/Tryton]]
 
* [[ExistingProjects/webERP]]: <http://www.weberp.org/> 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.
ExistingProjects/Frontaccounting.mdwn
Show inline comments
...
 
@@ -95,12 +95,49 @@ restrict a user to a specific Dimension.
 
Interaction with the data seems to happen with embedded SQL statements
 
intermixed with PHP code.  Thus, writing SQL statements is really the only
 
way to interact with the data, and as such, given that there isn't anything
 
specifically innovative about the data model, this is no better nor worse
 
than most other projects of this nature.
 

	
 
### Evaluation of the [[Storage API|UseCases/StorageAPI]]
 

	
 
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
 
<a id="final-eval"></a>
 

	
 
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.
0 comments (0 inline, 0 general)