Pay per contribution model
gig work is native labour model of Internet
Last updated
Was this helpful?
gig work is native labour model of Internet
Last updated
Was this helpful?
We feel inspired by the Gitcoin model, where we realized that the only way to have aligned contributors is to give them rewards once things are delivered. As we didn't have a token while writing this, we've decided to go with the Kusama relay chain token $KSM, and we've managed to build payment rails for contributors ourselves.
This evolution was quite fuzzy, yet we haven't got a roadmap; we've seen an opportunity to make this something unique for the end users.
Our primary goal was to establish a positive culture without making any compromises, given our past unpleasant experiences. We were hesitant about engaging mercenaries, but we saw viable option to achieve a great cultural fit within the company. The dilemma that arose was how to promote the right open-source principles and customs among our team without incurring significant losses.
We've managed to process since the first bounty to the current date of writing over $450,000 in liquid bounties without any lockups, which contributors can get approximately the same value for contributors in USD on exchange.
In terms of numbers, the current date of writing this is 6/2023, we've crossed 3000 pull-requests opened people from the Internet, and backlogged more than 5k GitHub issues related to bugs, features, improvements, new designs and various integrations.
Thanks to our model, delivery is powered across 40 repositories within KodaDot.
Our approach ensures a significant influx of open-source enthusiasts looking to join the web development world. We can easily collaborate without placing any commitments on people, whether contract, part- or full-time ones. Contributors can vote with their time - joining when they want and in ways they deem best.
In our repository, we have bounties of differing sizes, indicating the possible reward. Currently forming the total of around $50k, this amount is subject to change due to work presently going into launching para chains.
There are numerous web3 bounty platforms available, but none of them met our requirements. They were either too slow or their processes were not applicable to us. To address this issue, we came up with an idea to create an assignment was necessary because some contributors were only asking questions and not delivering their work even after a week or two. Therefore, we implemented a strict system where each GitHub handle is only allowed one chance to contribute and has a limited time to deliver their work. Additionally, we experimented with a queue system which was interesting to have and we believe it will be useful when the market is bullish again. Another notable factor was when one person took on too many tasks that they could handle. To solve this problem, we set a virtual metric of 5 issues that needed to be resolved before their work was merged.
Originally, we started by simply dropping the address, which seemed like a straightforward method. However, someone still had to process it. Later, we developed a simple one-field app that generated a link when people entered their address, which made things easier. However, some users didn't know their address, so we included a "reward me" link. Over time, we added a USD amount feature, which allowed users to easily add the desired amount they wanted to be paid. We also added a batch processing feature. Currently, our transfer app supports nine chains, and we are considering making it a separate payroll processing system. Our KodaDot URI payment scheme is being used across all departments, from NFT-gallery to workers, indexers, ambassadors, internal payrolls, and suppliers. This standardization ensures seamless and fast payments. We are currently redesigning our transfer app, with the aim of turning it into a dedicated product from KodaDot Labs- another flagship experiment that has stood the time.
To this day, our KodaDot payment URI was used with over $810k processed rewards across KodaDot ecosystem
As we making contributions to our project and receiving daily pull requests ranging between 20 to 50, manually processing payments became a time-consuming task. To streamline the process, we developed a simple that parsed payment links from the KodaDot URI in the pull request templates. Whenever someone writes "pay 100 usd" in a PR, the bot would look up the address and process the payment, providing proof of payment and marking the PR as "paid." We also conducted an experiment where anyone who merged 50 PRs into our repository gained access to our hot wallet containing $5k and could pay themselves when the work was completed. This experiment proved successful and created interesting dynamics.
After observing that some contributors have been active for a longer time and have established credibility, we been contemplating ways to promote and encourage them to contribute more. We are considering implementing a more flexible process that will allow these contributors to give back to the community. One idea we have been exploring is the establishment of a code review guild. Currently, the guild has eight members who are selected on a round-robin basis to their presence on various pull requests.
This is the reason why we are constantly learning and striving for the best, as there is no definitive solution. Our approach is collaborative, with the aim of making it the best possible way for everyone, and ensuring inclusivity. To this end, we have a few labels such as 'works-for-me', 'code-lgtm', 'qa-ok', and 'changes-requested'. These are the fundamental tools that enable those with greater privileges to apply these labels.
Documenting this particular issue can be quite challenging. In our current development, we assume the possibility of merge conflicts between the release and master branches. To minimize the occurrence of conflicts, we leverage GitHub issues as much as possible and make them atomic, ensuring that pull requests have fewer conflicts when two individuals work on the same thing. This helps prevent clashes in merge conflicts when one person's pull request is merged, knocking off another one in the queue.
At one point, our KodaDot development team of two was able to achieve a "refresh-rate" of nearly 250 pull requests in a single month. This is a remarkable accomplishment, especially considering that larger corporations struggle to reach even 50 pull requests in the same timeframe. Our experiment took off when we allowed others to access our hot wallet and payments started functioning in a peer-to-peer culture. This was essentially a DAO experiment, albeit without the use of any DAO tokens.
We are currently devising a plan to gradually introduce the system to other repositories in collaboration with our partners. Our aim is to simplify the developer onboarding process and make it less cumbersome. One of the major enhancements we plan to implement is the payout in USDT. Additionally, we are exploring the possibility of collaborating with other partners and leveraging bounty networks.
We've managed to drive unique contributors' culture within KodaDot and built a few products. You can find more about them in , which will be gradually expanded when things are baked.
You can check this on , which has already funded over $451k @ $200/KSM to notable contributing members. Now we are moving with funding contributors from Kusama , where we wil be sending rewards in $DOT currently and gradually integrating $USDT within our Transfer App
You can learn more
We have notes on how to replicate this game and were even
Want to sign up for your project to test with us? Hit
We've been giving away presentations at and
