So a few years back, before I ever heard of MaidSafe (which was just the other day and I’m really excited about it), I was wracking my brain to come up with a way for a semi open remote team to work together and build new startups (open and closed source software and any type of startup) and be rewarded based on their individual effort.
This is the first "white paper” I sent out to a bunch of buddies who are also devs to see what they thought. I’m sharing it with our community to see if any of it could apply to the builders community we hope to develop within MaidSafe.
Here is a link to a proof of concept site I put together just to help people see the vision.
A set of tools to help startups share and build their next big thing along with others who are willing to help (with sweat or funding) for a share of the potential profits.
The original creator opens up a share of potential profits to people who will help advance the project through hard work (and/or investment capital - need to consider legal ramifications of this part, see JOBS act). The percentage of profits (not equity at this point) could be anything the owner decides. For the purposes of the project toolset the percent will probably be between 60-80% of the profits. This pot will be divided up by the number of points that it took to make it to the current iteration at the time the profit is realized or upon the agreed upon recurrence or specified date or anniversary date. Each contributor will be paid based on the number of points they finished over the life of the project.
For the purposes of the toolset this will probably be all profits realized monthly or yearly. Not sure yet how this will happen but we will try to make it easy for accounting as well as taxes.
Points & Estimation
Only developers who have worked on previous points can estimate items in the icebox (think pivotal tracker). Point estimation is done by a consensus process (see workflow below for a full description). Point estimation is done based on a relative point value system (estimation poker). Everything should be relative to development work already done.
Outside users, investors, and other interested parties along with developers will record bugs, feature requests and ideas (feature requests might be the same as ideas). These can be entered at anytime by anyone. This information is also viewable by anyone, though outsiders will see a limited amount.
Outside users will vote for their top desired features and bug fixes. They can also pledge or invest toward a bug or feature, though this will not guarantee it will be completed faster. For more information see Investment Pledges below…
Developers will go through items on the wishlist and give a developer vote on them along with their best relative estimation and maybe notes on why they are estimating it at that point value. This phase will be limited to a specific number of days. Anyone can change their estimation at anytime during this phase but other developer’s estimations are not seen at this point.
At the end of this phase outliers will be required to enter reasons for their estimation. If they fail to give reason by a specific cut-off their estimation will be excluded from consideration. Developers will put in a second estimation and repeat this step until all come to a consensus or a time when the dictator steps in, if things are at a standstill.
Once the wish list items are estimated developers will enter their vote on a theme for the iteration. Themes will be ordered and items matching those themes will be moved into it. The top voted theme will be worked on. Each iteration these themes can be moved around and redefined as things become clearer.
Developers can then pick items they would be willing to work on and should put together a list of reasons why they want to work on a specific item. If someone requests to work on an item and someone else wants to work on the same item they should pair up and work on the feature or bug together. Collaboration is a good thing! If you’re worried about points then take another feature as well.
The iteration starts and each developer is required to follow the Dev guidelines and integration processes laid out by the project owner.
Once the iteration is over people can anonymously enter retrospective items. What went good, bad, what do we want to see more of, less of.
Rinse and repeat…
Investment Pledges (not sure this is legal yet - see JOBS act)
Pledges are a way for non-content creators to get a stake in the company. Outsiders can pledge money for features and bug fixes or just in general. Monies received in this way will go toward the project costs (hosting, tools, etc) and then points would be awarded to the backer. Pledge amounts that exceed costs to run the site for the following 6 months would probably go back to the developers in the profit pool.
Why wouldn’t everyone receive these extra funds?
Because pledgers are investors and they are helping to pay for the development of the project. Backers will receive profits only from realized sales. (Not sure about this part yet.)
How are pledge points priced?
Not sure yet… But the cost of each point needs to be equivalent to or slightly less (because they won’t realize profit until sales) than the amount of effort a content creator puts in so that it is fair to everyone.
- Widgets or APIs for sites to include integrations into their own sites.
- Notification System
- Source Control Repository for code (use a private github or bitbucket account). This would work for otherassets as well (ie images, written work, etc) for non-software projects. Issue Tracker (will be a custom solution)
- Outside Voting (will be a custom solution)
- Inside Voting and Estimation Poker (will be a custom solution)
- Iteration Builder (will be a custom solution)
- Retrospective Management
- Some kind of IP manager
- Partnerships with startup servicing complies (legalzoom, etc)
How do you think the acceptance process for new content creators on a project might proceed? Right now for open source software it’s generally - make your fork, fix an issue, ask for a pull. In this case, it looks like you have to have permission before you can work on something.
User of project would follow a link that says “get involved - become a stakeholder”? then it would explain the process and what is available to help out with. >> user would agree to a contract and get access to the codebase or some of the codebase >> user would do their work and do a “pull request” which would then be checked out by a trusted member >> user might be asked to do some things then eventually added in if it works and matches guidelines >> user would do this a couple times before becoming a trusted member him/herself.
is the source and currently bugs/timeline always open to all, so a new dev could take shot at something before ‘signing on’?
sourcecode: people would have to agree to some kind of “I will not steal your IP” contract before accessing content. So it would not be a simple OSS fork process. Agreeing to the contract would give you access to the private repo or a portion of the private repository and then they could go from there…
Access to bugs, features, and timeline: These will always be available but there will be insider details not available to the public. Details such as Dev only comments, current estimation points, etc.