Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
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.

Once you have Python and Postgres, you can use make to build and launch Gittip:

$ make run

If you don't have make, look at the Makefile to see what steps you need to perform to build and launch Gittip. The Makefile is pretty simple and straightforward.

All Python dependencies (including virtualenv) are bundled with Gittip in the vendor/ directory. Gittip is designed so that you don't manage its virtualenv directly and you don't download its dependencies at build time.


When using make run, Gittip's execution environment is defined in a local.env file, which is not included in the source code repo. If you make run you'll have one generated for you, which you can then tweak as needed. Here's the default:


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

You probably don't need it, but at one point I had to set this to get psycopg2 working on Mac OS with EnterpriseDB's Postgres 9.1 installer:


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.