[TL;DR Summary --This post lays out in fair detail the current state of ideation on a very big concept: A community platform/protocol-set/ecosystem riding on the SAFE Network, which will provide the tools for developers and other creative types to “labor in freedom” while being compensated for working to create value for all, as judged by the open source community. It is an attempt to design a system whereby anyone who has value to contribute can participate in the creation of fabulous things in free coordination with others. With the SAFE Network, we feel that the key tools are in hand to accomplish this. Just some more details to work out.]
What exists below is our best attempt at unravelling the vast tangle of ideas that have been gathered over the years of ideation and turn the strongest threads into a paradigm changing tapestry. I want to start out by thanking @fergish for his help in this process. Without him, I fear people would have a vastly harder time recognizing anything resembling the vision that is the fabric of this proposed ecosystem.
That being said, expectations still need to be set. There are a few ideas near the end of the document that are “works in progress”. We are asking for much-needed specific ideas and feedback, though I’m excited to hear any and all critiques the community might have.
#First, What is it?
Once completed The Crowd Found Hub will be a community resource that provides the necessary tools to allow distributed groups, made up of individuals who are operating voluntarily, to collaborate in a transparent and sustainable way on inspiring projects, while being free from hierarchical control structures. It will allow for each person to be rewarded for their contributions while protecting the individual from ruinous losses in time, energy and finances due to the high degree of risk often associated with investing in new endeavors. Success of projects developed using the Hub will be dependent on many factors, not least of which will be the understanding and appropriate use of the tools it makes available to participants.
The mission of the Hub is to Empower the Individual to Labor in Freedom, freedom being one of three key tenets of the SAFE Network. This quote emphasises the Hub’s mission:
“Everything that is really great and inspiring is created by the individual who can labor in freedom.” ~ Albert Einstein
##Projects, Proposals and Work Items
To understand how it accomplishes its mission, we must understand the ecosystem that the Hub will create for the project creators, collaborators and Makers who will be incentivized to work on projects developed on the Hub.
Anyone can start a project using the Hub. With a simple seed of an idea a new community is born. As the idea matures it will gain collaborators who continue to develop the concept into a more focused vision (business plan, requirements, what a minimum viable product might look like, etc.). Along the way these initial collaborators can be recognized by individuals of the community for their positive contributions. (see “Recognition Work Items” details below).
As the project vision takes shape, individuals will start to have embryonic ideas for features that might be included in the end product. Support towards these features is provided by contributing Hub Fuel (i.e., Hub Tokens), thus giving the collaborators a means of reaching consensus of the desirability of the feature.
When the project community agrees that a feature is ready to start development, an iterative work item is created. The work items should include a description of the feature as best the community can articulate it at that specific time, along with the expected results of any acceptance testing. Upon creation these work items are listed with the pledged incentives for the Makers who will complete them. A Hub algorithm will gradually release new Hub Tokens into the ecosystem through work items (more details near the end of the document).
When work items are completed, the assigned Hub Token pledges (along with newly released Hub Tokens) are transferred to the Maker(s) who completed the work item. Project Utility Tokens are also created at this same time in the same number of Hub Tokens the maker receives. These Utility Tokens are split between the project contributors and the Maker(s) who complete the work item (see “Project Utility Tokens” below).
###Iterative Development (Handling Scope-Creep)
Because completion of work items will almost always lead to further discovery and ideation about features, the work items should be seen as steps along the way towards a moving target. This is the essence of Agile Software Development. Makers should not be forced to go around and around handling scope-creep the community will inevitably introduce, in order for them to receive their originally agreed-upon reward. When the new ideas about a feature are discovered, those should be turned into new work items with their own descriptions and expected results. It is recommend that project community members (agile term: stakeholders) read up on agile development practices to ensure their community and maker relationships remain healthy.
###Recognition Work Items
As mentioned above, contributors who have been recognized for their positive contributions during the initial ideation phases are preassigned as Makers on special Recognition Work Items which are immediately awarded bonus Hub Tokens and proportional Project Utility Tokens (which can be held, used or sold), thus allowing those Makers to be compensated for efforts individuals deem worthy.
Each project is an autonomous community within the broader Hub community. The Hub will not seek to control project placement by some kind of curation. The Hub community will determine interest in projects by the members’ contributions and each user will be able to filter and sort projects the way they see fit (popularity, activity level, category, work items, no. of workers, creation dates, percent complete, etc.).
##Project Utility Tokens
The Hub will create Project Utility Tokens in the same number of Hub Tokens that are earned by the makers when they complete work items. Ninety percent* of these Hub created Project Utility Tokens will be assigned back to the original backers and ten percent* will be assigned to the Maker who completed the work items. These utility tokens can be used for anything the project community deems worthy. They are simply smart assets that can be used in any smart contract structure. Some example uses might be that these tokens could be the fuel for the project’s own ecosystem, or perhaps dividend producing “proof of contract” shares. Each project has the freedom to innovate to suit its own requirements, and to find new and more effective ways of doing things.
Just because the Hub automatically creates these project specific utility tokens for every work item completed on every project, this doesn’t mean these utility tokens have to be the final assets of value for that specific project. An example might be a project that only exists to get everything ready for a larger crowd sale of its “Public Tokens”. The community might decide they need a “Proof of Concept” or an MVP. The Hub would create the Project Utility Tokens and when the “Proof of Concept” or MVP is done to satisfaction they can run their crowd sale. Hub created Project Utility Token holders could receive a set sum of the crowd sale “Public Tokens” based on their percentage of project utility tokens held. All others who were not involved in that first phase would have to buy tokens through the normal crowd sale channels. This example might make an added use of the project utility tokens. During the “Proof of Concept” or MVP development, Makers could be being watched by the contributors to potentially become full-time project developers. The larger crowd sale funds might be controlled by the original project utility holders and passed to the full time devs after the sale. Again these are just two examples of how these Hub created Project Utility Tokens could be used. People will come up with many other uses and the Hub will make it easy to implement these different uses.
##Instant Incentive Conversion
Because of the SafeX protocol, instant conversion of work item incentives (project tokens/alt-coins, whatever used) to the Maker’s currency of choice is possible. This would allow the Maker maximum flexibility to participate according to his or her own personal needs/preferences/goals.
#Fueling the Ecosystem (i.e., Hub Tokens or, collectively, Hub Fuel)
Hub Tokens are designed to form the economic foundation which supports the decentralized Crowd Founding Model. The economic ecosystem made possible by this model will allow many ongoing advancements to progress in a co-supportive way, rather than requiring each project do all the heavy lifting individually. In essence the design is intended to be a decentralized Maker Space for software development. Additionally, it should incentivize and reward outside investment, rewarding it well and stably with minimal risk.
##A Volunteer/Donation Based Model
Some actions will require Hub Fuel, such as promoting through pledges on feature proposals (as covered above), while some actions and community developed add-on features will be donation-based. Each project will have to collectively decide amongst its participants whether or not to donate for using the features. They will be required to give a reason why they chose the way they did. Those decisions will be known to the network of Makers who will one day decide to contribute or not contribute to the project. We think this is incentive enough to help people help the ecosystem along the way, as well as allow for those projects that really can’t afford the donation to use them as they see fit.
The flow of Hub Tokens through the ecosystem can be visualized in the following diagram.
###A Note on Pledges and Support
When pledging support for features, the Hub Tokens are not officially assigned until actual work items are created. If a work item is cancelled, the Hub Tokens are released back to the address that pledged them originally and can be used to support other features or even other projects. The Hub Tokens do not officially change ownership until the acceptance testing is complete on the work item.
If Hub Tokens are the ecosystem’s fuel, Makers are the “autonomous as you want to be” engines that bring the desired products to the rest of the SAFE Network.
##Building Your Resume of Trust
While reputation and credentials outside the Hub community will be important to have and maintain, Makers of all types will be incentivized to build their reputation as competent and trustworthy participants in Hub-related activity. It is envisioned that even a pseudonymous Maker will be able to fetch excellent exchange for contributions, based solely upon a track record built within the Hub ecosystem. This will open the doors for contribution from a tremendous pool of talent who, while laboring in freedom, can start from nowhere and build their portfolio based upon trustworthiness and value-added contributions. It is likely that being able to demonstrate a good resume of contribution and trust through Hub activity will be valuable elsewhere, as well.
##Investing in Makers
Makers, as part of their compensation for tasks done, will receive Hub Tokens as well as other project-specific exchange, such as project tokens for specific projects worked on. In the long run, we hope this will be quite an adequate exchange so as to allow eventual “full-time” making. That being said, timing of that compensation may be a barrier to pursuing Hub project work full time at the beginning. This provides an opportunity for those who lack the time, talent or inclination to work as Makers within the Hub environment to potentially invest in and receive a return by supporting the Makers themselves. Remember that aside from those Hub Tokens distributed during the initial crowd sale, all further Hub Fuel will be generated only as compensation directly to Makers (and Recognized Contributors) in exchange for valuable tasks accomplished. The value of the tokens will be established by the open market (e.g., by way of the SAFE Exchange). Makers who earn through project production will be able to contract with investors for ongoing or episodic support, in exchange for an agreed-upon percentage or quantity of token earnings by the Maker. With Maker reputations on the line and smart contracts, we believe mutual agreements between parties can be customized to meet everyone’s expectations fairly.
##A Note on Junior Developers and PtP/PtD
If PtP (see SAFE Network feature “Pay the Producer/Developer) is implemented and the Hub receives safecoin rewards as a result, those rewards will be invested into junior developers who show promise. The contracts made with them will require that they work on Hub projects for a specific time period, or to a defined result, in exchange for the pay they would receive. The contracts with these junior developers will NOT require that a portion of their earning are passed back to the Hub. This might allow them to use those Hub Tokens, and project incentives they receive, to pay for education or pairing partners who are more experienced so they can get up to speed as fast as possible. Whatever they decide to do, the goal of this will be to help them become independent. Even if PtP isn’t implemented, we think others will see this model or a model similar to this or similar models as an example to invest in as well.
#Core Features of the Hub
- the ability to create proposals for new community projects in a language that connects the expert engineers with the community as a whole
- filterable list of project ideas (popularity, activity level, category, work items, no. of workers, creation dates, percent complete, etc.)
- project community hub (a dashboard of sorts with links to project details and communication pages)
- project ideation (defining the initial idea - including the business plan, resource estimation planning, mvp definition, etc)
- the ability to create new proposals for new features on existing projects (controlled by the existing community or open to everyone)
- voting on ideas and features
- filterable Maker resume listing
- the ability to crowdfund community project MVPs (might include, but not limited to templates and commonly used crowd funding patterns)
- the ability to crowdfund Maker tokens (might include, but not limited to templates and commonly used crowd funding patterns)
- hub project Maker payment algorithm for creating and paying hub tokens for work item completion
- the ability for projects to create work items and associating worker payments to them (bounties, contracts, etc.)
- a library of customizable smart contracts to enable projects to accomplish the above goals
- a community marketplace where developers can offer their own add-ons for projects to use within the hub
- other things we have yet to think about
#Expanding the Ecosystem with Community Developed Features
We want to support other projects that are working towards making the SAFE Network great. I have every intention to include these protocols and projects (@Seneca‘s Decorum protocol and @dallyshalla‘s SafeX) as well as any yet to be revealed projects, when and where they make sense. Along with using these, we will allow the community to incorporate their own feature add-ons for projects to use. These features could have their own suggested donation of hub tokens and the add-on developers would receive those donations for a period of time the developers determine. After that time has expired, the features would work like any other feature within the hub and the donations would be included in the hub project worker payment algorithm.
#Open Issues for Deeper Discussion
The number of Hub Tokens and the upper limit release algorithm is the least finished idea we are currently struggling with, though other seemingly insuperable obstacles have already been dealt with. It doesn’t need to be figured out right away, but it will need to be figured out and tested thoroughly and then the algorithm would be set in stone from that time onward.
##The Hub Token Release Algorithm
Because the hub is an ecosystem, pieces of data are known and can help us develop a powerful algorithm for the release of new hub tokens. Maker/Work Item Ratio (MWIR) would be known, so using supply/demand laws is possible. If more workers are needed, then higher hub token creation. If less workers are needed, then lower the hub token creation. We also know the total number of tokens that exist out in the wild and the average number of token throughput for any time period. With past history we can develop ongoing future forecasts and create new tokens accordingly. The number of tokens created would become less and less over time. (We need ideas and input to flesh this out. I.e., should there be a burn/recycle aspect? Should the supply be unlimited/limited?, etc. See below.)
###Things to Consider
There needs to be enough tokens to allow people to easily use them for projects. There can’t be too many tokens or the incentive value for workers will vanish. The release of tokens has to be in line with the number of new projects, features and actions (how many tokens people are using and a forecast of how many will be used in the near future). The tokens should increase in value over time. If token value increases over time they should be divisible so people can always afford to do actions with them.
####What is the problem with creating hub tokens?
- Increasing the number of tokens beyond their use will cause inflation and the incentives they are meant to produce will vanish.
####Is there a theoretical sweet spot for the number of tokens that should be in existence at any given time?
- Won’t know until we see how easily and often people use them.
- Perhaps this is the key to the algorithm?
####Should the total supply that will ever exist be time targeted?
- If the total supply is time based then the algorithm can make sure to limit the number created every day/week/month or whatever time interval we set.
- We could also set it up like bitcoin in that the number of them increases or decreases based on where we are in time.
##Why not safecoin in place of the Hub Tokens?
- Pro (perhaps): Less Friction
- Pro: Much simpler to implement (possibly)
- Con: Requiring peeps to use their “precious” safecoins might suck for some. Safecoins already have a utility function and that is to pay for data “PUTS”. Now if they want to invest in a project they have to give up safecoins.
- Con: No algorithm levers to govern the number of Project Utility Tokens (not a real issue unless the value of safe goes significantly higher/lower in a short time, which it probably will)
- Con: No EASY way to do a crowd sale to bring this project into existence in a “quick” full time way.
- Con: Kills the idea of supporting a maker to receive hub tokens.
- Con: Narrows the value channel into Hub Tokens, forcing everything through safecoin, rather than other, more direct swaps. This is actually a big minus. Via SafeX most cross value swaps will be possible.
##Bad Actor Protection
In Bitcoin, the miners are incentivised to be good actors because it just takes more resources to try to break the system than it would be to use those same resources to be rewarded to mine the way the system is intended. We need a way to incentivize all collaborators to be good actors or at the very least protect against bad actors.
If I wanted to be a bad actor in this ecosystem I could create a pseudo project and false makers. I could then support fake features and build fake work items and complete them with my fake makers. The Hub would create the extra (bonus) tokens and pass them onto the fake makers. It would be obvious to almost anyone looking at the project to know this is going on (source code, project collaborators, ideation, etc.) but it wouldn’t be obvious to the Hub. Now add the fact that a programmer could build a bot to create fake projects and makers and do this without any kind of human interaction.
We believe the Hub Creation/Release algorithm could be setup to only work if a large portion of its collaborators are known as good actors on existing projects. It’s still possible, though harder for a bad actor to play nice for a while and then start a scheme. More likely a group of real actors could work together to make this possible - perhaps running a scam on a larger population of Hub members. This good/bad actor decision could be done through connectivity characteristics of the existing hub social graph which would limit the extent of damage that could be caused by a given Sybil attacker while preserving anonymity, though these techniques could not prevent Sybil attacks entirely, and may be vulnerable to widespread small-scale Sybil attacks, we believe this would build a solid web of trust for the Hub ecosystem to be safe (for more information please see Sybilguard).