One of the potential uses of the tipjar technology is to facilitate bounties for open source projects.

Bounties are generally offered by someone, the "sponsor," who wants to see a feature added or a problem fixed, and offers so much money to be paid to whoever delivers the feature or repair.  Bounties are generally managed in association with particular projects, although recently more than one independent bounty clearinghouse has appeared.

Occasionally, as now occurs with the Vienna.pm "winter of code" initiative, or as happened with the "linux fund" while that was operating, a third party is in  a position to give grants to implementors who deliver on tasks defined by an entity who is not offering the bounty directly, therefore dividing the sponsor role in two:  the "funding sponsor" and the "requirements sponsor."

Vienna.pm has offered (December, 2007) a bounty for  delivering a bounty management  system, and tipjar LLC intends to whip something together to satisfy their requirements.

Rather than directly referring to Vienna.pm, Vienna.pm may appear in the system in the well-defined role of  funding sponsor, while the people described in their RFP as "project managers" will be "requirements sponsors."

In the TJDSBF (TipJar Dual-Sponsored Bounty Framework) there are five defined roles, including "everyone" who is a "NPI (non-participating individual)"

FA (framework administrator) does these things:
  1. provide a working system
  2. provide minimal accounts system plus integration to external SSO (single sign-on) such as bitcard
  3. provide skeleton templates
  4. approve/deny instance applications from funding sponsors
  5. facilitate modification of templates provided by FS (funding sponsor)
  6. maintenance as needed
FS (Funding sponsor) does these things:
  1. requests a TJDSBF  instance, describing self, and listing contact information.
  2. modify templates
  3. approve/deny listing applications from RS (requirements sponsors)
  4. disburse on project completion as determined by RS, mark PL as paid
RS (Requirements sponsor) does these things:
  1. requests a PL (project listing), including description of the project, reccommended grant amount, and expected completion timeframe
  2. respond to clarification requests, either directly or by adding notes to PL
  3. approve/deny reserving proposals from IMP (implementors)
  4. verify completion claims
IMP (implementor) does these things:
  1. request clarifications from RS
  2. request project assignment by submitting proposal for approval by RS
  3. implement (not done directly on the DSBF -- ha ha)
  4. claim completion
  5. receive payment (not done directly on DSBF initial release)
NPI (non-participating individuals) do these things:
  1. browse published project listings with reservation status
  2. request clarifications from RS
  3. share links to listed projects with potential IMP

Stages in the life of a PL (project listing)
  1. PL comes into being when a RS makes a listing request (PRELIST)
  2. FS communicates with RS to verify and clarify PL
  3. FS approves PL
  4. PL is listed (LISTED)
  5. IMP proposes to RS that he will work on PL
  6. RS reserves PL for IMP (RESERVED)
  7. IMP reports completion claim (CLAIMED)
  8. RS approves completion claim (COMPLETED)
  9. FS pays IMP
  10. FS marks PL as PAID
  11. FS deletes PL
the FS is the final authority on what projects are listed on their instance.

become a funding sponsor