Aragon Nest Proposal: Open source incentivization app for Aragon

[luisivan]

Aragon Nest Proposal: Open source incentivization app for Aragon

Abstract

Blockchains were born to solve the Tragedy of the Commons problem. All blockchains work because nodes are running some software that makes consensus possible. But maintaining software is hard. Ironically, many of these blockchains are suffering a tragedy of the commons scenario where developers are not correctly incentivized to enhance the protocols and implementations that make it work. And that's even worse in normal open source projects where no skin in the game exists in monetary terms.

Open source is not self-sustainable at this point. Some of the business models around it that we have seen in the past include:

• Selling support or consultancy services around an open source product
• Selling pro services not included in the core open source implementation
• Doing a token sale and deploying your own token which interacts or provides some value add to those using the open source product and having the token

Problem with all those is that they require external elements that make the core team or maintainers lose focus, and can also sometimes misalign incentives. For example, you'd want your open source implementation to be as basic as possible to people resort to consulting with you for custom solutions, buying the pro services, or buying the token that unlocks some value add. Therefore, corrupting the interest of the project itself.

The solution is truly community-run open source projects. We propose using governance tokens to provide sustainable funding for open source projects in a way that perfectly aligns the maintainers, contributors and community incentives, by implementing a decentralized Git repo as an aragonOS app.

This is enabled by two components:

• Aragon: By using Aragon, a token can be created for governance purposes, and different governance mechanisms could be put in place in order to incentivize the interests of the community
• Decentralized Git repo app: The core resource of an open source project is its source code. By using Aragon's governance mechanisms, the community could decide who are the maintainers, who is allowed to merge pull requests and how are those all rewarded.

Deliverables

1. A decentralized Git repo app compatible with aragonOS, exposing roles for curating issues, opening PRs, merging PRs, naming maintainers, setting bounties to issues and triggering events when each of those should be rewarded.
2. A GitHub-alike frontend for it
3. Ideally, implement everything described in the OpenCollab whitepaper

Grant size

Funding: From $50k Up to $100k in ETH, split into chunks paid out over achieved deliverables.

Success reward: Up to $50k in ANT, given out when all deliverables are ready.

Application requirements

• Proof of concept of the smart contracts for the decentralized Git repo as an aragonOS app. Alternatively, a whitepaper researching the implementation of the whole stack
• Details of the team members, alongside with their willingness in terms of implication
• Estimated average burn rate for completing the deliverables
• Legal structure to be adopted, if any

Development timeline

Testnet launch will be expected during Q1, with mainnet launch being Q2.

[osarrouy]

Hi guys,

I had launched the idea of submitting an aragon-based decentralized git implementation in a discussion with @Smokyish on RocketChat a few weeks ago.

My team and I are currently working on wespr - www.wespr.co - which would provide a global infrastructure to help content creators collaborate and share ownership over their work. To do so we are currently designing a decentralized git app based on IPFS and aragonOS (as an aragonOS app).

I don't know if this proposal is a real one - as it comes from @luisivan and does not seem complete - but if it is we would be glad joining our effort. And if it's not we would be glad submitting a grant proposal.

Let me know and thanks again for your amazing work on Aragon!

[luisivan]

It is indeed a real proposal! @osarrouy you should totally apply for this grant. Process is here: http://wiki.aragon.one/nest/guides/guide_for_submitting_a_request_for_funding/

[osarrouy]

Thanks @luisivan. I'm gonna work on this submission ASAP ! Thanks again.

[stellarmagnet]

This project sounds amazing & exciting and one I am passionate about, but really really massive. Kind of like an entire "ICO"-type company in & of itself or one that would need to use "governance tokens to provide sustainable funding for open source projects in a way that perfectly aligns the maintainers, contributors and community incentives"

"Ideally, implement everything described in the OpenCollab whitepaper"
Is Q1 testnet and Q2 mainnet really realistic for a project with such a large scope of work of looking like github, having all features like commenting etc too in addition to the tokenization?

I know it says ideally, but I actually have problems with this OpenCollab suggestion because I don't think this document describes the best roadmap for such a product that will solve the problem statement.

Additionally, wouldn't something with more flexible governance for how things are merged be potentially better?

I think for the scope of a $100k grant, perhaps it needs to be broken down in priority order as follows:

1. developing a decentralized github replacement atop aragonOS first & foremost
2. focus on what I think are solving the top tokenized governance issues for open source software development-
   a) prioritizing tasks/roadmap via tokens (like ALP02: Token-weighted Github Issue Prioritization  labs#2)
   b) collectively deciding how many tokens each issue is worth
   c) allocating bounties & tracking reputation (nice to have - perhaps subsequent grant)

[If you think about it -- you realize how I said "top tokenized governance issues" is an example of why having those features first is important, since other people can also decide if they agree or disagree with these being the top concerns. since these ideas would come up in 'gitdao' like it just happened this moment.]

Items a & b above are ones that require more collective decision-making across all token holders in the ecosystem, regardless of understanding code. I think the harder process is usually deciding if that feature should even be developed in the first place and then budgeting for that development work, before the merge request even comes into play. The OpenCollab paper lightly touches upon curation.

If we are trying to solve the problem of people being paid for their work before coding occurs, then we need to solve tokenized prioritization of features first and foremost, before we get into tokenized pull/merge requests. But ideally the task management system should be part of the git system. Having two different Nest teams for git merge requests vs task management will not be a good use of this funding either... unless they closely collaborate on the same app. so I am suggesting we think about the building blocks and perhaps prioritize features of this git replacement for something that can actually be accomplished in such a short period of time - it needs more of a "lean" approach.

the other alternative is you have 3 teams, with 100k grants each that are working together.

1 team of designers / product managers (100k)
2 teams of developers (200k)

The design/PM team does the UI and writes the specs. They present it to the Aragon community before development begins.

This gets approved, then you go to the development level. This can also be agile... where there are design reviews w/ the community every 2 weeks.

One dev team is focused on - replace github / build the front end, with commenting and advanced markdown stuff.

The other dev team is focused on integrating the smart contracts between the aragonOS/voting dapp and the gitdao tool. suggested priority order:
a) permissions/roles - this feeds into all of the smart contracts use cases below, and hence should be thought about first.
b) tokenized prioritization of a product roadmap
c) bounty system
d) reputation system (and how that ties to your work being merged)
e) merge requests that have governance

[osarrouy]

@stellarmagnet I do agree that there are many issues here which need to be thought and solved before diving into code.

We at wespr have been thinking a long time about that - althought our WP is not formalized yet - and maybe we could share our thoughts ?

What about opening a gitter or a specific channel on our slack to collectively discuss these issues further ?

EDIT : I've just created a distributed-git channel our on slack. Feel free to come in. We can also move it to gitter if it feels more confortable to anyone.

[osarrouy]

Let's start the discussion here before we eventually move it somewhere else to allow something more fluid :)

I also agree that there are two different problems here which are not equally complex:

a. building an distributed github-like plateform based on ipfs / swarm and introducing hooks to enforce a token-based governance. This platform should by itself be policy agnostic. This way, we introduce a separation of concern between the version control infrastructure and the governance infrastructure - allowing modularity and freedom in the design of the governance policy.

b. building the modular smart-contracts - as aragonOS apps - enforcing the governance policy.

Task a is quite « easy ». There is already a lot of tools out there to rely on: Mango, ipld-git and so on. There's work to do, of course, but i don't think such a task raises a lot of issues.

Task b on the other hand is quite fiddly. I just drop a few questions here that, IMO, needs to be discussed:

• With the actual proposal only the new contributions to a project get rewarded. This introduces a bias in the valuation of a project as only fast moving projects get rewarded. Though the fact is : a stable project which gets a lot of use and / or forks is still a valuable project that brings value to the community - althought it won't be rewarded in the current proposal. This raises at least two issues:
  a. This model does not offer sustainability for slow moving but valuable project. Don't we need to find a way to also reward forks, clones, etc. ? b. This introduces an arbitrary incentive to artificially push unnecessary changes to a repo just to get rewarded.
  All of this is a question of time: how can we think a rewarding process which does not arbitrarily reward short time turmoil, but also long time commitment. My point is: we have, somehow, to introduce time as a parameter to rewards.

• The way things are thoughts here only allow for a very linear ex ante dev roadmap where tasks -
  and their according rewards - are collectively set before they are solve through a PR. But what about spontaneous PR where people propose code enhancements or bug corrections without it referring to any previous roadmap entry ? To keep things as liquid and agile as possible, we have to find a way to let the community and the contributor set a reward ex post. A curved bounding mechanism could be a good starting point : see this post to deep further in the question.

[stellarmagnet]

@osarrouy My team will also be applying for this grant as incentivized open source development is something we have also been thinking about a lot - so I guess let's just see how this plays out the next few weeks.

It'd also be good if you had details on your website about who your team is.

[yondonfu]

Writer of the OpenCollab paper here - awesome to see this grant and the interest in working on alternative incentive mechanisms for general open source development! To clarify, the scheme described in the OpenCollab paper is very much a proof of concept - it is not a full fledged solution to the problem at hand, but rather a proposal providing a glimpse of a different way to approach sustainable open source with the advent of new cryptoeconomic primitives. As it has been pointed out in previous comments, as is, the scheme described does have some flaws. Here are some of my thoughts...

I think the harder process is usually deciding if that feature should even be developed in the first place and then budgeting for that development work, before the merge request even comes into play

Great point - the idea behind token based staking/curation is to allow token holders to participate in the prioritization of the project roadmap such that there is a transparent view of what the project community perceives to be the most important items to prioritize. The goal here is that potential contributors can observe community signals before development starts.

Small related addendum to that...there is a flaw in the rewards only being available for a merged pull request in the case of larger feature implementations. There ends up being a lot of uncertainty for any potential contributors that want to tackle the feature request especially if the development timeline is long. These types of contributors might be a better fit for grant-like funding with smaller releases of funds based on specific milestones with the largest release for a successful merge.

This introduces an arbitrary incentive to artificially push unnecessary changes to a repo just to get rewarded

Unnecessary changes to a repo would run counter to the desires of token holders (i.e. maintainers, users that want to influence the roadmap of the project) given that the token's primary utility is for the proper governance of the project itself. Honest maintainers have an incentive to reject such pull requests to preserve the quality of the project - if at a certain point the quality of project falls to low enough levels from bad upkeep, token holders likely would choose to exit the system and perhaps fork off. A malicious maintainer might try to collude with the pull request submitter to jointly capture the rewards for a successful merge, so there needs to be some sort of backstop that allows other honest token holders to intervene. The initial solution proposed by the paper is a challenge mechanism resolved by a quorum of votes - if the challenge is successful, the maintainer is booted out and loses the future economic value associated with being a maintainer. Of course this is just a starting idea, would love to hear more thoughts.

To keep things as liquid and agile as possible, we have to find a way to let the community and the contributor set a reward ex post

Totally agree that this is important. Perhaps the curation/staking process can be adapted to target open PRs as well in addition to issues on the project roadmap. So if a hotfix or urgent feature update PR is pushed up that was not originally on the roadmap, token holders can on the spot evaluate the importance the PR by staking rather than forcing the PR to be associated with an already existing roadmap issue.

Task a is quite « easy ». There is already a lot of tools out there to rely on: Mango, ipld-git and so on. There's work to do, of course, but i don't think such a task raises a lot of issues.

Note that until Filecoin and Swarm's incentive layer are in production, none of the current decentralized storage systems offer any guarantee of data persistence unless you run the nodes yourself and host the data. In this case, you end up back with a single party responsible for the uptime of repository data.

[osarrouy]

Hi @stellarmagnet. I do understand that we will « compete » for the same grant but whatever happens we are talking about an open-source project which is supposed to benefit the whole community and raises a lot of complicated issues. I really think we would all gain sharing our thoughts because i don't think all the intelligence of the world will be concentrated in neither of our teams :) But i do understand. I will continue the conversation here. Feel free to come back whenever you want. And concerning our team it will be public soon - and it's a really great one :)

@yondonfu Glad to see you joining the conversation. Here a my thoughts - bouncing back on yours in an apparent disorder ;)

Note that until Filecoin and Swarm's incentive layer are in production, none of the current decentralized storage systems offer any guarantee of data persistence unless you run the nodes yourself and host the data. In this case, you end up back with a single party responsible for the uptime of repository data.

Sure, that's a problem. But it's a community-wide problem - not related to this specific project - and my thought is that, for now, we sould make « as if » these incentivization layers did exist and cheat by running our own IPFS nodes ... As soon as Filecoin is live we just have to enter the game and data will get replicated and gain a guarantee of persistance. So: let's pretend it's not a problem even if it is one ;)

Great point - the idea behind token based staking/curation is to allow token holders to participate in the prioritization of the project roadmap such that there is a transparent view of what the project community perceives to be the most important items to prioritize. The goal here is that potential contributors can observe community signals before development starts.

Maybe we need to clarify a point here - and maybe @luisivan and @mariapao could enlighten us about that too. I'm not sure what the purpose of this grant proposal really is : a. creating a token-driven governance protocol or b. also offering a remuneration perspective for open source and / or free access creative projects.

My opinion is - but maybe I'm wrong : if we really do want to offer self-sustainability to Open Source Projects and Open Access Creative Contents we do need to find a way to offer them some kind of a « stable income ». Otherwise how do we incentivize maintainers to do their maintainer's job ? If we don't do that, we risk to drive OSS projects towards the same issues we are trying to bypass: the need for an external source of income.

If we do follow this approach, the question becomes: how to offer a « value » to OSS projects which are, by definition, free and open. Our approach at wespr - but that's really a point we need to discuss - is to make use of a twisted curve bonding approach.

The basic idea beyond curve bonding is to allow people speculate on the value of an asset ... thus fixing it's value - or more precisely: thus backing the perceived value of this asset with actual currency.

To do so you just have to fix two curves of value: the first setting the buy price a tokenized-piece of this asset respecting a given parameter - e.g. the number of tokens already sold - and the second one setting the sell price of this asset given the same parameter. This idea is that at any given point, the sell price is inferior to the buy price, so that to make profit, people have to make a bet on the future of this asset - e.g. more people will be willing to buy some of this tokens.

For now, most curve bonding approach rely on a sole parameter : the number of tokens already sold. But we could imagine a process where these bounding curve could take as a parameter what the community think reflects its value : the number of download, clones, forks, contributions, and so one. This would allow us to back a project according to the belief people have in how this project will evolve in time, how much appropriation it will get, how much people will use it and so on.

There would be a lot more to say about that but i'd be happy to hear community's thought about that first ...

There ends up being a lot of uncertainty for any potential contributors that want to tackle the feature request especially if the development timeline is long.

Totally agree. I think this is a real issue. More generally this points toward the need for a modular approach. I'm not sure we can anticipate on all the use cases such a project could spark. Thus, my opinion is that we should design a really abstract and modular governance process. On top of that we could provide a few plugins to handle the most generic use cases. But we could also offer the community an opportunity to design more suited plugins to handle their specific use-cases - which will not be the same for small and big projects, long term and short term projects, and so on.

I think the aragonOS approach is well suited to handle such a modular approach. Basically we should design our app so that it could easily grant decision rights to other apps which could then handle the specificity of each use case. I'd be happy to hear your thoughts about that.

The initial solution proposed by the paper is a challenge mechanism resolved by a quorum of votes - if the challenge is successful, the maintainer is booted out and loses the future economic value associated with being a maintainer. Of course this is just a starting idea, would love to hear more thoughts.

Well in some way we are talking about a kind of curation market. A lot of discussions about such curation markets are happening here. There would be a lot to say about that ! IMO the main problem such a solution would raise is the need for a large contributor / userbase. Curation markets won't work for smaller projects where the risk of collusion is more important and the probability of challengers showing up is low. I dont really know how to handle this problem right now but i guess this strengthen the need for a modular approach: curation markets will be useless and too rigid for « small » projects - though they would be perfect to maintain React or other huge projects of this type ...

[stellarmagnet]

@osarrouy My response to whatever is being discussed here is best described in a detailed project plan / proposal! I am trying to work on that & then will share it. The proposal does actually discuss this entire project being community driven -- cooperative as opposed to competitive :) Stay tuned. I'm just trying to find time to download the contents of my brain in the next few days.

[stellarmagnet]

Okay i couldn't fall asleep... here are some of the ideas :)

Use Nest #3 as a test DAO grant. The deliverables can be developed & designed by multiple communities / stakeholders. This tool will be developed by a new Aragon DAO that will operate on testnet using Aragon v0.5.

Proposed steps:

1. Create a repository for this project on GitHub
2. Create a roadmap via GitHub Issues on current thoughts & ideas in the thread + OpenCollab paper
3. Have a meeting with the initial early adopters of the tool (such as ones in this convo) and prioritize the roadmap thinking about “first principles”
   • Determine when & where standards such as StandardBounties (https://github.com/ConsenSys/StandardBounties) or token curated registries should be used for this tool.
4. From the prioritized roadmap and $100k budget, determine what % of the tasks should be done by full-time, which % by part-time (20hrs a week), and which % by consultants/crowd
   • Identify roles needed to accomplish the roadmap (skill + expertise level)
   • Workers apply to fill the roles (individuals or teams)
   • If there is more demand for the roles than available positions, the Aragon/Placeholder/Aragon Network selects from the applicants to fill the full-time, part-time etc role.
5. Allocate the $100k (in ETH) that is awarded for the grant across each of the tasks in the roadmap. Use Status Open Bounty or Gitcoin for budgeting ETH to tasks. This allows us to learn, improve & collaborate with existing git bounty tools, while building the decentralized bounty tool 😃 [maybe the communities will all come together? but, may need to make sure the tools support pre-selecting ppl assigned to some of the tasks]
6. In addition to the $100k in ETH, each contributor also gets governance tokens for the tool as it is an Aragon DAO (and, well, it's ultimately the token that enables merging etc).
7. Outsiders can contribute to the development of the roadmap (lower priority items) and earn the governance tokens, or other community members can stake ETH against the tasks.
8. If the team wins the $50k success reward, it’ll be distributed via a collective decision making process to determine who gets what % of it, using Aragon on Mainnet.

But before this process begins - need to agree on what the governance of the DAO would be 😃

How do we keep the vehicle going so the git project can continue to be funded/maintained? Maybe create a consortium of hundreds of DAOs that need the tool, bc it’s their IT infrastructure. They funnel funds from their DAO to make sure the tool survives, in addition to contributing to the code - perhaps trading hats on who the “repo maintainer” of the month is.

Basically what I think will happen this year, is there will be some kind of treasury DAO for the Ethereum ecosystem especially now that Aragon will be going live. I think it's totally fine if it's test tokens and external custodians allocating ETH too to begin with. Nest seems to be one of the first examples I have seen that is funneling large amounts of money toward common tools, using a community governed process. More companies can & will follow Aragon’s lead. What we can do as a community is help facilitate, organize, & spread the word - so this pooling of money is more centralized, yet managed by a decentralized entity whose mission is to develop common building blocks - so we can do more collaboratively across the ecosystem. I think what will happen is then you will see tools that will have more interoperable designs, in addition to becoming more secure and robust.

[luisivan]

Just wanted to jump in and say that this is intended to be a very open grant proposal, so if we do have teams applying with a sightly different direction, that's okay. I'd argue it's even better, as it's kind of a hedging strategy -- aka attacking a problem from different angles guarantees the probabilities of it being solved go up.

@stellarmagnet it is also totally doable to have multiple teams focusing on different parts of the problem applying.

As for the intention of the proposal @osarrouy, it's both a and b. Basically we achieve b (sustainability for open source projects) by implementing a (tokens with governance powers that should accrue value and incentivize all involved parties).

For the actual application process, please feel free to ask any questions, either to @mariapao or me directly (we're on https://aragon.chat)

[owocki]

hi from gitcoin.co and thanks @luisivan for the tag.

there are a few approaches that are spiritually similar to nest proposal: Fund Request Token, Git Token, OSCoin, Utopian.io, Gitcoin.co, Status Open Bounty being a few. i'm hopeful that we can all work together. as OP articulated so clearly above, the blockchains have the potential to solve tragedy of the problems and what bigger / more important problem out there than open source sustainability?

i'd note that one area where gitcoin took a different route than this proposal is that this posposal will be "building a distributed github-like platform", gitcoin chose to just use github for this part of the stack. this is a reflection of the reality that 99% of open source projects use github for hosting, and we didn't want to boil the ocean to start.

we also have our own thread for 'ideas for sustaining open source software at scale' .
feel free to check it out and borrow any of the ideas: gitcoinco/skunkworks#27

@luisivan i hear you (or at least some of your team) is gonna be at ETHDenver.com in mid February and perhaps the after party too? i'd love to nerd out about this a little bit there. i'll make a point of reading the OpenCollab whitepaper between now and then.

tagging @coderberry of codesponsor.io who may have ideas and will also be at ETHDenver.com

meantime, let me know if/how i can help. happy to help validate any portions of specific proposals. gitcoin.co may be in a unique position to do so in that we've been live for 3 months and have a bunch of data about what works and what does.

best,
kevin @owocki

[luisivan]

@owocki I won't be at ETHDenver, but @izqui will be! :)

Thanks for offering yourself to help validating ideas and proposals, I'm sure your insights could be helpful for @osarrouy @stellarmagnet

[macor161]

Hi! I just came across the Nest program, it's a pretty cool initiative!

I've been working part time on a small app called Exposito, it's not much but I think it would maybe fit this grant. The idea is to let people run an open source project as a DAO­.

On the website, I replaced DAO with "startup" because I realized not a lot of people outside the crypto community knows what a DAO is. hehe. Anyway, my app aims to let people easily set up a governance model by creating a token for their open source project. It provides different incentives for developers, like grants and rewards. But the main one is that each developer receives a number of tokens coresponding to the number of lines of code he/she contributed to the project. The more you contribute, the more you become an influencial "shareholder" of the project. And there are also monetization tools than I plan on making available.

The app is far from finished, it's working with Github right now and to be honest, I was planning of adding a decentralized git hosting module only later, in a version 2 or 3. But I can put on pause the development of the monetization tools and focus on git for a release in Q3-Q4.

I'm sure there are other projects related to this grant that are way more advanced than mine but I would still be interested in hearing what you think of it so I can improve some features. Of course, it would be quite nice to be able to work full time on this project and to continue contributing to the Aragon and Ethereum community.

[luisivan]

@macor161 deleted your last comment, please do only comment things relevant to this conversation. Otherwise, feel free to apply for the grant!

[john-light]

Sharing this GitTorrent repo here as a reference for anyone interested:

https://github.com/cjb/GitTorrent

I imagine that this project would use ENS for name -> hash mapping instead of Bitcoin OP_RETURN since it is an Ethereum ecosystem project.

Edit Feb 7 2018 Speaking of oscoin, they just announced closing a funding round: http://oscoin.io/updates/1.html

[yondonfu]

@osarrouy A few responses below! Hope they're helpful

My opinion is - but maybe I'm wrong : if we really do want to offer self-sustainability to Open Source Projects and Open Access Creative Contents we do need to find a way to offer them some kind of a « stable income »

I echo the comments made by @luisivan on leveraging governance tokens as a way to fund projects in a way that aligns the longer term incentives of the project community. Although project funding is without a doubt for many classes of open source projects (especially those that fall into the awkward area of the spectrum where they are too big to be maintained by 1-2 people working one weekend out of the month, but too small or niche to attract the sponsorship of a large company with ample financial reserves or large scale donations), I think the bigger open question is how to fund projects in a way such that even if key participants leave today, the incentives are structured that if there is sufficient community interest, project maintenance continues undisturbed. If it was just about getting more funding into the system, regular bounties and grants would suffice, but funding is just one component in the larger open source sustainability problem (there have even been cases of projects that actually do receive some funding, but the maintainers are uncertain of how to actually use it efficiently - perhaps the utility of governance tokens can come in here).

But we could imagine a process where these bounding curve could take as a parameter what the community think reflects its value : the number of download, clones, forks, contributions, and so one.

I like the idea of taking into account additional factors that might signal the health/interest in a project, but I would be wary of using metrics such as number of downloads, clones and forks because those are easily gameable. Contributions could be interesting - the defense against gameability there would likely have to rely on whatever the mechanism used for accepting a contribution and merging it into the main codebase. Another potentially interesting one is the number of projects that actively use this project as a dependency.

You might even want to also take into account these parameters for the reward calculation - perhaps past contributions affect current contributions to start creating a path toward becoming a regular contributor as opposed to a drive by contributor.

I dont really know how to handle this problem right now but i guess this strengthen the need for a modular approach: curation markets will be useless and too rigid for « small » projects - though they would be perfect to maintain React or other huge projects of this type ...

Agreed! I think it is a good idea to take a modular approach and focus/test perhaps with a specific type of project in mind first, validate or disprove the proposed model in that scenario and then expand from there.

[osarrouy]

Hi @yondonfu

Thanks for your answer. Some thoughts about that.

I echo the comments made by @luisivan on leveraging governance tokens as a way to fund projects in a way that aligns the longer term incentives of the project community

I really think - but maybe i'm wrong - that we need to make use of two different tokens to : a. fund the project and b. govern the project. The main reason for this differenciation is that the remuneration token must be fungible - because otherwise ... well, it's of no help :) - while the governance token must NOT be fungible - because otherwise any wealthy person could « buy » a decision right in any project and thus influence its direction given a profit-only rationality.

If we do wanna avoid, in the blockchain era, the mistakes made by the « company era », i think it's really important to give back the power to the real contributors, while leaving investors do what they do best : valuating a project by speculating on it - but not taking decision on its future.

So the only way to gain governance token MUST be the contribution and not the exchange market.

If it was just about getting more funding into the system, regular bounties and grants would suffice

Sure but the whole idea - IMO - is to find a way to get OSS self-sustainable ... and so to avoid the necessity of an external grant mechanism :)

I think the bigger open question is how to fund projects in a way such that even if key participants leave today, the incentives are structured that if there is sufficient community interest, project maintenance continues undisturbed.

That's a good point. But what about the fork logic ? After all, if a project just stops evolving, nothing stops you from creating a fork and driving the community to work on this fork, right ? I would be glad to hear your thoughts about that ...

I like the idea of taking into account additional factors that might signal the health/interest in a project, but I would be wary of using metrics such as number of downloads, clones and forks because those are easily gameable.

Well in fact there already exists a lot of algorithm to spot such gamed signals - the same algorithms Yelp or TripAdvisor, for instance, use to spot false evaluations. We've been discussing a lot about that with the rest of our team. The main problems are:

a. Such algorithms are not compatible with Ethereum scalability and costs. We could think of a way to make the calculus off chain and check it on chain - as Colony does for its reputation algorithm - to lower the costs. But such a solution still need to store all the foundation datas - number of downloads, views, etc - on-chain, which is really too expensive for now. We have been looking for post-blockchain solutions to solve that problem and are in touch with the guys from holochain, but this would require a cross-blockchain communication layer and make all stuff much more complicated.

b. If we want the community to have power over this remuneration algorithm, we do need to keep things as simple and readable as possible - otherwise no one will understand how remuneration works and how to tune the algorithm.

The solution we are working on right now - and which we hope to share with you as soon as we find time to finish our WP :) - is to use some kind of tweaked curve bonding to valuate the project.

Users would only have to stake ETH to buy a given project's bond and expect that, if this project works, these bonds they've bought will gain value overtime. The tweak, in our project, is that these curving bonds take a time parameter. That is: you stake ETH for a given time lapse where you won't be able to sell your bonds back. The idea is that the more ETH are staken for a long period - and thus with more uncertainty - the more this project is valuable - because people seem to trust it in the long term.

So the remuneration a project gets depends on the VALUE * STAKE TIME.

In this way we do use speculation to value the project in the long term - minting remuneration token given the VALUE * STAKE TIME INPUT - while still differenciating the remuneration token, the governance token and the speculation token.

What do you think about that ?

Another potentially interesting one is the number of projects that actively use this project as a dependency

That's part of our project. Forked projects would get remunerated by their children projects. More on that as soon as our WP is more advanced :)

PS : @stellarmagnet I will answer soon about the points you raised but i'm kind of running out of time right now :(

[lftherios]

Hey from oscoin & thank you @luisivan for the link.

My name is Eleftherios and together with @cloudhead we are working on http://oscoin.io In comparison to other projects in the space, we are currently focused on building a decentralized infrastructure for code hosting & collaboration. We consider this a prerequisite for potential innovations on the governance and incentivization layer, so we decided to address it ourselves.

We recently published our first update and announced our roadmap http://oscoin.io/updates/1.html We are always open to collaborate with folks, provide feedback or hang out, so if you are working on something similar please reach out.

[luisivan]

Thanks for dropping by @lftherios!

we are currently focused on building a decentralized infrastructure for code hosting & collaboration. We consider this a prerequisite for potential innovations on the governance and incentivization layer

I totally agree with this, and while I like the intention behind the tools that are sort of bridging crypto with GitHub, I like this approach more.

[osarrouy]

Hi @lftherios !

we are currently focused on building a decentralized infrastructure for code hosting & collaboration. We consider this a prerequisite for potential innovations on the governance and incentivization layer

Totally agree. Not sure what kind of way you're taking on that but maybe we could join our effort concerning that part of the work.

On our side we have decided not to fully reproduce git over IPFS / Ethereum as it would be a redundant layer over what IPFS already offers: native CID, de-duplication system, and so on.

So we are working on git-like protocol relying on the inner characteristic of IPFS through an IPLD tree describing any given repo.

The control-mechanism will be enforced by a set of AragonOS based smart contracts as this really offers what we need regarding Role enforcement - and the ability to abstract role behind smart contract to enforce governance mechanism such as voting and so on.

Don"t know if its the way you're following, but if it is, drop us a line so that we can join our effort instead of scattering our man power on various redundant projects.

[osarrouy]

Hi everyone,

Just a few words to give you some news.

I have spent the past week developing a small PoC for a distributed versioning system based on IPFS and AragonOS: https://github.com/wespr/pando

It's not that much: commits have no granularity, they just have one parent, you can't merge repo and governance roles are just limited to granting a PUSH right ...To make a clear, that's just a PoC showing how easy it is to develop a powerful versioning system leveraging the inner power of IPFS and AragonOS.

Feel free to test it and drop open an issue if you wanna discuss about it. If you just wanna have a look here is a short screencast showing Pando in action : https://www.youtube.com/watch?v=lOcElty7zIw

My team and I are now gonna work hard on the WP to discuss things further and polish the details of our governance protocols.

By the way, @luisivan and @mariapao, what kind of WP are you waiting for: do you need something entering into the technical details or just a more formal presentation of the protocols - meaning that you trust us when we say we're gonna be able to actually build it :)

Bests.

[mariapao]

I'm closing this proposal as a team working on this project was already funded: Pando