# Developer Incentivization v1 (Outdated)

In order for the Sangam protocol to scale and support healthy, growing communities; each entity in the protocol must be sufficiently incentivized to continue supporting the system. Critically their incentive to support the system should scale with the size and scope of the system (ie it is undesirable for hobbyists to be tasked with running a global-scale network). This goes equally for operators who invest money into the infrastructure that supports the community, as well as for the developers who invest their time into building the protocol.

At the same time, no entity should be a single source of failure. Just as operators cannot use their central position to control a community against their will, developers should not be able to use their role as the central authority over the Sangam codebase as a way to unfairly exploit the success of the Sangam network for their own benefit.

To that end, all code relevant to the Sangam protocol must be [CA: nit: R"FOSS" - I have recently learned that the term open source kinda sucks because it does not imply free redistribution/modifications. Technically software could be open source but licensed to prevent forking"] open-source. This will ensure that anyone can fork the protocol and take on the developer role if they wish. Sangam communities may choose any development team they wish, and will not be restricted to the original one.

The sangam protocol will allow for developers to be incentivized through a developer fund on a Sangam blockchain that uses [CA: whose codebase?] their codebase. Any community that registers themselves on a Sangam blockchain will in addition to paying the relevant transaction fees to the blockchain operators also contribute to a developer fund (either on a continual or one-time basis) that goes to the developer team [CA: this is vague, there may be original dev teams and current dev teams maintaining code] that implemented the Sangam protocol for that blockchain. This will make the developer fund scale along with the number of communities that are dependent on the development team's specific implementation. [CA: IMO this should be 100% optional, I don't think it'd be wise to even try to enforce this since the code could just be forked and redeployed to bypass this. I also think the users of this won't all be from US and Europe where standard of living/costs are significantly higher than in other countries, making this fee possibly a very high tax on some users. Some governance models could try to implement this tax, but I don't think we should say it is the default behaviour, just one form of developer incentivization.]

As each development team has control over their codebase, each development team has freedom to decide how they will be rewarded, if at all. However, it is in a Sangam blockchain's [CA: what is a "Sangam blockchain"?] interest to use a Sangam implementation that has some developer incentivization baked in as this implementation will be capable of supporting a professional team of developers to cater to the communities' needs. Just as with the operator case, there is a balance of power that allows both parties to benefit without exploiting one another. A blockchain could always change the development team by hard-forking [CA: I don't think hardforking a blockchain is a viable option] the blockchain and using a different implementation if the development team becomes malicious or incompetent. The blockchain could also hardfork and change the parameters of the developer incentivization to lower the amount going to the developer fund. However, doing these things will reduce the incentive of the developer team to continue working on the implementation and to address the specific needs of that blockchain's Sangam communities. There is an inertia and proof of competency that any development team can rely on to keep the developer incentives as is, or to potentially increase them if governance decides the increase is worthwhile. Thus, the balance of power between developers and communities is another way the Sangam protocol keeps all entities incentivized without letting them gain too much power over the system.

Development teams may also monetize their work by offering auxilliary services. This may include payment processing for operators and users or infrastructure support. Of course, developer teams will have no monopoly on being able to provide these services but perhaps they can use brand recognition and community good will to gain an edge over competition and thus monetize their development work by being able to charge slightly more for these auxilliary services. Here again, developers do not have a monolopoly but are still able to have some ability to leverage their position for their own benefit. This pattern is a repeated and essential pattern in making Sangam scalable yet fair to all parties involved.

[CA: overall I disagree with this form of developer incentive. I think it is counter to the Sangam protocol which makes user exits easy. We have already discussed migrating the blockchain you use for governance to be very complex with lots of friction. This puts communities at the mercy of the blockchain with actual financial potential for abuse. I also don't see any benefit tbh. I understand that this is meant to mirror the community fund on the hub, but it's unclear to me why the blockchain hosting the developer fund would even distribute funds properly. Hard forking blockchains is non-trivial, especially if your chain is something like the cosmos hub. Distribution of the funds adds bureaucray, how often has the cosmos hub community fund distributed its funds? (once in like 17 months of existence?) I also don't think we should enforce the tax on all communities, this makes the governance software [non-free](https://en.wikipedia.org/wiki/Free_software) which I think is a poor ethos to begin a new community with. At this point it makes more sense to ask community members to donate via OpenCollective. I know historically this hasn't been the most successful, but hey the code being ran is being built on enormous layers of open source protocols, why should the last person to the bon fire get all the beer? I don't think we should ship Sangam with any recommendations for developer incentive, rather present possible options. This incentive mechanism feels like it is introducing a new version of the exit problem that Sangam is trying to solve]

[CA: I think a better way of presenting this tax option is allowing community member registration into community X require donation (or repetitives donations) to a developer fund. That developer fund could be controlled by the community of it could be controlled by the large Sangam communities. This would make this enforcement completely optional. Communities could already enforce some registration fees even without this mechanism, this just makes it publically enforceable where the donations go. ie I pay $10 and $6 go to devs and $4 goes to the operator. This would allow communities to modify the registration fee requirement through the same mechanism they modify who the operator is. This allows the tax to be representative of the cost of living the communities are being hosted/grown. It allows easy migration to funding new dev teams as well. Since there is no "global shared" Sangam software, I don't think it makes sense to charge a global tax]