npo-accounting-ikiwiki/GSoC2014Ideas.mdwn

Google Summer of Code 2014 Ideas
================================

Welcome, potential Google Summer of Code students!  This project is
currently called "The NPO Accounting Project", for lack of a better name.

The project is coordinated by
[Software Freedom Conservancy, Inc.](https://sfconservancy.org/) which is a
501(c)(3) charitable not-for-profit organization in the USA.  We run all our
operations solely and completely on Free Software.

One area that we've had great difficulty is regarding non-profit accounting
software.  We've launch this project to improve the state of accounting Open
Source and Free Software for non-profits.  Since this NPO Accounting project
is just getting started, there are only the five potential projects below
for a GSoC 2014 student.  Students who wish to apply to our org should pick
one specific project below, and focus their application on that project.

We'll likely select just one (and at most two) students, but we've provided
multiple project choices.  Students who wish to apply to our org should pick
*one* of the five projects below, and focus their application on that
project.

We need all of these items below done anyway, and we want to find the best
possible student/project match.  Please pick the *single* project below that
fits your skills and background best when submitting your application.

## Possible GSoC 2014 Projects

1. Add all the necessary tag types found in 
   [the tutorial on the Ledger-CLI setup for fiscal sponsor 501(c)3 organizations](https://gitorious.org/ledger/npo-ledger-cli/)
   into the
   [REST API for basic double-entry accounting](http://npoacct.sfconservancy.org/accounting-api/),
   and then write some reports using that new API.
 
   This will require the student to get familiar (or already be familiar)
   with how Ledger-CLI works, how REST APIs work, and learn some basics of
   double entry accounting.

    A successful student should be able to complete that work about
    three-quarters the way through the summer, and then be able to focus on
    actually writing a few specialized NPO-style report using the API.  A
    great acid test will be to use the API to implement the
    [IRS required charity public support test](http://www.irs.gov/Charities-&-Non-Profits/Exempt-Organizations-Annual-Reporting-Requirements-Form-990,-Schedules-A-and-B:-Public-Charity-Support-Test).

   This particular project description is vague because we'd like to see a
   creative application from someone who has done some research into how
   non-profit accounting workflow works and wants to help implement it.

2. Convert  [Ledger-CLI](http://www.ledger-cli.org/) to use fixed-point
   arithmetic.

   Currently Ledger-CLI uses floating point arithmetic, which is definitely a
   mistake for an accounting system.  This causes
   [off-by-one bugs](http://bugs.ledger-cli.org/show_bug.cgi?id=992) on some
   types of transactions.  This should be fixed.

   A successful student on this task will:
      * Write various test cases for Ledger-CLI that will clearly show the
        floating point issue.
      * Rework the codebase to use fixed-point arithmetic so those bugs are
        closed.
      * Shepherd the patch upstream.
      * Close any bug tickets in the bug tracker that relate to this issue.
      * Time permitting: verify that other Ledger implementations don't
        face the same problem.

   Note that because this would be a major "bombing run" sort of change,
   there may be some resistance to upstreaming this patch, so this task may
   be harder than it looks on the surface from a community advocacy angle.  

   Application tips for this task: an application from a student who does the
   following will be considered a very good application:
      * Write a patch (before submitting your application) for ledger-cli
        that uses the existing test framework to add a useful new test.
      * Submit a pull request to ledger-cli to add that test to upstream.
      * If your patch is accepted by ledger-cli's maintainers before your
        application is considered, that will be looked upon most favorably.
      
3. Build a better test suite for [Ledger-CLI](http://www.ledger-cli.org/).

   Since this project relies so heavily on Ledger-CLI, we'd really like there
   to be a full test coverage for Ledger-CLI.  To do that, a student will
   need to be already somewhat familiar C++ and willing to learn about how to
   set up test suites for C++ programs, and likes writing tests.  The student
   could easily spend the whole summer just writing tests and not finish.

    Ledger-CLI does have a basic test suite, but it might turn out that using
    a more "full featured" test harness is useful.  The student will
    investigate and discuss this possibility with the mentor.  It would also
    be nice if lcov or other test-coverage tool could generate reports
    automatically.
    
    While this project is of primary interest to this project, it will
    require careful coordination with Ledger-CLI as an upstream, and we'll
    help mentor the student in that.
      
4. Build a better Python interface to Ledger-CLI for use by our API.

   Right now, Ledger-CLI has a rather incomplete Python interface, based on
   [Boost.Python](http://www.boost.org/doc/libs/1_55_0/libs/python/doc/).
   However, the right approach is probably to use
   [SWIG](http://www.swig.org/) or some other similar mechanism to build a
   proper Python API.  Perhaps Ledger-CLI could stick with Boost.Python, but
   what's there clearly needs an overhaul.  The upside of using SWIG will be
   that we can get APIs for other languages too. 

   While this project is of primary interest to this project, it will require
   careful coordination with Ledger-CLI as an upstream, and we'll help mentor
   the student in that.

5. Add a JSON/RESTful API to [Hledger](http://hledger.org)'s
    [hledger-web](http://hackage.haskell.org/package/hledger-web) app,
    mirroring the C++/python API (improvement for which is described in (1)
    above, as part of another task).  This would provide an alternate
    implementation useful for testing, validation and future-proofing.

    The ideal here would be that the NPO Accounting Project could use
    *either* Ledger-CLI *or* hledger as a back-end.  This work may require
    coordination with other students who might be working on (1).