Incentives for developers of Aragon modules about client HOT 6 CLOSED

Great thread!

The idea about support tickets seems very nice, but let me play devil's advocate a bit: if a developer's main source of income is support tickets, it kind of incentivizes making the module look great at the beginning (to incentivize start using it) but then making it have problems or making some part of it very complex so you need to pay for support.

from client.

outsider/newbie comment starting to dive in (so excuse if you already thought of this and discussed it somewhere else :) )

how about a simple (traditional) module marketplace where developers can sell their modules to companies?

In the long run there might be too many modules and become a problem to parse and choose, but at the beginning, simply selling your module might be enough of an incentive.

Cons: I'm guessing that modules should be open source ( for security reasons), so the problem is that anybody could copy your code and become your competitor. not good.
Or is there a mechanism that sandboxes the modules from the rest of the dapp, bylaws etc?

brainstorming solutions:

• for the number of modules maybe you could grant a maximum of 3 per category in your marketplace (although this is centralizing the curatorial function to the Aragon team rather than the community). This limitation would be an incentive in itself for the developers to be among the first to create the modules and guarantee their position in the marketplace. There are of course ways to guarantee new/better modules to enter the space and compete if you like this direction.

• (not an incentive / security) any module should inherit from your basic module contact/library where you could implement a "disable" or "globally disable" function that would allow you to globally disable / stop that module, across all DAOs, with one click, in the case it was found to be malicious or bugged.

• (not an incentive / security) the same global inherited behaviour could be extended to global reverting the version of the module to a previous version, so that if only the update of the module is bugged it could still work.

• the base module contract could implement the recurring revenue function (and the one time payment function if the dev prefers) so that both the dev has one thing less to implement (an incentive in itself) and Aragon can automatically get a % fee of the sale.

• as for the "support token", it's definitively an interesting option, but not only for support, and also for the implementation of new custom features: In the enterprise / SaaS business one of the biggest revenues comes from custom integrations. These developers could be engaged and payed outside in any freelance marketplace, but if you have an in-built tool/token for companies to request features and pay for them, maybe pooling the funds together (more than one company might need the same feature) that would be interesting.
  In this case, the companies that pay the developers could ALSO have a revenue split of the sale of the modules...this would be an incentive for outsiders, even non coders, to invest in the Aragon module ecosystem early as they would get revenues from the sales of the module.

there might be inspiring solutions in this paper "OpenCollab: A Blockchain Based Protocol to Incentivize Open Source Software Development" http://www.cs.dartmouth.edu/reports/TR2017-831.pdf

just some thoughts.. heading in the right or wrong direction?

from client.

Thanks for the comment!

Yes, all apps being open source is so important. If you cannot see and trust the code, really bad actions could be performed without you noticing.

An important point on your suggestions is that no single party should be able to tap a red button and stop/downgrade/upgrade any smart contracts, no matter if that third party is us. There should be some governance mechanism, or at least a way for people to pre-approve the changes. If not, we could easily end up with an overly complex, but in the end centralized, system.

What I really like is creating governance/support tokens, and as you describe, funds could be easily pooled by a group of organizations to fund a specific feature together. I loved the OpenCollab paper, one of the best resources I have read on this, thanks for pointing it out! I have been thinking about making open source truly sustainable for a long time, and it feels like OpenCollab's architecture is the most advanced so far. It feels like maybe we don't need to implement a fully working incentive structure ourselves, but just use an existing system like OpenCollab's and then focus on building our ecosystem by having the best product, developer tools and access to easy monetization.

from client.

@izqui agreed, I think we should adopt OpenCollab's model which also empowers feature requests without falling into that particular incentives trap

from client.

Hi all! How's the status on this?

from client.

Should make specific proposals as an AGP

from client.