Christopher B. Browne's Home Page
cbbrowne@acm.org

2. Free Software (Gift) Exchange Registry Methodology

2.1. Assumptions

This effort is based on the following set of assumptions (which may not be a complete set, but there you go...):

2.2. Affiliation With Governmental Taxation Systems

It often appears attractive to try to turn these sorts of projects into some form of "registered charity" in order to obtain favorable tax treatment, for contributors, of their contributions.

Unfortunately There Ain't No Such Thing As A Free Lunch is abundantly true, and charity policy is no exception to this principle.

The donors may be nicely treated by the taxation authorities, but this there are two other corresponding costs that occur at other levels:

In contrast, "gifts" may not be tax deductable, but are happily, by the same token, not taxable in the hands of the recipients.

2.3. The Free Software (Gift) Exchange Registry Methodology

The Free Software (Gift) Exchange Registry consists of a registry of the following things:

The two critical things are the lists of developers, and the lists of pledges. Once joined together, people can examine the data to determine that, for example:

People working Linux kernel development might have been pledged $300,000, whilst those working on library development were only pledged $30,000.

Since libraries are important too, people may grasp this fact, and allocate later contributions more intelligently.

2.4. Details of the Database Schema

The database would consist of, roughly speaking, the following groups of data:

2.4.1. People

Anyone may register themself as a contributor.

This will contain address and naming information, as well as whether or not the individual wished to be publicly identified as a contributor. (Some people may prefer not to be known.)

This would also be used to represent identification information for would-be recipients, but more about that later...

2.4.2. Projects/Systems

It still proves useful to list projects. People developing free software tend to be associated with some particular system, whether it be a tool, application, or piece of documentation.

This would include information such as the name of the project, and contact information such as a primary email address and a URL.

It would be logical to set up a view of contributors and contributions based on this table, determining people and amounts associated with each system.

2.4.3. Vouching

This is a very important table from an authorization point of view; it indicates what people are affiliated with projects, and thus appear worthy to receive gifts on behalf of their efforts.

My initial thought is that, in the ancient Hebrew legal traditions, people be considered "vouched for" if there are three witnesses willing to vouch for their address and for their involvement with the project/system in question.

One would hope that this would not be a matter of great contention; I however expect that most of the political problems that would arise would specifically arise in this area.

It would be reasonable for someone to request that contributions go elsewhere. For instance, I would suspect that Richard Stallman might prefer that contributions go to the Free Software Foundation rather than to him directly. Similarly, there might be a lot of people that would wish to express their gratitude to other "celebrities" in the little world that is the free software community; this might prove to provide overwhelming amounts to such luminaries as Linus Torvalds, Eric Raymond, Alan Cox, and others.

An unfortunate aspect of what might be called the "celebrity effect" is that these celebrities are likely to receive a disproportionate portion of funds. There are three salutory counter-effects:

  • These people generally seem fairly responsible, and I expect that it is likely that they would pass on excess monies to destinations that they would consider worthy.

  • These are gifts, and supposing a million people want Linus to be showered in money, it is not his obligation to deny people their desires.

  • Hopefully after making some such "millionaires," people would get some of the worshipfulness out of their systems, and consider more carefully where to send funding in the future so as to get a little utility from their encouragement.

Note that not all recipients will necessarily be programmers as such; people that support free software in other roles such as writing documentation or otherwise providing useful support may be well deserving of reward for their efforts.

2.4.4. Pledges

This would join together people who are contributors with "vouched" recipients. Initially, this table merely indicates a pledge as opposed to a "validated" contribution.

Note that since no money goes to the Free Software (Gift) Exchange Registry, we have no way to directly validate that contributions are actually received. All we have is a voluntary reporting of amounts people are publicly declaring that they intend to give as gifts.

2.4.5. Receipts

This data would be (voluntarily) filled in by recipients of gifts to indicate amounts actually received.

A logical approach would be to allow recipients to "log in" to a web page that would present a list of outstanding pledges that are directed to them. They could then mark off those that had been received, and perhaps indicate amounts received that had not been pledged.

2.5. Major Reports

Several "views" of the data would obviously prove useful:

Google
Contact me at cbbrowne@acm.org