shared API for double-entry accounting, treating it as a 'math' library.

[Daniel Pocock]

On 15/11/13 17:48, Bradley M. Kuhn wrote:

> As we've been doing these codebase evals, I continually come back to the
> conclusion that everyone who has approached this problem in the Free
> Software community (including us!)  had a small-scale, niche market in
> mind.  Ours at the moment is non-profits -- and in particular fund-based
> fiscal sponsorship accounting with 30 or more (up to a thousand, I
> suspect, when we consider an org like Fractured Atlas) pools of
> temporarily restricted assets.
> 
> We basically have two choices of approach to this situation (and I don't
> think this is a false dichotomy but if it is, let me know):
> 
>   (a) We can do the same that everyone else did: start a project, and/or
>       bend an existing codebase, to address our niche, and have yet
>       another specialized version of one of the existing accounting
>       systems, or
> 
>   (b) try to build a toolkit useful in the creation of small business
>       accounting applications (and reusing code from whereever seems
>       prudent, when that code is flexible enough to be adapted into a
>       toolkit).

It is not just about code though.

It is also worth considering some other angles:

- Somebody goes to school to learn book-keeping or accounting, usually
before they really know whether they will work for a small business, a
fund or NPO or whatever.  What system does the school teach with?  What
can they install at home to practice and improve their skills?  Which
free software projects could try to fill this gap?  Getting in at the
education stage is a very powerful way to raise the profile of free
software for financial purposes across the board.

- as mentioned in my other email, how can products interact, e.g. using
cXML or something else to exchange invoices?

- internationalization: many products have a focus on their local
market, e.g. Postbooks is strong for the US and European users have to
set up VAT codes manually.  Commercial vendors (e.g. Quickbooks) are
putting out products that work out of the box for local conditions (e.g.
automatically loading VAT codes in the UK, Australia, Canada and various
other places).  It is not really a question of language and date
formats, rather, it is about building up a collection of static data
such as tax rates and currency symbols.  Can this type of data be
gathered into a shared database that can be leveraged by all of the free
software solutions who want to provide plug-and-play support for
locales?  It would be silly for every free project to try and duplicate
this themselves.

- industry associations: the financial profession and the NPO sector
have various industry associations, could they be encouraged to
participate in this effort, maybe forming an advisory board?  Could this
even help to find funding opportunities?

- what we use ourselves: many free software developers and enthusiasts
are self-employed.  Many of us tend to patch and improve the software
that we use ourselves every day and so we get to know if very well.  The
same is true for financial software: if we can rally a lot of people
around a single product or a small group of products that they can use
for themselves, they will end up promoting those to other professionals
and businesses as well and it will gain further momentum.  If the
products in this pool are flexible and scalable enough then it meets a
diverse range of business requirements and that means more free software
enthusiasts are employed more of the time and there is a nice snowball
effect.