FOSS Factory depends on a complex system of checks and balances. We recommend reading over this document carefully, as it describes some subtleties that can help you get the most out of the system.
If you're just looking for a high-level introduction, check out our opinion piece: Why we need FOSS Factory.
Each project consists of a name and a set of requirements. Project requirements should be complete, but brief. They should focus on functional needs, as opposed to design points. Wherever possible, design issues should be left in the hands of the community. On the other hand, it can be a good idea to outline quality requirements like performance and resource utilization. We anticipate that the community will develop standard wording for abstract requirements such as usability and code maintainability.
In the interest of fairness to developers, project requirements should be fairly static. However, there will always be a need for changes or clarifications. Any member can post a requirement change proposal at any time. It is up to the project lead to accept or reject the proposal.
The project lead must ensure that requirement changes are reasonable and justified. If a dispute arises over a requirement change, the benefit of the doubt will normally lie with the plaintiff.
2. The Project Lead
Each project has a project lead – that is, the user responsible for keeping the project moving forward. The project lead's duties include:
- To accept or reject requirement change proposals.
- To allot a portion of the project funds to newly created subprojects.
- To review submissions and decide whether they satisfy all project requirements.
- To respond to complaints that are filed.
Who is the project lead?
By design, the position of project lead can be transient. The intent is to ensure that there is always somebody able to fulfill the duties. Nevertheless, a good project lead should have no problem retaining the position. The project creator is normally the initial project lead.
Whenever the position is vacant, any site member can become the project lead. At any other time, the current project lead can be supplanted by any member holding a larger number of project credits.
Immediately upon missing any duty deadline, the project lead is automatically removed from the position, leaving it open for anyone. This is not intended as punishment, but rather as a way to keep the project moving. In most cases, the original lead can reclaim the position when he/she returns.
Any site member can sponsor projects. Subject to certain restrictions (see Holds on funds), you can distribute and redistribute funds freely among any projects in the system.
The reserve is like your personal bank account on FOSS Factory. You can transfer money into or out of it using PayPal, and you can draw from it to sponsor projects or retract sponsorship funds back into it. If you earn a bounty by submitting a project solution, the payment will be placed into your reserve.
A monthly sponsor is a member who sponsors projects via a pre-authorized monthly plan. Your monthly sponsorship settings can be managed in the Monthly Sponsorship section of your My Factory page. You can choose how much of your monthly deposit goes into each of your favourite projects. You can also choose an amount to contribute to a randomly selected featured project.
Special benefits are reserved for monthly sponsors:
- Your featured projects voting power is doubled.
- Your number of project credits is doubled for all of your projects. This doubles your capacity for supplanting the project lead should the need arise.
- Normally, when a developer receives payment for a solution, a portion of the payment (currently 0%) is deducted. We call this the community deduction. For developers who are also monthly sponsors, this deduction is waived.
If you plan to participate as a developer, we highly recommend that you become a monthly sponsor to avoid the community deduction.
Project sponsorships can be withdrawn at any time to the member's reserve, except for amounts held due to pending submissions.
Every dollar you contribute to a given project gives you one project credit. (This number is doubled for monthly sponsors) Anyone with more credits than the current project lead may take over the position at any time.
You may also assign your project credits to any other member. That is, you can use your credits as votes to help elect a member of your choice. This opens up the possibility that a group of disgruntled users may overthrow the project lead by electing a replacement.
Every dollar you contribute to any project also buys you a vote toward the list of featured projects. (Your number of votes is doubled if you are a monthly sponsor.) Featured projects are displayed prominently throughout the site. Furthermore, most of the funds collected from the community deduction are distributed among the featured projects. Having your favourite project in the featured list will help give it the attention it needs to quickly move forward.
Subprojects provide a way of breaking down large projects into smaller pieces. Each subproject has its own requirements, and its own project lead. Subprojects may be broken further down into smaller subprojects. The idea is that large projects may be recursively partitioned into manageable tasks on the order of a single day of work. The resulting project hierarchy would naturally serve as a rough design document.
Anybody can create a new subproject at any time. Each new subproject can be thought of as a proposal for a particular breakdown approach. The project lead for the parent project must decide what portion of the parent project's funds to allot to it. This decision should be based on the merit of the breakdown approach, and on an estimate of the workload. Subject to certain restrictions (see Holds on funds), project leads may rebalance subproject allotment percentages at any time.
The deliverable for a subproject is usually a cleanly separable component such as a function, class, module, library, or even a completely separate executable program. The subproject requirements should outline the functional requirements, plus the complete programming interface. For example, if the deliverable is a command-line executable then the subproject requirements should fully define the command-line syntax.
If you are thinking of working on a project which would take you more than about one day of work, consider creating a subproject for the first component that you'd like to work on. Don't bother making a complete breakdown design. You can leave creation of the other subprojects to other developers. Creating only subprojects that you intend to work on helps to signal to other developers that somebody is probably working on it, so they're more likely to leave the task for you rather than compete for the same funds.
Avoid creating redundant subprojects. If you believe that you know a better approach for a subproject, then start by proposing a requirements change on that subproject. If your change proposal gets rejected and you still feel that your approach is significantly better, then it's appropriate to create a competing subproject. The top-level project lead will decide whether to allocate funding to your new approach. It is at his/her discretion whether to remove funding from the first approach, or to support both equally. It is often valuable to support two competing approaches for a single component.
5. Project Completion
To claim the project funds, a developer must be the first person to provide a complete solution to the project as a single submission. The submission must satisfy all of the project requirements at the time of submission.
A solution can be posted either for the complete top-level project, or for any individual subproject.
The effective funding on a subproject is the sum of any funds contributed directly to that subproject, plus its share of its parent project's funds. When a subproject is solved, the solver is paid the full direct funding on that subproject, plus the portion of the parent project's funds that were allocated to that subproject. For the purpose of project sponsorship and credit tracking, the reduction in parent project funds is attributed proportionally to all sponsors.
At first it might seem that this race-to-the-finish approach violates the collaborative spirit of the free software community. However, as long as a project or subproject is large enough or lucrative enough to be attractive to multiple developers, most developers are motivated to minimize their risk by further subdividing the project. The result is better project definition, and more opportunity for collaboration.
The cool-off period
Whenever a submission is approved by the project lead, there is a time delay before the payout actually occurs. The delay may be anywhere from 24 hours to two weeks, depending on the popularity of the project and the size of the payout. The purpose of the delay is to give community members a chance to assess whether the project lead has made a mistake, or even acted in bad faith. During this interval, members can file a complaint if they believe there is a problem.
Holds on funds
Normally sponsors can redistribute their sponsorship funds freely. However, from the moment a submission is made on a project, all funds on that project are locked in place at least until a decision is made. This ensures that sponsors can't use their funds as a carrot, only to withdraw it the moment a submission arrives. The hold remains in place either until the submission is rejected with prejudice, or until the submission is rejected without prejudice and the refiling grace period expires. If the submission is accepted, then the funds are paid out, so they are obviously no longer withdrawable.
While a hold is in place sponsors can still increase their funding if they so choose (though they are warned about the hold). Pre-authorized sponsorships will proceed without warning.
There are two different modes of submission rejection – rejection with prejudice, and rejection without prejudice.
If a submission is rejected with prejudice, it means that, in the judgment of the project lead, it is not even close to being a valid solution. There are many possible reasons for this. For example:
- Confusion or misunderstanding on the part of the submitter
- Obvious copyright infringement, or other legal problems
- Deliberate abuse, or gaming of the system
In any case, the submission is completely removed, and the hold on project funds is immediately lifted. A notification is sent to the submitter to explain why the submission was rejected.
If a submission is rejected without prejudice, it means that it seemed to be an honest solution attempt, but it was found to be lacking in minor ways. In this case, the hold on project funds remains for a period of time in order to give the submitter a chance to fix the problems and resubmit. The submission will remain listed in the submissions tab for as long as the hold exists. Other contestants may still submit their solutions during the hold period; as always, the first correct submission will earn the payment.
The community deduction
Normally, whenever a project is successfully completed, 0% is deducted from the payout. By default, the deduction is distributed among the top ten featured projects, weighted according to the number of votes for each project. Alternately, the claimant can choose to direct the deduction to one of several charitable organizations.
The community deduction is waived whenever the payment is claimed by a monthly sponsor. That is, if you are both a developer and a monthly sponsor, then whenever you complete a project you are entitled to 100% of the funds.
The purpose of the community deduction is to encourage members to become monthly sponsors, in order to help sustain the community.
FOSS Factory's fee
FOSS Factory deducts a 0% transaction fee from all bounty payments. This fee is separate from the community deduction.
Any registered member can file a complaint regarding the management of a project. When a complaint is filed, the project lead is notified, and must respond to the complaint. If the project lead responds by posting a counter-argument, then the plaintiff is notified and must follow up. The dispute can continue back and forth between the plaintiff and the project lead until one of the following occurs:
- The plaintiff opts to cancel the dispute; or
- On their turn, one or the other party chooses to finalize the discussion. In so doing, they forfeit their final opportunity to comment, thus granting their opponent the last word.
The entire dispute takes place on a public page, linked to from the project page, with a public discussion forum underneath.
The final decision is normally made by a jury. The jury is auto-selected as a group of active site members who have shown no interest in the project in question, or in any of its related projects. Jury members remain anonymous. In the event that a jury can't be selected, the decision is made by an arbiter (a FOSS Factory staff member). In either case, the decision is final and binding.
Prior to making their decision, jury members (or the arbiter) have the opportunity to direct specific questions to either party. The parties are responsible for answering the questions.
Throughout the process, the project lead is given deadlines for each of his/her responsibilities. The plaintiff, on the other hand, is not given any deadlines. The presumption is that it's the plaintiff who is seeking justice, so any delay on his/her part only harms him/herself.
Note: The automatic jury selection system is not yet operational. Currently, all finalized disputes are decided by an arbiter.