White Paper

Bazaar Accounting

For the Neighbourhoods Bazaar to work in a decentralized fashion, it needs an automated accounting system that makes it possible to reliably, granularly track contribution to applets all manner of valuable elements in the Neighbourhoods ecosystem.
The following presents our current progress toward the design of the bazaar, and should be read with the understanding that particulars may be affected by its future governance and our efforts to share such governance amongst market actors described above.

Dashboards & Settlements

Accounting in the bazaar uses the representation of human-hours required for ideating, designing, implementing, critiquing, iterating, and maintaining applets. In addition to hours worked, the bazaar must also track developer statistics, activity and commit logs, and feedback on features. To enable development costs to be split across communities, the Bazaar also logs usage statistics of applets (e.g. number of nodes that have downloaded an applet).
Developers can add their 'billable hourly rates' to the hours tracked, which communities would then be required to pay, in order to access applets and components. Native payment options will include different models, like subscriptions, one-time access fees, and grant schemes for open source projects.

Price Transparency: Accounting for ‘hours worked’

Our bazaar accounting measures hours worked, tasks completed, and other metrics useful for displaying actually progress to contracting communities. This enables us to deliver a crucial benefit to neighbourhoods--cost sharing across communities. When more communities require a certain applet, the cost for access to the applets drops.
Figure 8: Declining costs per user for a applet as number of users increases (assuming the number of hours required to maintain a applet remains constant)
This is a key difference that Neighbourhoods is bringing to the pricing of code. Traditional tech companies generate more revenue as users increase, with the same lines of code. Code is a non-zero-sum resource, which we are here taking advantage of to be able to spread more useful, distributed app code to more communities more cheaply. At the same time, developers set their own hourly rate, as is standard in the culture of freelancing. By displaying rates, we hope to drive costs down for communities.
Our approach can bring about a shift in the pricing of code that sets a precedent in the crypto space for the benefit of groups of users and the code commons. Because we expect that more people using a applet may entail a greater number of required hours of maintenance, these hours may be reflected in billing and settlement. This is a fair increase rather than a venture multiplier; NH's stance is that revenues to developers shouldn't increase on principle as a function of increased user count.
The modularity inherent in Holochain's architecture, combined with our framework for applets and sensemaking, also makes it easier to swap out applets so that communities are not unnecessarily locked in as the bazaar grows and new options emerge.