Space is open to us now; and our eagerness to share its meaning is not governed by the efforts of others. We go into space because whatever mankind must undertake, free men must fully share.—John. F. Kennedy

The beginning of this series presented the motivations behind creating a protocol for creating a free-licensed design marketplace for material products. Now, I hope to detail the design concept of a specific package: “Narya Bazaar”[1] is to be a web e-commerce application designed for a free-licensed economy. It will need to have many features in common with other e-commerce systems (shopping carts, credit card payments, and so on), but here I want to explain the unique part of the design, which is the “Bargain Protocol” that links our three principle actors: projects, donors and vendors.

Actors

Projects in the Narya system are more-or-less as they are in the GForge[2] (or SourceForge) free software project incubator. They may be run by single individuals or groups of people. Groups might be affiliated only through common interest, or be co-workers funded by a commercial institution, though the former is much more likely.

There are particular roles within the project that are common to other project systems, such as the “project leader”, but Narya Bazaar introduces another particular role, which I call the “quartermaster” (QM). Like a real quartermaster, the project QM is in charge of the project’s material stores, and is trusted by project members with this role. Furthermore, in order to interact with the Bazaar system, the QM must have a physical mailing address and account information on file at the site. Since this represents some loss of privacy, it’s understandable that projects will not want all of their members to have to agree to these terms, but at least one member needs to if they want to take advantage of Bazaar’s provision of materials and services.

Like a real quartermaster, the project QM is in charge of the project’s material stores

Donors, are the wonderful people who have money to spend on seeing that projects of interest to them succeed. Without them, of course, there would be no point in designing Bazaar at all. We do not treat them as a magic source of funding here, however, but as customers who expect to see value for the money they contribute. This value comes in the form of newly available technologies that they can use, and in the manufactured incarnations of those technologies as provided by vendors.

Finally, vendors, are the commercial providers of the materials and services that are needed by projects to complete their development work, and who must be paid using funds that come from donors. These are fairly well-understood commercial entities, although they may take any commercial form from a self-employed consultant to a large contract manufacturer or commodity supplier. In some cases, the “vendor” in the Bazaar system will actually be a reseller of services procured by external means.

Vendors sell to donors in essentially two modes: the first is direct sales in which the “donor” is more-properly called simply the “customer”; and the second is providing services to projects that the donor is supporting. In a successful free-matter economy, the former kind of sale will dominate in sales figures, although the latter will probably be the main form of sale at the beginning, and may always be the largest in number of unique transactions. However, since the former case is handled by standard e-commerce solutions, I will not expand further on it. It is the latter mode that most needs explanation here.

Project needs

In the previous two articles, I have outlined the fears and needs of the donors and vendors by way of outlining the requirements of this protocol. The one remaining class of actors is probably the most obvious one—the project developers. Fortunately, the fears and resulting needs that project developers have from the Bazaar system are pretty straightforward:

Funding

• Fears: that project will be impossible to complete because of materials costs.
• Wants: a fundraising system that allows interested parties to help them with costs.

This is the whole point of the Bazaar system.

Services

• Fears: project will require work that participants are unable to do for themselves.
• Wants: way to purchase necessary services.

In short, we need to have vendors available to provide the services. Given the difficulty of sourcing, ordering, and receiving high-tech components in prototype quantities and the difficulty of finding testing services which are normally only marketed to commercial organizations, this would be a problem even if money were no object.

Commercialization

• Fears: commercial needs will overwhelm project participants and steal control of project goals.
• Wants: to control project without the threat of “takeover” by donors or vendors.

Project developers have chosen the free-design route for a reason. Any design which tends to destroy the free-market of ideas surrounding free-licensed development must be avoided. Although Bazaar will undoubtedly include a “tip-barrel” much as SourceForge now does, the focus will be on “provision” funding rather than “grant” funding for this reason (projects wishing to operate on a direct-payment basis can always function as vendors in the Bazaar system, of course).

Combined with the needs outlined in parts 1 and 2, this gives us the requirements that drive the design of the Narya Bazaar Bargain Protocol.

Resolving trust faults

Most of the needs outlined for these three actors are types of assurances that need to be made to resolve the natural trust faults of the bargain arrangement, as diagrammed in Figure 1. Note that faults exist not only between the classes of parties involved in the bargain, but also among the individual actors within each group. Indeed, these include some of the most serious problems to be solved.