Components:

• Participants:
  • Customers
    • pledge money
    • pay money
    • determine product acceptance
    • vote if needed
  • Developers
    • implement the spec
    • fix reported significant bugs on the bug list.
    • license the result by GPL
    • guarantees non-infringement of the implementation
    • get paid after it is accepted or at least free of terminal bugs for a fixed acceptance period
    • (owns the copyright?? or does the administrator??)
    • (obtains agreement from other contributors of incorporated code??)
    • (how is their fee determined??)
    • (how do we ensure developer coalignment/cooperation??)
  • Administrator:
    • provides infrastructure
    • imposes structure
    • is a party to the legal agreements
    • owns the copyrights (??)
    • receives a percentage of the income (10%?)
  • Idea specifier
    • puts the spec into the system
    • guarantees IP non-infringement of the spec (or obtains permission to use it)
• decision-making processes:
  • the system should minimize unnecessary conflict
  • use dollar-weighted voting by customers when needed
  • developer teams can self-organize with a united front
  • it may become necessary to provide more structure using other methods as experience dictates (e.g., consensus, democracy, dictatorship...)
• a software map, comprising an editable tree or graph
  • non-terminal nodes represent categories of software
  • terminal nodes represent particular specs and contain:
    • the description
    • its current financial status
    • a "point of sale" to make contributions, with aids to rational self-pricing.
    • access to the current development snapshot
    • the current bug list for the spec
      • a sliding time-window to allow timely bug reports
      • a method to specify "significant" bugs
      • Once cleared for N days, Project Completion can be declared
    • associated usenet and/or email discussion group(s) automatically emailed to whoever wants
  • specs can be contributed by anyone
    • edits can be adjudicated by whom?
    • RMS: specs shouldn't be too detailed
• license agreements to bind the participants
  • developer agreement
  • customer agreement
  • idea-specifier agreement (to relieve the system of liability for IP issues on specs)
• a contribution-processing system including
  • a bank account
  • and an accounting database to track the status of a set of amounts associated with spec's and contributors.
  • An amount may be:
    • PLEDGED: when the customer completes the CGI form
    • IRREVOCABLE: after some milestone
    • TAKEN: after another milestone
    • AVAILABLE_FOR_DISBURSEMENT: after another milestone
    • ALLOCATED_FOR_DISBURSEMENT: according to what rules?
    • DISBURSED: by yet more rules

Key problems and Solutions:

• The First Dollar Problem: Why should the first customer contribute if the idea is still just a mere idea without anyone committed to it?
  Solution: the money is merely a *pledge*, softened by postponing until later the deadlines for withdrawing commitment and for transferring the funds. Commitment could be revokeable until some reality milestone is achieved; similarly funds transfer can also be postponed until some milestone is achieved. Suitable milestones can include a fixed duration of time from the pledge date, or achievement of a threshold total pledge amount (specified by whom?), or a declaration of commitment by developers, or initial delivery by the developers, or final acceptance by the customer.
• The Last Dollar Problem: Won't contributions stop too early? Many signs indicate to potential contributors that they don't need to contribute: a) the project seems to be moving along already so their contribution isn't required; b) the project isn't moving along at all, so it isn't likely to actually happen in the first place, so why bother contributing; c) the project is getting funds in from other customers so why not let them take care of it and just go along for the ride.
  Solution: TBD. One solution is not to start until some budgeted amount (e.g., the developers' offer) is fully subscribed (this is the CoSource.Com solution). But it would be better to have a system that supports ongoing and continuous contributing, continuous rebudgeting, continuous development, continuous evolution of the spec's, if possible. Another approach is to hide the finances from the customers so they don't enter into mind games with each other. Or instead, aids to rational self-pricing which encourage community awareness and financial cooperation among customers should be provided to customers at their point of payment, including currently projected total additional market, current financial and technical status of the project, a suggested price based on revenue, cost, market size, customer characteristics, etc. Customers should be able to see for themselves how much their contribution will really help, how badly it is needed. This kind of information might potentially persuade contributors to make appropriate contributions at different times, small ones at the beginning, perhaps, to flesh out a rough spec with a minimal implementation, followed later by further contributions to expand and refine it as the project evolves, etc.
• The Customer Pricing Problem: How much does each customer contribute?
  Solution: However much they want, subject to an administrative minimum.
• The Developer Pricing Problem: How much does each developer receive?
  Solution: Developers get the remainder after expenses are taken out (such as the administrator's percentage). Customer voting using weighted sums, where each contributor votes their dollars over the set of claimants. I'm not sure this is any better than having a manager who has a reasonable sense of the developer labor market negotiate in good faith and individually for the contributions of each developer. If developers work together in groups where they adjudicate their own contributions and receipts, whether through a single lead or through consensus or other methods, that is a compatible form of this solution, wherein customer voting needs to be invoked only when developers cannot resolve it among themselves. CoSource.com's solution is that developers make an offer with a price, a deadline, and an Adjudicator. This has the advantage of clarity but doesn't encourage bazaar development.
• The Other Contributors Pricing Problem: What fees are paid to the administrator, idea specifier, project manager?
  Solution: 10% to the administrator, nothing to the idea specifier (despite their contribution not only of the idea but also of the formalization of it as a spec, and of a guarantee that the spec is free of IP constraints) nothing to the manager (since there is none in the current version).
• The Many-Eyes-On-The-Problem Problem: We want to retain the bazaar characteristic of development, but to have that in an environment where fees are being paid, we must either provide clear means for participants to judge the amounts paid for any particular technical contribution, or we will have endless disputes, even lawsuits, among developers. If many developers make large and small individual contributions and they are not also socially organized in some group structure with means for judgement and negotiation, then we invite endless unnecessary disputation, where a moment's reasonable negotiation, in writing and in advance, with someone in authority, would have prevented it. On the other hand, if developers organize themselves under leaders or via consensus or any other method, their group can make a unified front to the system, and invoke customer voting only where internal disputes are impossible to resolve.
  Solution: Ensure or at least encourage new developers to join in on projects. Provide all possible support for the group decision-making structures of teams of developers, consistent with adding new participants and treating them fairly. Where necessary allow recourse to customers voting their dollars as a weighted sum over alternatives. Include assent to the process in the developer's agreement.
• Project Termination Problems: What event determines project completion? How do we ensure a project isn't underfunded (i.e., declared Complete and then released before enough contributions have come in to pay for committed expenses)? Does anyone get a refund if it is overfunded? (is there such a thing as being overfunded?)
  Solution: Uhh, hmm.
• The Developer Delivery Deadline Problem: What prevents a developer on whom the system relies from taking forever to make their contribution? If a group decides to accept a developer's commitment before recieving their actual contribution, then other developers may be redirected away from doing that bit of work, and thus hold the whole project hostage. If in trying to solve this problem multiple developers end up doing the same work, who gets the credit?
  Solution: The CoSource.com solution is for developers to attach a deadline to their offer on a spec, and to put some teeth behind that deadline (maybe it's renegotiable with customers, I'm not sure). Here, developer groups should manage themselves as much as possible, handling this issue like any other. The system may provide decision-support methods and structures to help developer groups And where conflicts arise between groups, customers can vote their dollars as a weighted sum over the alternatives, as with any other problem.
• The Credit Card Storage Security Problem: SSL can encrypt this information in transit, but if the transaction isn't committed instantly then their storage on the administrator's filesystem becomes a huge potential security risk.
  Solution: Be careful.(??)
• The Freeloader Problem: If the current development snapshot is made freely available then potential customers will have one less reason to contribute. (We want to ultimately enable infinite freeloading, but it may be a problem during the development phase.)
  Solution: a) Don't make it free until after Project Completion is declared. Make it available only to customers who pay at least the administrative minimum, or make it free only for developers. Or: b) Allow freeloaders from the beginning. Depend on the incorporated aids to rational self-pricing to convince potential contributors to help. (??Require freeloaders to at least look at the aids to rational self-pricing??)
• The Bug Status Problem: Some bugs are not worth the trouble of fixing them, because their effects are too insignificant and/or the trouble to fix them is too great. Therefore we should not require the bug list for a project to be completely cleared before Project Completion is declared. Instead we need some method to determine the significance of a bug.
  Solution: TBD. Bugs may be Terminal or Non-Terminal. A bug list with associated discussion groups should be provided for every project, with each bug and bug report going through a formal tracking system. Again in disputes, participants including developers and customers could discuss and vote with their dollars or their time or whatever. Cosource.Com provides for every project an Adjudicator to solve this particular problem; it is another developer selected by the project's developer and is accepted by the customer when the project is initially bought in to. (This enables collusion among developers who could declare acceptance of each others' junk deliverables on projects, at least until retained historical records give customers enough information to avoid those developers, assuming that is provided for.)
• The Project Expiration Problem: PFFS has not considered project expiration, which is a key component of Cosource.com, where specs are typically intended for short-term custom programming requirements, where the customer and the idea specifier are one and the same, and where specs therefore normally include an expiration date. In such cases few if any additional customers are likely to cooperate to contribute. However, PFFS, as I conceive it, targets more significant projects with long-term value to many customers; we haven't made provision for pledges or projects to expire, they just sit there and accumulate pledges, which form a growing permanent prize.
  Solution: I don't think this is a problem: Having a prize attached to a spec, for as long as it takes to achieve that spec, is a Good Thing. Although there is a technical issue: credit card pledges may have some intrinsic half-life we should know about, so we can complete approved transactions before it's too late.
• The Intellectual Property Violations Problems: Specs and implementations might violate various IP restrictions.
  Solution(s): a) We could pretend to disclaim all responsibility for projects and just be cheering bystanders to transactions among third parties, by not owning any of the copyrights or providing the servers for the distributions to come from, or taking an administrative fee, if that would save us. b) Or we could instead require that specs and technical contributions are contributed with a clean IP slate.
• The Moving Target Problem: What if people want to change the spec or reorganize the technical components in a different way? This is a good reason to keep the spec from being too detailed.
  Solution: after Project Completion, a change becomes a new separate project. Before Project Completion, it becomes a big pain, requiring group decision making, maybe all the customers will have to vote again, and so forth. Yuck. Changes should be easy and this isn't.

  Notable differences with CoSource.com:

  At CoSource.com, money is pledged not to a spec but to a developer's offer, thus pre-adjudicating a number of problems by simple market dynamics: the Developer Pricing Problem is solved by customer choice among offers. The Customer Pricing, First Dollar, and Last Dollar Problems are solved because the idea specifier and the customer are usually the same person and because the offer is fully funded before the developer starts. The Project Termination question and the Developer Delivery Deadline problems are answered by the developer's offered deadline. Freeloaders don't detract from the funding since the project isn't started until it is fully funded. Bug status issues are resolved by Adjudicator named in the developer's offer. And the Project Expiration is provided for when the spec is entered into the system by its idea-specifier-cum-customer.

  The main problem I see with CoSource.com is that the projects supported are mostly really small, time-limited, custom-programming projects basically negotiated between one customer and one developer, rather than significant new initiatives that many participants can pull on together. I have had big ambitions for PFFS, which should be able to organize large and visionary projects, and which should ideally be able to appeal to and bring in the mass markets of naive users whose needs for easy UI's can motivate more of that kind of programming, which isn't getting done as much as it might in the Free Software world.

  Also CoSource.com loses the Many-Eyes-On-The-Problem, bazaar nature of free software development, by not really allowing developer groups to modify their offers and by not really encouraging them to include all additional developer participants that have a willing spirit. In this way it doesn't seem to allow for gradual and continuous evolution of projects or integration with the volunteer free-software development community. Also under CoSource.com, customers no longer have much leverage on the process after their money is committed (which may be a Good Thing, if customers are normally obtuse en masse), whereas, here, customers control project acceptance by controlling disbursements: money doesn't become "AVAILABLE_FOR_DISBURSEMENT" until they say so (subject to bug-list dispute-resolution methods). Finally, at CoSource.com the developer specifies the kind of licensing they are offering, and customers may accept whatever they like. This market solution has the result that developers may not be motivated to GPL their code.

  In summary, though, I think CoSource.com makes reasonable choices for all these problems, and provides a solution that is at least both market-based and clear for most of them, and with some relatively minor tweaks they could have everything I have conceived in PFFS. One possibility is to go talk to them (I'm in Seattle, they are just across the lake) and give them some feedback and let them run with it. What do you think?

  Mailto: pffs@gnu.org

  
  Last Modified: January 18, 2000