As a quick disclaimer, I am the primary developer of REMITT, so I may be slightly biased ...

The reasons that are given here regarding REMITT and its unsuitability are not valid, and here is a point-by-point reasoning of this:

1. Remitt is also written in Perl.

But the actual code that performs the action of transforming and transmitting the billing data is programming language agnostic. It is completely possibly to rewrite REMITT in C/C++ or something else ... The only reason Perl was used was its excellent PDF rendering libraries and support for XML-RPC using SOAP::Lite. I wouldn't consider this anywhere near as much a liability as FreeB's dependence on Perl, since it is so intrinsically tied to the language for all of its processing. All of REMITT's actual processing is performed by the Perl interface to libxslt, and is completely customizable using simple XSL tranformations.

2. Remitt has a complex format system.

REMITT uses a W3C standard (XSL), and a simple monolithic XML format with XPath to traverse the object model. It requires no actual coding skill to create and/or modify formats, just XSL skills. This is far superior to the meta-compiled format that FreeB currently uses, which is an XML descriptor format, but which requires Perl coding knowledge to actually modify the guts of the processing routines. It's also non-trivial to add additional rendering types, since the looping involved can vary wildly from the implemented Perl code.

3. Patent Cloud/Licensing Issues

This is a non-issue, as referenced on http://remitt.org/license.html ... there is an open license for any opensource project to use REMITT. Of course, since it's an XML-RPC application server, the only parts that would need to be changed would be the XSL sheets, which are under the straight GPL; everything else is seperate, as it is simply an implementation of the XML-RPC API as a client, much as FreeB's client code is.

Please feel free to email me.

Jeff
FreeMED MA, Inc
http://freemedma.com/
(freemed@gmail.com)