Skip to content
Gittip is a platform for sustainable crowd-funding.
Python JavaScript Shell
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.

This is Gittip, a platform for personal funding.

Gittip is a cooperative escrow agent for recurring micro-gifts, or gift tips. Possible tip amounts per week are 0.00, 1.00, 3.00, 6.00, 12.00, and 24.00.

Friday is payday. On Friday, we charge people's credit cards and the money goes into Gittip's (Zeta Design & Development, LLC's) bank account. Money is allocated to other participants according to tips. Participants may withdraw money at any time, though this is currently quite manual.


The site is built with Python 2.7 and the Aspen web framework, and is hosted on Heroku. Balanced is used for credit card processing, and Google for analytics.

You need python2.7 on your PATH.

You need Postgres with headers installed. There's a simple Makefile for building the software. All Python dependencies are included in vendor/. To make run you need a local.env file in the distribution root with these keys:


The BALANCED_API_SECRET is a test marketplace. To generate a new secret for your own testing run this command:

curl -X POST | grep secret

Grab that secret and also create a new marketplace to test against:

curl -X POST -u <your_secret>:

The site works without this, except for the credit card page. Visit the Balanced Documentation if you want to know more about creating marketplaces.

The GITHUB_* keys are for a gittip-dev application in the Gittip organization on Github. It points back to localhost:8537, which is where Gittip will be running if you start it locally with make run. Similarly with the TWITTER_* keys, but there they required us to spell it

The DYLD_LIBRARY_PATH thing is to get psycopg2 working on Mac OS with EnterpriseDB's Postgres 9.1 installer. You might not need it.

Setting up the Database

Install PostgreSQL. The best version to use is 9.1, because Gittip uses the hstore extension for unstructured data, and that isn't bundled with earlier versions. If you're on a Mac, maybe try out Heroku's

Add a "role" (Postgres user) that matches your OS username. Make sure it's a superuser role and has login privileges. Here's a sample invocation of the createuser executable that comes with Postgres that will do this for you, assuming that a "postgres" superuser was already created as part of initial installation:

$ createuser --username postgres --superuser $USER 

It's also convenient to set the authentication method to "trust" in pg_hba.conf for local connections, so you don't have to enter a password all the time. Reload Postgres using pg_ctl for this to take effect.

Once Postgres is set up, run:

$ ./

That will create a new gittip superuser and a gittip database (with UTC as the default timezone), populated with structure from ./schema.sql. To change the name of the database and/or user, pass them on the command line:

$ ./ mygittip myuser

If you only pass one argument it will be used for both dbname and owner role:

$ ./ gittip-test

The schema for the database is defined in schema.sql. It should be considered append-only. The idea is that this is the log of DDL that we've run against the production database. You should never change commands that have already been run. New DDL will be (manually) run against the production database as part of deployment.

Testing Testing

Please write unit tests for all new code and all code you change. Gittip's test suite is designed for the nosetests test runner (maybe it also works with py.test?), and uses module-level test functions, with a context manager for managing testing state. Please don't use test classes. As a rule of thumb, each test case should perform one assertion. For a guided intro to Gittip's test suite, check out tests/

Assuming you have make, the easiest way to run the test suite is:

$ make test

However, the test suite deletes data in all tables in the public schema of the database configured in your testing environment, and as a safety precaution, we require the following key and value to be set in said environment:

YES_PLEASE_DELETE_ALL_MY_DATA_VERY_OFTEN=Pretty please, with sugar on top.

make test will not set this for you. Run make tests/env and then edit that file and manually add that key=value, then make test will work. Even just importing the gittip.testing module will trigger deletion of all data. Without this safety precaution, an attacker could try sneaking import gittip.testing into a commit. Once their changeset was deployed, we would have ... problems. Of course, they could also remove the check in the same or even a different commit. Of course, they could also sneak in whatever the heck code they wanted to try to sneak in.

To invoke nosetests directly you should use the swaddle utility that comes with Aspen. First make tests/env, edit it as noted above, and then:

[gittip] $ cd tests/
[gittip] $ swaddle env ../env/bin/nosetests

See Also

Something went wrong with that request. Please try again.