Home Public Register Contact Help Source Code
The Galt Escrow Agency system is a powerful and flexible tool to manage contracts for software development and other services. It gives developers a strong financial incentive to produce quality software on time. The system includes an elaborate facility for arbitrating disputes, and it enforces the arbitrator's decision automatically and immediately.
Under the Galt Escrow Agency system, if you enter into a development contract as seller, you won't receive a salary. You won't be paid by the hour. Instead, your income will be tied to your performance under the contract. The system will keep track of when you deliver the first working version of the software, how many bugs are found, how quickly you fix them and when you achieve stability. All of this information will figure into how much you get paid. If your performance is poor enough, you'll actually have to pay the buyer, instead of the buyer paying you.
Below is a sample chart showing how the remuneration for delivery of the first version varies over time, under a hypothetical development contract.
In this example, the developer estimates he will deliver on April 17, and in that case, his remuneration will be 18 troy ounces of e-gold. If he is early, he will get a bonus of 0.25 ounces per day that he is early, up to 8 days. If he is late, he will be penalized 2.5 ounces per day that he is late, again up to 8 days. If he has not delivered by April 25, he will actually have to pay the buyer 2 ounces.
The delivery remuneration is just one component of the developer's income. There is also a penalty for each bug found, scaled according to severity. The contract is over when the developer achieves stability, i.e., where all known bugs have been fixed, and a certain number of days have gone by with no new bugs found. The remuneration for stability depends on when stability is achieved, according to a chart similar to the one for delivery.
This policy of tying income to performance motivates developers to do good work. But it also has a screening effect. Those who don't have what it takes to get the job done will tend not to enter into the contract in the first place.
Either party to a contract may request arbitration to resolve a dispute, such as whether something is a bug. When drawing up the contract, the parties may specify a list of arbitrators in order of preference. In this case, when arbitration is requested, the system will choose the first available arbitrator from the list. Otherwise, a default arbitrator will be chosen.
An arbitrator is just another user of the system, like a buyer or a seller. Almost anyone can be an arbitrator. There are no plans for any centralized directory or ranking of arbitrators. Thus, when choosing a list of arbitrators in advance, the parties will need to decide in their own way who is qualified to arbitrate a dispute.
The system holds deposits from both parties, so that it can enforce the terms of the contract. The funds deposited by the buyer are escrow funds in the usual sense, while those deposited by the seller constitute a performance bond.
There is no actual company called the Galt Escrow Agency. Rather, each installation of the system is a Galt Escrow Agency, whose administrator is the escrow agent.
Someone wanting to be an escrow agent will need to create an e-gold account, and then install the system on a suitable web server. If users will be expecting default arbitrators, the escrow agent will need to find some qualified people and recruit them, which is not a trivial task.
There are no plans for any centralized directory or ranking of escrow agents. Thus, when choosing someone to act as escrow agent for your contract, you will need to decide in your own way who is trustworthy enough to hold your money.
Two specific kinds of Galt Escrow Agency are envisioned: public and private.
A public Galt Escrow Agency is primarily designed to find new buyers and sellers, and let them evaluate each other. The escrow agent may recruit prospective buyers and sellers through advertising or by word of mouth. A major challenge for the escrow agent will be building up a good enough reputation that users are comfortable depositing funds with him, and they have faith in his choice of default arbitrators.
Contracts will generally involve small amounts of money. As a guideline, the buyer commitment should be no more than about 5 ounces, and the seller commitment should be no more than about half an ounce. This will help to keep the site from becoming a major target for hackers.
A typical contract will be a qualifying contract, i.e., one whose purpose is to test whether the seller is qualified for something else, such as a larger contract or full time employment. Thus, the specification will describe a task to be done that is a miniature version of another task, testing whatever talents and skills will be needed for the other task. Normally, the specification will avoid any reference to the identity of the buyer or his company.
Sellers can evaluate buyers by examining the specifications they post. A well written specification, with few ambiguities or contradictions, is an indication that the buyer knows what he wants, and that the work will be satisfying.
Arbitration will usually involve default arbitrators, because the parties won't know each other, and thus if one party proposed an arbitrator, the other party would have no way to verify that he was not an employee or close friend. The escrow agent must therefore either recruit default arbitrators or act as default arbitrator himself.
A private Galt Escrow Agency manages contracts for a specific list of people, by invitation only. In some cases, the site will be created just to manage a single contract, and will be shut down when that contract is over. The site will not be advertised, and in fact only people in the given list should be aware that the site exists at all.
As an example, after a seller successfully completes a qualifying contract on a public Galt Escrow Agency, the buyer may introduce himself by name and invite the seller to enter into a larger contract on a private Galt Escrow Agency. If the site already exists, the seller will need to approve the choice of escrow agent. Otherwise, the parties will need to choose someone and persuade him to act as escrow agent.
The parties may also want to choose one or more arbitrators. Frequently, one party would propose someone he knows personally, and the other would verify that their relationship is not so close as to create a conflict of interest. Both parties will generally want to make sure an arbitrator has good deductive reasoning ability, good writing skills and some familiarity with the relevant industry or field. Of course, the parties can just let the escrow agent choose a default arbitrator when needed.
When there is a large amount of money involved, it is particularly important that outsiders not hear about the site. This will help to avoid problems with e-gold account hackers.
The user interface of the Galt Escrow Agency system is designed to let you work quickly. There are a minimum of graphics that would slow things down. Detailed instructions generally appear on the individual pages where they are needed. But here is a high level summary to get you started.
Each web page in the system has a common overall structure. After the banner comes a form to let you log in or out, followed by a navigation bar. Then there are several "panes" separated by horizontal rules. If you think of the entire web page as a window, then each pane is a section of the window.
The user pane appears in every web page in the system when you are logged in. It is labelled "User", and contains links and forms for the top level things you are allowed to do because you are logged in. For example, there is a link for editing your profile, and there is a form for listing the schedules you have proposed.
Whenever you are logged in, the navigation bar has an entry labelled "User". This is a link within the page to the user pane.
The public pane appears in every web page in the system. It is labelled "Public", and contains links and forms for the top level things that anyone is allowed to do whether logged in or not. For example, there is a link for viewing recent audit results, and there is a form for listing unhidden works.
The navigation bar always has an entry labelled "Public". This is a link within the page to the public pane.
The system deals with several types of objects, including schedules, contracts, claims, works, versions and defect reports. Each object has a view pane. It is labelled "Information about ...", and contains detailed information about the object, along with links and forms for operating on the object.
To bring up an object's view pane, you can select the object from a list, or find a reference to the object somewhere. Either way, the link will take you to a page whose first pane is the view pane. For example, to bring up the view pane for a contract where you are buyer or seller, you can first go to the user pane and ask for a list of such contracts, and then select the contract from the list.
Each link to a schedule, contract, claim, work, version or defect report includes a "key", which identifies the object and also states how you have access to it. For example, a defect report key of "23" means "defect report 23, to which you have direct access". A defect report key of "31c47" means "defect report 47, which is referenced by claim 31, to which you have direct access".
In most cases, the system keeps track of keys automatically and you don't need to be concerned with them. However, you will need to specify a key in the following situations:
The version key is displayed near the top of the view pane for the version. The defect report key is displayed near the top of the view pane for the defect report.
A date and time value is displayed as "yyyy-mm-dd hh:mm:ss", with the time representing GMT. When you input a date and time value, the system will always accept it in this format. A few other formats are also accepted, such as "mm/dd/yyyy hh:mm".
When you request a list of objects, you can specify a range of dates, with the starting and ending date each given as "yyyy-mm-dd". The format "mm/dd/yyyy" is also accepted.
In a chart of delivery remuneration or stability remuneration, the legend for date and time may show dates only, as "yyyy-mm-dd". This means that the corresponding time values are all 00:00:00.
The system maintains a session for you when you visit the site. The session keeps track of whether you are logged in, and also holds some temporary data. If cookies are enabled in your browser, the system will use a cookie to store the session id, normally labelled PHPSESSID.
If cookies are disabled in your browser, the system will embed the session id in the URL for each link within the system. Thus you would see "?PHPSESSID=" followed by some hex digits in each URL. In fact this is normal for the first page, but it should disappear for the second and subsequent pages if cookies are enabled.
Embedding the session id in a URL is a potentially serious security problem, because if someone else gets a copy of the full URL including the session id and points his browser there, he will be using your session, and in particular he will be considered logged in with your user name.
Many web applications require that cookies be enabled, because this security problem is so serious. The Galt Escrow Agency system doesn't go that far. However, it is strongly recommended that you enable cookies. In any case, you should never make a copy of a URL containing a session id and paste it into an email or other communication.
As mentioned earlier, detailed instructions for using the Galt Escrow Agency system generally appear on the individual pages where they are needed. But here is a discussion of each of the major system concepts.
A user is a person who may act as buyer or seller in a contract, or as arbitrator for a claim. In addition, the escrow agent (also called the administrator) is represented as a user with special privileges. To register as a new user, you will need to choose a user name and a password, and you will need to provide a valid email address for notifications.
There are four permission flags that control whether you are allowed as buyer, seller, arbitrator and default arbitrator, respectively. You can see the current settings of these flags by clicking "View Status" in the user pane. If the flags you need are currently turned off, you should contact the administrator and say something about what you will be doing. The administrator will want to verify that your planned activities are legal, and that you understand the risks you will be taking.
In your profile, you can provide as much or as little contact information as you like. It's a good idea to provide at least a public email address, so that prospective buyers and sellers will have some way of contacting you. From the public pane, you can list the users on the system, and you can see each user's view pane including your own. The view pane will show only those fields of the profile that are visible to the public.
If you will almost always be logging in from the same IP address, you should seriously consider turning on the "challenge if new IP address" flag, accessible through "Edit Security Configuration" in the user pane. Then each time you try to log in from a different IP address, you will get a notification email containing a challenge code, and you will need to enter this code in order to complete the log in process.
At this time, the system accepts only e-gold for escrow funds. Near the top of the wish list is support for other currencies such as e-Bullion, GoldMoney and Pecunix.
The system will automatically create the following accounts for you whenever they are first needed:
Below is a diagram showing a simplified flow of funds between accounts in the case of a contract between hypothetical users Alice and Bob.
In this example, the sequence of events is as follows:
The system charges a maintenance fee on each account balance, to compensate for the storage (agio) fee assessed by e-gold.
In fact, a maintenance fee is charged each time a new transaction (other than a maintenance fee) is posted to an account. Each transaction has an effective date and time. When a new transaction is to be posted, the system calculates the maintenance fee as follows:
If the resulting value MaintenanceFee is nonzero, it is posted as the maintenance fee just before the new transaction.
Essentially, the maintenance fee is negative interest compounded continuously, rounded up to a multiple of 0.000001 troy ounces. The public pane has a link to a page that lets you calculate the maintenance fee for any starting amount, over any time interval.
Each account also has a "pending maintenance fee", which is the maintenance fee that would be charged if a new transaction were posted effective now. The phrase "nominal balance" means the balance prior to the pending maintenance fee, while "current balance" means the balance after the pending maintenance fee is deducted.
Keep in mind that the effective date and time of a transaction is not necessarily the same as the posting date and time. Transactions are not necessarily posted in order by effective date and time. Occasionally, the maintenance fee for a new transaction may be negative, actually increasing the nominal balance. Of course, the pending maintenance fee will also increase in this case.
A schedule is a listing of the terms of a contract. It may be an initial schedule (also called a schedule for a new contract), or it may be an amendment schedule for an existing contract.
To start a new contract, a user proposes an initial schedule. When the schedule is accepted, a contract is created and the schedule becomes effective for it.
Either party to an active contract may propose an amendment schedule for that contract. When the other party accepts the schedule, it becomes effective for the contract, and the previous schedule is retained as a historical reference.
As long as a schedule has not been accepted, the proposing user may withdraw it at any time. A schedule is considered pending if it has been proposed but not yet accepted or withdrawn.
When a user is proposing an initial schedule, the system automatically chooses a reference date and time for the new contract. This will be the effective date and time for all transactions on the committed funds accounts, except for the final settlements. For example, the remuneration for any claim will be considered effective as of the reference date and time, regardless of when the service was performed or when the claim was submitted. This greatly simplifies the planning of remunerations, because there are no maintenance fees. The buyer and seller settlements for a contract are effective as of when the contract terminates, and a maintenance fee is charged for each one as usual.
Each schedule specifies two commitment amounts, one for the buyer and one for the seller. These are the amounts that will be transferred into the corresponding committed funds accounts. For an amendment schedule, these are additional commitments, and may be negative (meaning that funds will be "uncommitted", i.e., transferred from the committed funds account to the general escrow account). A contract can never cause either party to lose more than the balance of his committed funds account.
For example, in a schedule for a new contract where you will be the seller, you can think of the seller commitment as the most you can lose, and you can think of the buyer commitment as the most you can gain from the contract. It's important to pay attention to these commitments, because the system doesn't warn you if the remunerations in a schedule are larger than the commitments.
The system charges an escrow fee on each positive commitment in a schedule. The escrow fee is a configured percentage of the commitment.
When you propose a schedule where your commitment is positive, a prepaid funds account is created, and a prepayment is made to this account from your general escrow account, enough to cover both the commitment and the escrow fee. This serves as a guarantee to the other party that if he decides to accept the schedule, the process can't fail due to insufficient funds on your part. If you withdraw the schedule, the prepayment is returned in full.
A schedule refers to a main specification, and may optionally refer to an auxiliary specification. These documents define in detail the service to be performed. Having both documents allows one of them to be shared with other contracts. For example, in a schedule for a development contract, the main specification could spell out the requirements of the software, and could be shared with a maintenance contract and a defect reporting contract. The auxiliary specification could state whether delivery includes installation and training, which would only make sense for the development contract.
When the phrase "the specification" appears with no qualification, it refers either to the main specification or to the combination of the main and auxiliary specifications.
A schedule also includes the following information:
A contract is a negotiated financial arrangement between two parties, a buyer and a seller. Generally, the seller agrees to perform a service, and the buyer agrees to pay an amount that varies according to how well the seller actually performed the service. A contract is created when its initial schedule is accepted.
A contract is considered active if it has not yet terminated. The normal way for a contract to terminate is a claim calling for termination. The contract terminates when such a claim is granted.
Alternatively, a contract may terminate due to an overdraft of a committed funds account. Whenever one of the committed funds accounts becomes overdrawn, the transaction that caused the overdraft is partially or fully reversed, and the contract terminates. The overdrawing party gets no settlement, because the balance of his committed funds account is forced to zero.
A terminated contract may still have some unresolved claims for which arbitration was never requested and/or some pending amendment schedules. Any such claim will remain unresolved indefinitely. Any such schedule will remain pending until the proposing user withdraws it.
A claim is a formal statement by either party to a contract, saying that remuneration is due under that contract. For some claims the remuneration may be negative, in which case the claimant will effectively be paying the respondent. A claim may also call for termination of the contract.
The claimant is the party who submits the claim, and the respondent is the other party to the contract. As shown in the diagram below, the claim proceeds through various states until it is resolved, i.e., either granted or denied.
In some cases, the system rules for the claimant when the claim is submitted, because the assertions of the claim have already been fully verified, and there are no issues left for any arbitrator to decide.
At any time, an unresolved claim may be conceded by the respondent or withdrawn by the claimant. The dispute fee and the arbitration fee are partly designed to encourage the respondent to concede the claim as soon as he realizes it is valid, and to encourage the claimant to withdraw the claim as soon as he realizes it is invalid. The winner may charge any dispute fee up to the dispute fee limit, and the arbitrator may charge any arbitration fee up to the arbitration fee limit. The loser pays both fees, except that the dispute fee is waived if the claim is denied due to contract termination.
Once the respondent has disputed the claim, the parties may make arguments as to why the claim is valid or not. When either party feels that there is no point in arguing further, he may request arbitration. The claimant may also request arbitration even when the respondent has not disputed the claim, if the response time limit has expired.
A request for arbitration is disallowed if any claim submitted earlier under the same contract is still unresolved.
Once arbitration has been requested, in order to ensure that the arbitration fee can be paid, each party transfers the arbitration fee limit from his committed funds account to a newly created arbitration funds account. If either transfer causes the committed funds account to become overdrawn, the transfer or transfers are reversed, and the contract terminates. The overdrawing party forfeits any remaining committed funds to the other party.
After both parties have successfully transferred the arbitration fee limit, the system chooses the first available arbitrator from the list given in the schedule, or a default arbitrator if the list is empty or if none from the list are available.
Once the claim is in arbitration, the arbitrator may make one or more inquiries asking for further information. Both parties can see such an inquiry, and either or both may reply in the form of an argument.
When the arbitrator rules either for the claimant or for the respondent, he must include an opinion. In this document, the arbitrator should address any arguments made by the losing party, explaining why they are invalid, irrelevant or insufficient.
A work is a set of documents, each of which is a version of the work. One may say that the work itself is a document, implicitly referring to any of its versions, or to the latest version. An example of a work would be a software system or a requirements specification.
The owner of a work is the user who created it. Initially, a work has no versions.
A work may be hidden or unhidden. A hidden work will not appear in a list available to the general public. It is only accessible to its owner or to someone who has access to one of its versions. The owner of a work may hide or unhide it at any time.
A version is one of the documents comprising a work. It can be any kind of file. In the case of a software system, a version would typically be an archive file (e.g., zip or tar.gz) containing source code, installation scripts and system documentation.
A schedule's main specification and optional auxiliary specification must each be a version of a work.
The owner of a work may post a new version at any time.
A version may be hidden or unhidden. A hidden version will not appear in a list available to the general public. It is only accessible to the owner of the work or to someone who has access to another object referring to this version. An unhidden version is accessible to anyone who has access to the work. The owner of the work may hide or unhide any of its versions at any time.
A defect report describes a defect in a particular version of a work. The rules for who may post a defect report are as follows:
A defect report may be hidden or unhidden. A hidden defect report will not appear in a list available to the general public. It is only accessible to the user who posted it or to someone who has access to another object referring to this defect report. An unhidden defect report is accessible to anyone who has access to the work. The user who posted a defect report may hide or unhide it at any time, except that a defect report must remain unhidden if at least one claim of defect discovery or presence referring to it has been submitted and has not been denied.
A user who posts a defect report normally proceeds to submit a claim of defect discovery, unless he is the owner of the work. This claim will decide whether the defect report actually describes a valid defect.
The words "defect" and "bug" are synonymous here. When the work is a software system, a defect is a software bug in the usual sense. Although there's a fair degree of consensus as to what constitutes a software bug, it's hard to give a set of rules that covers every case. Generally, a software bug is a failure to meet requirements. The requirements include those given explicitly in the specification, as well as the implicit requirement that the software must do what the provided documentation says it will do, and that it must comply with any established standards of the relevant industry or field unless overridden in the specification.
Unless otherwise stated in the specification, a defect report for a software system must describe a "trigger scenario" under which the software consistently fails to meet its requirements. A trigger scenario is a sequence of events that triggers the bug.
This means when you're posting a defect report, you need to include the steps to make the problem happen consistently. If you observe an intermittent failure, you can't really be sure the problem is in the software provided by the developer. It could be due to flaky hardware or some other software. The trigger scenario is the critical information the developer needs to reproduce the problem in a debugging environment, and thus identify the root cause of the failure and fix it.
The word "consistently" is open to some leeway. A defect report may be deemed valid even if the trigger scenario is not 100% reliable, as long as it gives the developer enough information to reproduce the problem in a debugging environment.
Sometimes the trigger scenario is very difficult to describe. Bugs involving race conditions or uninitialized variables are particularly troublesome in this regard. Below is an example of some C code with a bug due to an uninitialized variable.
#define MAX_PRODUCTS 100
extern void fatal_error(char *message);
int sale_counts[MAX_PRODUCTS]; /* count of sales for each product */
/* update_sales_statistics -- Update statistics to reflect a sale. */
void
update_sales_statistics(
int product_code, /* code of product that was sold, between 0 and 99 */
int quantity) /* how many of that product were sold */
{
int array_index;
if ((array_index < 0) || (array_index >= MAX_PRODUCTS))
fatal_error("invalid product code");
sale_counts[product_code] += quantity;
}
A call to update_sales_statistics may work correctly, or it may generate a fatal error "invalid product code", depending on what value the local variable array_index happens to get when it is allocated on the stack. The fix is to get rid of the variable array_index, and change both uses of it to use product_code instead. But describing a trigger scenario for this bug is very hard. If the client actually observed the problem, presumably it's because he did something that caused another call prior to the update_sales_statistics call, where the earlier call happened to set up the stack with values that would cause the failure. If he can remember in detail what he did, he can put together a trigger scenario.
If you're a client observing an intermittent failure, and you've spent some time looking for a trigger scenario without success, what can you do? You can certainly let the developer know, giving him any clues you may have about when the problem seems to happen. Normally, the developer will be eager to investigate, because if he can find the trigger scenario before you or anyone else can, he won't have to pay the defect discovery remuneration.
Another option you have is bringing in outside help. A third party may be able to find the trigger scenario. He can then try to negotiate with the developer to report it via a defect reporting contract. If that doesn't work, you can report it through your existing contract, and give the third party a cut of the defect discovery remuneration.
A valid defect report must not be a duplicate of any earlier unhidden defect report for any version of the same work. Unless otherwise stated in the specification, given two defect reports, the second is considered a duplicate of the first if in the ordinary course of fixing the first defect, a competent maintainer would naturally fix the second one also.
Below is a simple example of a Java class with a bug.
public class location
{
private double latitude;
private double longitude;
location(double latitude, double longitude)
{
this.latitude = latitude;
this.longitude = longitude;
}
// initialBearingTo -- Calculate the initial bearing for the great circle route to the given destination.
public double initialBearingTo(location destination)
{
double arc1;
double arc2;
double arc3;
double angle1Degrees;
double angle2;
arc1 = (90.0 - destination.latitude) * Math.PI / 180.0;
arc3 = (90.0 - this.latitude) * Math.PI / 180.0;
angle2 = (destination.longitude - this.longitude) * Math.PI / 180.0;
arc2 = Math.acos(Math.cos(arc1) * Math.cos(arc3) + Math.sin(arc1) * Math.sin(arc3) * Math.cos(angle2));
angle1Degrees = Math.asin(Math.sin(angle2) * Math.sin(arc1) / Math.sin(arc2)) * 180.0 / Math.PI;
if (angle1Degrees < 0.0) {
return 360.0 + angle1Degrees;
} else {
return angle1Degrees;
}
}
}
Now here is a sample application using the above class, with two calls that don't work properly. But the second failure is a duplicate of the first.
public class app
{
public static void main(String[] args)
{
location auckland = new location( -36.867, 174.767);
location lima = new location( -12.050, -77.050);
location vancouver = new location( 49.267, -123.117);
// shows correctly as 36.156 degrees
System.out.println("initial bearing for great circle route from Auckland to Vancouver: " + auckland.initialBearingTo(vancouver) + " degrees");
// shows as 310.048 degrees, should be 229.952 degrees
System.out.println("initial bearing for great circle route from Lima to Auckland: " + lima.initialBearingTo(auckland) + " degrees");
// shows as 47.278 degrees, should be 132.722 degrees
System.out.println("initial bearing for great circle route from Vancouver to Lima: " + vancouver.initialBearingTo(lima) + " degrees");
}
}
The bug in calculating the bearing for Vancouver to Lima is a duplicate of the bug in calculating the bearing for Lima to Auckland. That's because a proper fix for the case of Lima to Auckland also fixes the case of Vancouver to Lima. One such fix would be replacing the line "if (angle1Degrees < 0.0) {" with the following lines:
if ((Math.cos(arc1) - Math.cos(arc2) * Math.cos(arc3)) / (Math.sin(arc2) * Math.sin(arc3)) < 0.0) {
return 180.0 - angle1Degrees;
} else if (angle1Degrees < 0.0) {
On the other hand, if the developer submitted a claim of fix delivery asserting that the Lima to Auckland bug was fixed, and then the Vancouver to Lima bug was found in the new version, it would not be considered a duplicate, despite the earlier rule. Generally, one bug is never a duplicate of another one that has supposedly been fixed.
Each contract has a category, specified in its initial schedule. The category determines the overall structure of the contract, including what kinds of claims are allowed. Below are the possible contract categories.
Managing development contracts is the primary purpose of the Galt Escrow Agency system. Under a development contract, the seller agrees to develop and deliver some software meeting a given set of requirements. Thereafter, the seller agrees to fix any bugs that are reported, until the software is stable.
Below is a diagram showing some typical state transitions in a development contract between hypothetical users Alice and Bob.
In this example, the sequence of events is as follows:
After delivering the first version of the software, the seller submits a claim of delivery to collect remuneration for it, and to advance the contract toward either finding bugs or recognizing stability. The delivery itself involves at least posting the software as a version of a work. The specification may also stipulate that delivery includes installation and/or training.
The terms and conditions say the delivered software must "comply substantially" with the requirements. Of course, a few bugs are perfectly normal. But if the software doesn't work at all, or if some required functionality is completely missing, that is grounds for denying the claim of delivery.
The remuneration is based on the delivery remuneration list given in the schedule. Each line in this list has a delivery date and time, along with the corresponding remuneration. For intermediate date and time values, the remuneration is found by linear interpolation. A sample chart of delivery remuneration appeared in the introduction.
The seller isn't allowed to deliver any earlier than the first date and time in the list, nor any later than the last date and time in the list. This may help the buyer to plan when system hardware and testing personnel need to be available.
When the claim of delivery is granted, delivery is no longer expected for the contract, and the buyer may begin posting defect reports. The delivered version becomes the supported version, and the work of which it is a version is known as the maintained work. For the rest of the contract, the supported version will change with each granted claim of fix delivery, but the maintained work will stay the same.
The schedule for a development contract includes a delivery claim deadline. If the seller hasn't submitted a valid claim of delivery by this date and time, the buyer can submit a claim of delivery failure. The remuneration for this claim is also given in the schedule. The contract terminates when this claim is granted.
Actually, the seller is also allowed to submit a claim of delivery failure. In this case, the remuneration is the negative of what it would be if the buyer submitted it.
After posting a defect report, the buyer submits a claim of defect discovery to collect remuneration for it. The remuneration is taken from the defect severity list in the schedule, based on the severity which is stated as part of the claim. The specification explains the meaning of each severity. Once the claim is granted, fix delivery is expected for the contract if it was not already, unless the claim was applicable to an earlier supported version.
The defect report must not be hidden, because other users need to be able to see it so they won't post duplicates.
The buyer may post any number of defect reports for the supported version, and may submit a claim of defect discovery for each one.
The buyer may submit a claim of defect presence referring to a defect report for any version of the maintained work, regardless of who posted the defect report, as long as the bug is present in the currently supported version.
As with a claim of defect discovery, the remuneration is based on the severity which is stated as part of the claim. Once the claim is granted, fix delivery is expected for the contract if it was not already, unless the claim was applicable to an earlier supported version.
The remuneration for defect presence is intended as compensation for the presence of the bug, and is normally somewhat less than the remuneration for defect discovery which is a reward for finding the trigger scenario.
After delivering a new version of the software that fixes one or more bugs, the seller submits a claim of fix delivery to have the new version become the supported version. The remuneration for this claim is generally negative, effectively charging the seller a persistence fee for each granted claim of defect discovery or presence, plus a new version fee. The seller's motivation to submit the claim is that it's a necessary first step toward stability. The persistence fees encourage him to deliver the new version promptly, while the new version fee discourages him from having too many separate upgrades.
To calculate the remuneration for a claim of fix delivery, the system examines all granted claims of defect discovery or presence applicable to the existing supported version that were submitted under this contract prior to the fix delivery date and time. For each such claim, the persistence fee is calculated as the weekly persistence fee from the defect severity list multiplied by the number of weeks (pro rata) between the claim submission date and time and the fix delivery date and time. Then, the remuneration for the claim of fix delivery is the negative of the sum of the persistence fees, plus the negative of the new version fee from the schedule. When the claim is granted, fix delivery is no longer expected for the contract.
The system operates on the assumption that the new version fixes all bugs reported so far. If the parties prefer to allow a new version that doesn't necessarily fix all reported bugs, they may so stipulate in the specification. Then after the claim of fix delivery is granted, the buyer can submit a claim of defect presence for each bug that is not fixed in the new version, and the seller can submit a claim of other condition to back out the extra presence remunerations. This is a bit complicated and not really recommended. Normally, it shouldn't be that hard for the new version to fix all reported bugs, since these bugs will eventually need to be fixed anyway for a claim of stability.
The system allows a claim of fix delivery even when fix delivery is not expected for the contract, i.e., even when no claim of defect discovery or presence applicable to the existing supported version has been granted. In this case, the remuneration is just the negative of the new version fee. As an example, the seller might have found a bug and fixed it without ever posting a defect report for it. If the parties prefer to disallow this practice, they may so stipulate in the specification.
The schedule specifies the stability interval duration, which is the number of days before stability is recognized. After this many days have elapsed since the submission of the most recently granted claim of delivery or fix delivery, the seller may submit a claim of stability if the buyer hasn't submitted a valid claim of defect discovery or presence applicable to the currently supported version. In particular, fix delivery must not be expected for the contract.
The remuneration is based on the stability remuneration list given in the schedule. Each line in this list has a stability date and time, along with the corresponding remuneration. For intermediate date and time values, the remuneration is found by linear interpolation, just as for a claim of delivery. The contract terminates when this claim is granted.
Keep in mind that the stability interval starts when the claim of delivery or fix delivery is submitted, not when it is granted. This is to avoid giving the buyer any incentive to stall in conceding the claim. It's even possible that when the claim of delivery or fix delivery is finally granted, the conditions for stability will already be satisfied. In this case, a moratorium on claims of defect discovery, defect presence and stability failure is in effect for 24 hours, to give the seller a chance to submit a claim of stability.
In some cases, the seller may voluntary choose not to submit a claim of stability even though technically it would be valid. For example, the buyer may have observed an intermittent failure, and the seller may be convinced it is a problem in his software, even though a trigger scenario has not been found yet. The seller may then decide to keep looking for the trigger scenario instead of submitting a claim of stability, in order to keep the buyer happy.
The schedule includes a stability claim deadline. If the seller hasn't submitted a valid claim of stability by this date and time, either party may submit a claim of stability failure. This claim is also allowed if the earliest possible claim of stability would cause an overdraft of the seller's committed funds account.
The remuneration is the stability failure remuneration given in the schedule if the buyer submits the claim, or the negative of this amount if the seller submits it. In any case, the contract terminates when this claim is granted.
The parties may occasionally negotiate an agreement for payment and/or contract termination beyond what the schedule would normally permit. Either party may submit a claim of other condition to implement such an agreement.
A claim of other condition is actually allowed for any category of contract. It requires an invoice, which is a document explaining why the claim is valid. If the claim is implementing a negotiated agreement between the parties, the invoice can just be a brief statement to that effect.
People looking for software often have difficulty articulating what they want in the form of a complete and unambiguous requirements specification. It's envisioned that specialists known as requirements analysts will be available to help people with this important task. A requirements analyst needs excellent interpersonal communication skills, particularly the ability to listen well. He also needs to be able to write clearly and effectively.
When a requirements analyst is paid by the prospective client, he's a consultant in the usual sense. However, a consultant is usually paid by the hour, and thus his income isn't tied directly to his performance. The specification he writes may omit important details that seem obvious to the prospective client but are not obvious to an outside developer.
The Galt Escrow Agency system provides a requirements analysis contract, where the seller is a requirements analyst and the buyer is usually a developer. Typically, the developer would have heard through the grapevine that someone was looking for a software system. The developer would then hire the requirements analyst via this contract to get the details and write up a specification. Remuneration under the requirements analysis contract is deliberately not contingent on whether the developer gets the later contract to develop the software, or even whether such a contract happens at all. This keeps the requirements analyst focused on listening rather than selling.
Under a requirements analysis contract, the seller agrees to analyze the requirements of a software system that a prospective client wants, and to deliver a specification detailing those requirements. Thereafter, the seller agrees to fix any bugs that are reported, until the requirements specification is stable.
There are two separate specifications involved here:
The contract specification is found in the effective schedule for the requirements analysis contract. It consists of either the main specification or the combination of the main and auxiliary specifications. It should give contact information for the prospective client, who would typically not yet be a user of the Galt Escrow Agency system. It may also define what constitutes a "bug" for the purposes of this contract. Unless otherwise stated, a bug is an ambiguity, incompleteness, contradiction or inaccuracy such that the buyer cannot reasonably be expected to implement the software system without further clarification from the prospective client.
A requirements analysis contract is treated essentially the same as a development contract. The deliverable is a requirements specification instead of a software system, and the word "bug" (or "defect") has a different meaning, but the same kinds of claims are recognized, with the same rules for when they are allowed.
The developer acting as the buyer in the requirements analysis contract is of course hoping to be the seller in a later development contract. But as mentioned earlier, the development contract might not happen at all. So the developer will have to view the money spent on requirements analysis as part of the overall cost of doing business, the way some might view a sales and marketing expense. In fact, the prospective client will most likely think of the requirements analyst as a salesman, even if the actual terms of the requirements analysis contract are explained.
Under a maintenance contract, the seller agrees to maintain an existing work for some period of time, fixing any bugs that are reported. The work may be either a software system or a requirements specification.
A maintenance contract is treated the same as a development contract or a requirements analysis contract, except that delivery is never expected. The initial schedule does not include a delivery remuneration list. Instead, it states what the first supported version is. The buyer may immediately post defect reports for the supported version. The rules for claims of defect discovery, defect presence, fix delivery, stability, stability failure and other condition are the same as before.
The earliest possible moment of stability is given by the date and time on the first line of the stability remuneration list. Thus, for a 6 month maintenance contract, this date and time would be 6 months in the future. Normally, the seller tries to achieve stability at that moment, or as soon as possible thereafter.
Under a defect reporting contract, the seller agrees to post a valid defect report for an existing version of a work. In most cases, the seller has already found what he believes to be a bug, and wants to collect the defect discovery remuneration for it through this contract.
A claim of defect discovery behaves the same as before, except that the seller submits it instead of the buyer, and the contract terminates when the claim is granted.
The schedule includes a defect discovery claim deadline, and if the seller hasn't submitted a valid claim of defect discovery by this date and time, either party may submit a claim of defect discovery failure. The remuneration is the defect discovery failure remuneration given in the schedule if the buyer submits the claim, or the negative of this amount if the seller submits it. In any case, the contract terminates when this claim is granted.
A claim of other condition is allowed, with the same behavior is before. No other kinds of claims are allowed under this contract.
A common situation would be that the buyer in a defect reporting contract is also the seller in a contract for development or maintenance with the same maintained work. He should then assume that the buyer in the other contract will submit a claim of defect presence for this defect report. Thus, the defect discovery remuneration under the defect reporting contract would typically be no more than the difference between the remunerations for defect discovery and defect presence under the other contract.
Under a contract for other service, the seller agrees to perform the service described in the specification. This may be any legal service. For example, the seller could provide consultation on a particular subject, with remuneration by the hour.
The only kind of claim allowed under this contract is a claim of other condition. Such a claim includes an invoice, the remuneration amount and a flag saying whether the contract terminates when the claim is granted. The system has no way to verify any of this information, so it's up to the respondent and any arbitrator to check whether the claim is valid, based on what the specification says.
These functions are available to the general public, whether logged in or not.
Fee Rates:
| maintenance fee rate: | 1.02% per year compounded continuously, rounded up to multiple of 0.000001 troy ounces |
|---|---|
| escrow fee rate: | 0.1% of contract commitment, rounded to nearest multiple of 0.000001 troy ounces |