# About
These resources explore the opportunity of contributor based funding for Web3 ecosystems. # Open source contributors A proposal for an open source contributors disbursement process **Proposal** {% content-ref url="/pages/TUwbcQ0hMbz1UMtsQ2wP" %} [Current funding landscape](/proposal/open-source-contributors/current-funding-landscape) {% endcontent-ref %} {% content-ref url="/pages/wvirkaVMBlfObxOyuDhx" %} [Tech company comparison](/proposal/open-source-contributors/tech-company-comparison) {% endcontent-ref %} {% content-ref url="/pages/vxyetfzQhTayjSsJJyQw" %} [Open source contributor funding](/proposal/open-source-contributors/open-source-contributor-funding) {% endcontent-ref %} **Contributor funding experimentation** To experiment with this open source contributor funding suggestion there are some resources that outline a process that can be used for an initial funding experiment: {% content-ref url="/spaces/MknWvDkc5shALcb0cpEH" %} [Contributor Funding](https://funding.contributors.org/) {% endcontent-ref %} # Current funding landscape A broad overview about the current landscape of funding processes across Web3 and how these compares with large tech companies {% embed url="" %} This page contains the same information that is covered in the above video ***
Many Web3 ecosystems have their own treasury which is used to help fund initiatives that generate impact for the ecosystem. Founding entities in each Web3 ecosystem are often responsible for the ongoing maintenance and development of the network itself. Moving above this responsibility the most common process for funding is idea based funding. This can often come in the form of requests for proposals (RFPs) that are suggested by the founding entities or an open proposal process is used where community members can suggest ideas for voter approval. For the open proposal process the deciding voters are often a founding entity that look after the treasury or they are the wider community if coin based voting is being used and governance decisions have started to move on-chain. Idea funding often helps with funding initiatives that focus on building new protocols, software libraries and applications in the ecosystem or for supporting ecosystem initiatives that help with maintaining and growing the ecosystem. Some ecosystems invite ideas that help with network & infrastructure development which could compete or compliment the founding entities own efforts. Some ecosystems invite proposals that focus on global and location based public goods, however these initiatives might not be as relevant or focussed on improving and growing the ecosystem itself.
We can go into a bit more detail about idea funding. Idea proposals usually cover the details about the idea whether broadly as a project or more specifically as an idea with a number of execution steps. This is then usually coupled with information about the contributors who are going to be involved with executing that idea. For voters, the responsibility of selecting ideas is either handled by the founding entities or by the community members. Community member voting usually means that an on-chain voting solution has already been developed and is available for the the ecosystem to use. Many idea funding processes are often open where anyone can submit proposals that will then be considered. These proposals may all go into the same bucket or category or there might be separate categories that handle different types of idea or different amounts of funding. The other process you also see are request for proposals. These are often created and handled by a founding entity. Founding entities will identify some priority that could be addressed by the community and convert that priority into a request for proposals so that community members idea proposals can be selected and compensated to help with addressing that problem or opportunity. Finally in terms of incentives you often have budgeted contributions where the proposers will outline what they intend to execute and how long they believe it will take, this then results in a total requested budget. Some ecosystems may enable project funding where the project outlines what it’s overall purpose is but doesn’t commit to any specific execution outcomes. In these situations the community would be just be supporting these projects more broadly with what they’re working on. **Problems for contributors** Idea based funding processes can cause a number of problems for contributors. * **High participation time required** - Contributors need to create ideas to be considered for funding which means a certain amount of upfront work is needed every time a contributor is looking to receive more income. Contributors need to handle the ongoing burden of proposal writing and promotion of their ideas. * **Proposal submission complexity** - Ideas and contributors are often combined into a single proposal. Sometimes the priorities they are addressing are also included in the proposal which might also include any justifications about why those priorities are currently important. This submission structure increases the complexity for contributors to participate as now a lot of contribution effort is needed around presenting information about priorities, an idea and the contributors involved all in a single proposal that is documented upfront so they can make a submission and be considered by the voters. Proposers also need to handle this complexity each and every time they want to be funded for a different idea. The complexity is only further increased by the fact that these ecosystem can change very quickly meaning it can be very difficult to accurately budget how long a given idea will take to execute due to the community, tools and infrastructure that is constantly changing around them. * **Low contribution flexibility** - A contributors flexibility to work on different impactful ideas is reduced when the incentives are attached to ideas. Contributors have an obligation to execute their ideas that were selected and funded by voters. Contributors either need to go through some form of approval process to change their idea beyond what was voted on or accept they need to execute the idea as stated. This can be an issue due to the fact that more impactful ideas could emerge as time goes on and intersecting ideas that benefit multiple teams could also emerge. In these situations these ideas would need to receive funding separately first or an arrangement needs to be made to agree on where the funding is coming from to pay for the contribution efforts that are needed to execute these new ideas. These efforts to resolve compensation could occur each and every time a new idea is executed or contributors could alternatively ignore this issue and accept that they just won’t get paid for those efforts. This upfront commitment to an idea they must execute can limit how fast a contributor is able to respond to a fast changing environment and new information and can prevent these contributors from directing their efforts to the most impactful initiatives that emerge. Contributors become less flexible in how they can work in the ecosystem due to the ongoing burden of working out how they are going to get paid for all the different things that they could help with when trying to generate impact for the ecosystem. * **Low income stability** - Contributors that want to have a more reliable income stream would need to repeatedly create ideas that then get selected by voters. Having one idea funded does not mean the next idea will receive funding, it will often be difficult to predict which ideas a community of voters is going to select with any high degree of accuracy. Another factor that impacts income stability is the variance in the time it takes to actually complete an idea against the initial budgeted plan. Most ideas change and evolve over time as the environment changes or as new information emerges. This makes it much more likely that individuals become under or over paid for their contribution efforts due to this unpredictability. * **Budgeting complexity** - Budgets can greatly increase the complexity of idea planning. Idea planning is an important task in any scenario as it helps with better understanding how to execute an idea by breaking it down into different steps and tasks that are involved. Adding a budget commitment to this is where the complexity and risks are introduced. Accurately estimating how long an idea will take to execute can be extremely difficult at the best of times, and even more so with fast changing Web3 ecosystems. Ideas that are novel and that have not been executed before add further complexity when predicting exactly how long it will take to execute that idea. This requirement for budgeting can be a deterrent for contributors to participate due to the upfront amount of work needed to try and estimate and commit to these costs and then also the ongoing risk around the likelihood that they are going to be underpaid due to the idea taking far longer to execute than expected due to these changing variables and factors, many of which they have no control over. * **Governance complexity** - There are risks around how incentives are distributed when some stakeholders involved in that project temporarily have custody over these assets for a funded idea. If there is a dispute between the management and contributors involved in the execution of an idea there is a risk that some of the contributors do not get paid for their efforts. Even with a distributed multi-signature approach this dispute could still happen. Another risk is the potential misuse or theft of funds due to certain stakeholders becoming malicious whilst having control of the assets for a funded idea. The larger the amount of funding an idea receives the more incentive there is for an individual or small group of individuals to abuse their position of control. * **Proposal game theory risks** - Proposers could try to increase their chances of receiving compensation by increasing the number of ideas they submit. Sybil resistant systems can help with preventing spam however it is still difficult to restrict users to only submit a few ideas as this could reduce idea flow and potential collaboration around different ideas. Another game theory risk is around proposers that attempt to exaggerate the costs that are involved in the execution of an idea. This could be extremely time consuming and complex to disprove as each idea is different in what they are working on meaning each one would need to be moderated and verified on whether their budget is actually fair and reasonable. **Problems for voters** Idea based funding processes can also cause a number of problems for voters. Voters could be the foundation who decides which ideas get funding or it could be the community using coin based voting. * **High voter participation time required** - Voters need to review and understand many ideas to make an informed decision when selecting the ideas that they believe will be the most promising for generating impact for the ecosystem. Each idea could have a large amount of information that needs to be considered such as the skills involved, the outcomes and impact it could generate and the budget and feasibility of that idea. Even for founding entities that take on this responsibility that have the relevant skills and background experience this task is extremely time consuming making it extremely difficult to scale this to a large number of people unless they are properly compensated for that time. * **High voter decision complexity** - Comparing and selecting ideas requires a lot of context about what is happening inside and outside the ecosystem and the trade offs between the different suggested ideas and how they could impact the ecosystem. It will often be difficult to predict whether an idea is actually going to generate any impact or not ahead of time. Pushing this complexity towards the community makes it difficult for them to feasibly participate if they don’t have the right skills, experience or understanding of the ecosystem. Beyond just comparing the quality of ideas overall the voter also needs to understand whether an idea has been fairly budgeted or not or whether the contributors are even suitable for executing that idea, only a handful of voters may have the relevant skills and experience to fully assess whether an idea is fair and reasonable in terms of the budget and its feasibility based on the scope of the idea and the contributors who are involved. * **Low voter expressiveness** - Voter expressiveness is also something that can be often problematic with existing idea funding systems. If a voter agrees with an idea but believes the contributors are not suitable for the execution of that idea they might not be able to easily express that opinion within any of their voting decisions. And vice versa a voter might disagree with an idea but would like to see those contributors working in the ecosystem due to their experience and skill sets. This issue exists when ideas and contributors are attached in the same proposal within a single funding decision. If these parts were separated the voter could more easily give their feedback and preferences about an idea without the commitment of selecting who is going to execute that idea in the same decision. * **Low voter accountability** - Voters are usually either not paid or not paid large amounts for their participation in these funding decisions. They are usually free to move to other ecosystems and can sell their existing assets within a relatively small time frame. This means voters have low levels of responsibility and accountability to ensure the ecosystem makes good funding decisions. This makes it far more difficult to push large complexity and responsibilities towards these community members who likely don’t have the capacity or willingness to tackle highly complex governance decisions when there is not sufficient compensation for their time. Idea selection often means pushing far too much complexity onto the voters who are often not sufficiently informed, incentivised or accountable for handling such complexity. It is of vital importance that community governance is simple so that these systems are actually scalable. An ecosystem needs to understand the exact implications and complexity of the governance decisions that they are pushing towards community members and need to be able to justify that complexity over other approaches. An ecosystem will want to be very specific about what governance decisions it expects the wider community to handle and which areas can and should be delegated. **Problems for Web3 ecosystems** A number of funding problems currently exist across many Web3 ecosystems. * **Ephemeral ideas** - Ideas are often treated as ephemeral yes or no funding decisions. This can be problematic for encouraging collaborative efforts and suggesting improvements to these ideas over time. Ecosystems could alternatively have a persistent way to suggest and share ideas that increases the exposure of these ideas to the community. This can help with increasing the amount of engagement and feedback an idea receives. The importance of ideas can increase and decrease over time as the ecosystem changes which further increases the need for ideas to be more persistent so that execution can be paused whenever it makes sense to do so. A community member could have a fantastic amount of experience and skills that are relevant to a number of impactful ideas that they want to suggest or give feedback to. Those same community members also may have no interest in personally executing those ideas for any number of reasons. An ecosystem can benefit from enabling those community members to contribute to the ecosystem and provide value in the way they would like to - which could be just suggesting and sharing their thoughts about potentially impactful ideas. * **Missed innovation opportunities** - Another potential problem with idea funding is that when the community is responsible for selecting every idea that is going to receive funding it becomes much more likely that innovative but less well understood or well known ideas get rejected and ignored. Issues could emerge around groupthink or due to voters simply focussing their attention towards the areas that are most relevant to them rather than the ideas that could be the most impactful for the ecosystem. It might be less clear or obvious for a number of ideas on how they are going to generate large amounts of impact without the voter having enough experience and context to understand the potential of that idea. * **Inefficient treasury asset usage** - A problem for Web3 ecosystems is around the active and efficient use of treasury assets that get disbursed. A single contributor has a limited amount of capacity to execute ideas. If a contributor is funded for multiple ideas or for one large idea there is the potential issue that they might be allocated an excessive amount of funding which then sits idle whilst they execute those ideas. This could mean that a percentage of funding is now deadweight for the ecosystem for a certain period of time due to that funding being idle and not being actively used to pay for contribution efforts. Stagnant treasury assets that are not being fully utilised can mean reducing the speed of development of impactful ideas. Excessive funding for one individual or group of contributors can also mean less funding for other contributors which can further lead even more reduced income stability across the ecosystem. * **Lack of prioritisation systems** - Another problem is the lack of prioritisation systems across Web3 ecosystems. Many Web3 ecosystems currently rely on the founding entities to help with prioritisation or are discussing these priorities in existing systems such as forums, chat channels or on X (formerly Twitter). Community members are often unable to vote on the different priorities that might exist which could help with finding out what the communities current sentiment is about these different problems and opportunities. Another key issue to consider here is that the priorities that the community vote on might not align with any of the ideas that have recently been suggested. If ecosystems can increase the clarity and exposure about what the community actually prioritises and values this could drastically help with inspiring more targeted ideas that can help with addressing those specific problems and opportunities that the wider community currently most values. # Tech company comparison Funding comparison between tech companies and Web3 ecosystems {% embed url="" %} This page contains the same information that is covered in the above video ***
Comparisons can be made between Web3 ecosystems and large tech companies. Large tech companies are a great case study for Web3 ecosystems due to a number of overlapping areas. Over the last few decades these tech companies have been some of the most desirable places to work on the planet. Partly due to ambitious global missions coupled with great incentives and employee benefits. Now these companies have obviously not got everything right, however some great learnings can be made by looking at what has worked well for the both employees and these companies. The comparison that we’re most interested in thinking about here is around the idea funding process that is commonly used in Web3 ecosystems and comparing this with the working environment and incentive structures that used with employees in tech companies. **Web3 & tech company overlapping areas** Large tech companies can provide a number of useful learnings about growing a large ecosystem that has many full time contributors. Larger companies can share a number of overlapping areas with Web3 ecosystems: * **Number of contributors involved** - Tech companies such as Apple, Microsoft, Amazon, Alphabet and Meta have scaled to handle a vast number of contributors that work on different products and services. Both tech companies and Web3 ecosystems have a large number of skilled contributors that help with executing different ideas. * **Skill sets** - Both large tech companies and Web3 ecosystems rely heavily on competent software developers to build high quality and scalable solutions that can scale to the masses. Product, design, research and analysis are many other skill sets that both these ecosystems can highly benefit from. * **Problem scale** - Web3 ecosystems and tech companies both are trying to solve global problems which means solving global scale technical challenges and creating well refined products & services that could be used by the large populations. * **Execution complexity** - Both tech companies and Web3 ecosystems are involved in complex execution efforts. Whether that’s AI, blockchain or virtual reality there is often execution efforts that span multiple years to actually create impactful products and services. * **Shared execution problems** - Large tech companies and Web3 ecosystems both reach a scale where there are many shared problems within their ecosystem that benefit from shared solutions. React and GraphQL are a great example of this within Meta, where first they became an increasingly adopted solution within Meta, but not soon after then became open source and then generated wider impact across the entire software industry. **Tech company working environment** Other useful learnings that can be taken from existing tech companies are the environments they have created that can help their contributors focus and thrive whilst they work on important problems. Some of these environmental approaches include: * **Time based incentives** - Tech companies use time based incentives. Contributors are paid for their time based on an agreed salary. Once this amount is agreed contributors do not need to be concerned with where and how they are getting paid and instead can focus their entire attention on their own work efforts. * **Bonus incentives** - Large companies often offer performance and impact based incentives in the form of stock options, bonuses and job promotions. Employee benefits might also exist that further help with simplifying and improving the lives of employees so they can be more productive. * **Contribution flexibility** - Contribution flexibility is an important factor if you want a more dynamic workforce. Companies often enable employee to move across teams and make impactful contributions where they are most needed. Employees do not need to be concerned with how they are going to be paid when they work across multiple teams and potentially help with multiple initiatives. Now it’s worth stating the obvious that not every company is as flexible as others. Though a great example of a company on the really high end of contribution flexibility would be [Valve Software](https://www.valvesoftware.com/en/). Employees in Valve are free to move and help with any project that interests them and where they believe they can add value. * **Collaborative environment** - Teams working on different projects and services can freely collaborate with any other team in the company if it made sense to do so. These employees all work in the same company so ultimately they are all on the same team! The incentives are fully aligned for employees to collaborate on any problems or opportunities that could be mutually beneficial for those teams and the wider company. * **Quickly changing ideas** - Ideas can also quickly change in these environments. Teams often have a moderate amount of autonomy when working on different products & services and often take the leading role in planning their own roadmap and delivery of new features and improvements. This enables them to experiment and trial new ideas quickly as different opportunities emerge without needing to seek approval from everyone else in the company. * **Pausing idea execution** - Teams are often able to start and stop working on different ideas whenever it makes sense to do so. Some ideas won’t generate the intended outcomes that were desired and in that event a team could stop working on it as soon as this becomes obvious. If a team moves from one idea to another this won’t change or impact their incentives. Each employee and team are ultimately responsible for making as much impact for the company as possible. **Common reasons people leave tech companies** The following are some example common reasons why people leave large companies. This can help with identifying which Web3 funding approaches might help with resolving or reducing these issues in the future. * **Better work-life balance** - Looking for opportunities that have better work-life balance. * **Looking for more meaningful work** - Current responsibilities or working environment is uninspiring. * **Personal values misalignment** - Actions and outcomes generated by the company don’t align with personal values. * **Lack of career advancement** - A lack of opportunities to grow and learn. * **Burnout** - A need for recovery due to over working. * **Management & leadership issues** - Conflict or disagreement with people that have authority. * **Entrepreneurial aspirations** - Trying to start a new business themselves. * **Relocation -** Wanting to live and work in another location. * **Changing work interests** - Looking to try something new or more challenging. **Tech companies compared with current Web3 funding landscape** * **Less complexity to contribute** - There’s less complexity to contribute in a large tech company. An potential employee just needs to submit their personal and professional information, often in the form of a CV to be considered by the company. Promising candidates will then go through a one time interview process and if selected can join the company and receive ongoing compensation. In comparison, Web3 ecosystems contributors need to define and suggest ideas ahead of time which takes a large amount of upfront work to be considered for compensation. There’s also increased complexity for Web3 contributors as they need to do this every time they want to be funded a different idea. * **Higher income stability** - Once hired a tech company employee doesn’t need to be concerned about how much income they are receiving each month, it’s pre-determined and agreed. For Web3 contributors they often need to budget ideas ahead of time and this can easily lead to becoming under or over paid due to differences in how long the idea actually takes to execute. They also have reduced stability due to the fact that their ideas they suggest might not be selected to receive funding meaning they may go through periods of receiving no income at all. * **Higher contribution flexibility** - Higher contribution flexibility can mean contributors are more easily able to allocate their time to the most impactful initiatives. Employees can often work on numerous ideas and different teams whilst they work in an organisation. The idea that a team is working on could completely change if they had good reason to make that change, they could end up addressing a completely different problem or opportunity. New teams can quickly form to address any emerging problems or opportunities. In Web3 ecosystems if every idea is funded separately there is a higher complexity to move to different ideas unless there is enough funding available and a working agreement is made about who is going to be paid for what execution efforts. Alternatively if these agreements can’t be made then every single idea would need to be approved and funded separately which delays the speed in which these ideas can be explored and developed. When a token has been created this complexity is only increased further as now the contributors involved in this project are now responsible for maintaining and growing that particular idea and ecosystem that this token is used for. This can easily prevent contributors from being able to move as easily between ideas and help with different initiatives that could have generated a lot of impact for the ecosystem. * **Easier collaboration** - In companies employees are paid for their contribution efforts each month rather than for the ideas that they suggest and execute. This means it doesn’t matter which idea an employee is working on as long as the outcomes from their efforts help to generate impact for the company. Collectively these employees are all working on the same team which enables teams to more easily identify intersecting problems and opportunities that they could work on collaboratively. Software libraries created in Meta such as React and GraphQL are great examples of this. In Web3 ecosystems collaboration is more complex as funding is allocated through ideas meaning if one team executes these intersecting ideas and doesn’t complete their own funded idea they risk receiving a lower amount of compensation for their efforts due to this idea not being funded and could also risk not being funded in the future due to not focussing on their own idea. Contributors in an idea funding environment have to compete against each other constantly to receive funding which doesn’t fully align the incentives to collaborate and give their time to build out mutually beneficial solutions without the burden of first coming to new working agreements. * **Less complexity for decision makers** - Companies focus on identifying, attracting and retaining the highest quality people they can to work in their organisation. The complexity for companies is comparing and selecting the best contributors. In Web3 ecosystems this complexity is often far higher as comparing ideas instead of contributors means a lot more information and complexity is introduced. Many of the voters will struggle to have the right level of experience and context about these ideas to make well informed decisions. Web3 ecosystems that want to fully decentralise this idea selection approach will be pushing this massive complexity to the wider community. This idea decision complexity is also a persistent problem for Web3 ecosystems as ideas will constantly change - you don’t keep executing the same idea! In comparison competent contributors do not change as often, and this is why tech companies will look to simply retain their talented employees that work on one or many ideas at a time. **Web3 funding considerations** Web3 technology has the potential to completely rewrite how society operates on a day to day basis and influence how incentives flow through these ecosystems to consistently generate impactful outcomes.
When thinking about how to design a funding process for Web3 ecosystems some considerations that can be made are: * Is a given funding approach more effective than the previous systems and processes we’ve seen before? * Is it becoming easier or harder for contributors to get involved and receive fair compensation for their efforts? * Can the funding process feasibly scale to a wider voting audience? Is the complexity increasing or decreasing for voter over time? There was a time where these existing tech companies were the most novel and new places to watch or work in. It was really exciting to see them rapidly evolve and change to create new markets and address global problems. Blockchain and ledger technology is going through this same phase now but eventually it will become just another piece of technology like existing internet protocols such as HTTP, SMTP and TCP/IP. Web3 ecosystems are trying to recreate and improve the money and systems that society uses on a day to day basis. An effective funding process can help with aligning and fixing the incentives, which will be a key part of making these emerging Web3 ecosystems thrive over the long term. # Open source contributor funding Outlining what an open source contributor funding process entails and how this approach could be beneficial to the contributors, voters and Web3 ecosystems {% embed url="" %} This page covers similar information that is covered in the above video ***
There is an opportunity for Web3 ecosystems to experiment with an open source contributors funding process. Contributors would be selected and compensated to work on open source initiatives. Founding entities currently often handle the core network & infrastructure development in most Web3 ecosystems. So, a great starting point for open source contributors could be to become a supporting structure that sits on top of the founding entities. This would mean that contributors would be responsible for helping with the development of protocols and software libraries. These contributors can help with improving the developer experience, the availability of protocols to integrate and the number of smart contract utility libraries as just a few examples. Ecosystems could also optionally encourage open source contributors to help with network & infrastructure development efforts or application development as well. **Funding process analysis** To read more about the analysis and background that supports this open source contributor funding proposal it is worth reviewing the following funding analysis: {% content-ref url="/spaces/8L61e8ulVlk90t5mlQk1" %} [Funding](https://funding.treasuries.io/) {% endcontent-ref %} **Open source contributor funding experiment** Contributor funding resources have been created to outline how a contributor funding experiment could be setup, what the overall goal and objectives are for the experiment and what the development roadmap could look like: {% content-ref url="/spaces/MknWvDkc5shALcb0cpEH" %} [Contributor Funding](https://funding.contributors.org/) {% endcontent-ref %} An example contributor funding process experiment resource can be found here for reference: {% content-ref url="/spaces/ZE8rIZvI1VylVcwzSPzR" %} [Experiment Example](https://example.contributors.org/) {% endcontent-ref %} ## Advantages for c**ontributors** **Quick & simple participation** Contributors would submit their personal and professional information along with any contribution history to showcase their skill sets and any impact they have generated for the ecosystem. They then can be considered as a potential candidate to become a paid contributor. Contributors don’t have to suggest new ideas or make financial agreements with existing teams and instead can focus on helping with the executing any new or existing open source initiative. **Removed budgeting complexity** Contributors could work on one or many open source initiatives. The contributor doesn’t need to do budget planning ahead of time for the ideas that they work on which saves them time each time they work on a different idea. This removal of budget planning also helps to remove the risks of under or over compensation due to an idea taking longer or shorter than expected. Paying contributors based on the time they work means ideas can more easily change and evolve as required due to a changing environment or requirements. This lack of budgeting requirement is also great for ideas that only take a day or week to complete as now they can just quickly get these done as contributors are paid for their time and don’t need to constantly seek voter approval for every idea they work on. **Income stability** Contributors being paid for their time means they will receive an increased amount of stability in their income. They will also have full awareness of how long they will be compensated for as their duration of payment will be known ahead of time when they are selected as a contributor. This means contributors can spend their entire time fully focussed on executing impactful ideas rather than being concerned about how much they are being paid and the issues that emerge when an idea takes longer or shorter than expected. **Flexible contribution** Contributors could work on one or multiple ideas whilst they are being compensated to work on open source initiatives. This enables a contributor to align their efforts with the initiatives that can generate the most impact for the ecosystem. This autonomy gives the contributor more responsibility and accountability to self identify the most impactful initiatives over time that they should work on. This can ultimately help to increase the chances that they get selected again in the future as a contributor. This ability to help with the most impactful initiatives can be more easily achieved due to the fact that incentives aren’t tied to a single idea. **Reduced governance risks** Funding would come from the treasury and go directly to the selected contributors. This helps to remove governance risks around having any intermediaries that might have held these assets temporarily. A small number of actors could have misused or stole those funds that were supposed to pay for contribution efforts. Instead by paying contributors directly the incentive risks are localised to each individual contributor and the risk for each contributor is a single month's worth of compensation. **Increased depth of experience** Contributors that are working on open source initiatives across an ecosystem can help with creating an environment where these contributors could become very well informed about the different approaches that can be used to build applications and protocols. This exposure to many open source initiatives can also help with improving their awareness and understanding of what the biggest problems and opportunities are for improving the developer experience in the ecosystem that they can then even try to resolve with their own contribution efforts or through collaboration with other contributors and the founding entities. **Inherits many of the best parts of working for tech companies** Many of the best parts of working in large tech company environment for employees can be achieved with an open source contributor funding process. The first advantage is that the simplicity of time based incentives can help increase contribution flexibility and create a more collaborative environment as the incentives are attached to the efforts of a contributor and not a single idea. One advantage of an open source funding process over existing working arrangements in tech companies is that a contributor funding model can push beyond the advantages of working in tech companies by giving contributors even more autonomy over how they decide to generate impact for the ecosystem. The contributor would ultimately be their own boss and have full ownership and responsibility to generate impact and build their own reputation. Contributors would be able to work wherever and whenever they want as long as they generate impact for the ecosystem. Contributor funding could help give people higher levels of flexibility, reputation ownership and autonomy. **Helps reduce or resolve the common issues of why people leave large tech companies** * **Better work-life balance & burnout** - IIncentives can help with encouraging and rewarding contributors that work harder than others in an ecosystem. However the actual choice of how much time a contributor is willing to use from their daily lives is fully up to them. Contributors won’t have any top down leadership that is pressuring them to work more than they want to, a problem that can happen in corporate environments. * **Relocation** - A contributor working for an online Web3 ecosystem can work anywhere in the world they want providing they have internet, so relocation should never be an issue! * **Lack of career advancement & changing work interests** - A contributor would self determine what they work on based on what ideas could generate the most impact for the ecosystem but then also based on their own interests and what areas of work have the most meaning to them. Contributors would have more autonomy to ensure they are spending time on areas of interest or professional development that they value. * **Meaningful work, personal values misalignment & entrepreneurial aspirations** - The outcomes that are generated in this suggested funding process would be open source and publicly available. A contributors work could be used by an entire ecosystem and could even make impact across the globe. Open source initiatives can help to provide ample opportunity for finding meaningful work that aligns with someone's values due to the wide scope and scale of the problems they could work on. So hopefully these issues should be reduced a moderate amount. * **Management & leadership issues** - No fixed management or leadership roles need to exist in Web3 ecosystems when using a contributor funding approach. No one would be pushing contributors to work overtime and beyond their means. If a contributor didn’t enjoy working with another contributor they would be able to move to other initiatives when they believed it made sense to do so. ## Advantages for voters **Faster and simpler decision making** Voting for contributors is faster and simpler than idea selection decisions. Voters wouldn’t need to compare and vote on a number of open source ideas that they might not understand or have enough context for. Instead they can focus on reviewing the competencies and experience of a number of contributors that could help with the execution of any open source initiative. This selection approach helps to reduce the complexity and time required for voters to participate in the funding process. Decreasing the time required and complexity for voters can help with increasing the amount of voter participation and scalability of this suggested funding process. **Easier future decisions** Voting decisions become easier over time with a contributor funding process. Priorities and ideas will naturally change and evolve over time meaning the complexity of selecting priorities or ideas is a persistent ongoing complexity. However quality contributors are far more consistent over a longer time period which means that contributor selection becomes easier over time as voters become aware of the most competent and effective contributors who they can repeatedly select to receive funding. More tools and processes that help to highlight the performance and impact that someone has generated can further improve this ease of future decision making. Easier funding decisions will help with improving the scalability of this funding process. **Idea feedback is still captured** it's important that the community is able to give feedback to the ideas that contributors are working on. Selecting contributors instead of ideas doesn’t mean the voters wouldn’t have their voices heard when ideas are being created and selected for execution. Any process for creating and selecting ideas can be fully public and invite the entire community to offer their preferences and opinions. The key difference with the open source contributor funding process is it would be the contributors who have the responsibility to select the most promising ideas and respond to any community engagement and feedback. Contributors are paid for their contribution time meaning they can work on any idea during that time period that looks like it could be the most impactful for the ecosystem. The contributor is incentivised to respond to community feedback and work on impactful ideas as if they don’t they might not get selected again in future funding decisions. ## Advantages for Web3 ecosystems **Efficient usage of incentives** Contributor funding helps with improving the efficiency of how assets get distributed. This is because any assets that get disbursed would be actively used to generate contribution outcomes for the ecosystem as they would only be distributed to pay for recent contribution efforts. Contributors would also only be eligible for future payment upon the submission of a previous monthly contribution log that demonstrates their contributions. This reduces the potential risks of assets sitting idle that can occur with over funded ideas where assets might not be used immediately to support contribution efforts that can generate impact for the ecosystem. **Environment helps create skilled contributors** A contributor funding process can help with creating an environment where contributors become highly skilled over time. Contributors would be able to work across one or many open source initiatives that could generate impact for the ecosystem. This exposure to many problems and applications across the ecosystem can help with providing contributors a lot more context and deeper understanding on what's working and what needs improvement across the ecosystem. Another skill set you help to enable is the ability for contributors to self identify where they can generate the most impact. The contributors who can master this skill of prioritisation the most effectively should have a better chance of being re-selected in future funding decisions. They could also be paid increasing amounts of bonus incentives over time as the ecosystem grows which would align the incentives with the contributors that generate the most impact. **Improved developer experience** Open source contributors can be a great solution for improving the developer experience over time. Open source initiatives can help with speeding up existing and future teams in developing their own solutions due to new software libraries and useful reference source code. Any developer experience improvements could have a large impact on the development of applications across the ecosystem. The faster and cheaper it becomes to build applications the more it can encourage people to build solutions or it could encourage more investment into the ecosystem to experiment with new use cases and opportunities. Open source contributors could directly support these teams in understanding and applying the different libraries and tools that exist across the ecosystem and help them improve their own solutions. Open source software helps to create a flywheel of making it easier and easier to develop applications and protocols that are increasingly complex over time. **Increased collaboration** Collaboration is another area that open source contributors could help with. Open source contributors will help to develop new open source software but they can also help existing teams with building their own open source solutions. If contributors are available to help different projects there is an increased opportunity for collaboration to emerge across these projects when shared problems are identified. Solutions that can help with addressing these shared problems can be more easily identified by contributors who are supporting many projects. These intersecting software solutions could be extremely useful for speeding up the development of ecosystem projects. Contributors can be seen as a collaborative glue that helps to bring together the ecosystem to more easily identify the most important shared problems that these contributors could then address. Increasing the amount of collaboration can help with reducing the amount of duplicated efforts and outcomes that would have likely occurred if these contributors weren’t available to help with developing different open source solutions. **Incentivises open source solutions** Open source contributors could help better incentivising projects in an ecosystem to open source their software. Open source contributors should have a policy that they are only allowed to work on open source software. This simple policy helps to create a positive reinforcing incentive for projects in an ecosystem to open source their code. A project with only a few developers could have immediate access to the support of numerous open source contributors that can help with their projects development if they choose to open source. Projects that decide to not open source their code would need to compete with projects that do which could give them a serious disadvantage. This simple incentive could lead to a growing percentage of projects that open source their code from the start of their project rather than years down the line. The development speed of the entire ecosystem could be increased due to this compounding effect of having access to lots of open source code as a learning resource for other projects. **Reduces game theory risks** Open source contributors can help with reducing certain game theory risks. Contributors would state what their expected salary is when proposing as a candidate to become an open source contributor. There is a large amount of data available online that helps to show what the lower and upper ranges are for different roles and skill sets. This makes it more difficult for a contributor candidate to exaggerate the amount of funding they should expect based on the evidence they provide. This approach can help to prevent the issues that can exist with idea based proposals where the amount of time they say it will take is exaggerated. The exaggerated idea cost problem is far more difficult to disprove without reviewing each of those ideas separately in more depth. ## Future opportunities & narratives **Faster adoption of self sovereign identity solutions** Self sovereign identity is an important growing technology that can help people with taking control over their identity and data. Open source contributors could be a fantastic approach for increasing the adoption of this technology. Credentials could initially just be used to provide proof that a contributor has been selected in the funding process to become a funded open source contributor. That simple credential could be used for a number of governance related decisions between contributors or for execution decisions. Credentials can then also be useful for recording contribution history, impact and performance, education & skills and any peer to peer attestations that help with building up a contributors reputation. Credentials could help with providing more evidence about the contributions and impact that each contributor has helped to generate for the ecosystem. Potential contributors could also start building up their reputation at any time which would then help them with getting selected in future contributor funding decisions. If these types of credentials help to increase the chance that someone becomes a funded contributor in the future then there is an increasing reason for contributors to adopt and utilise this technology. Funding open source contributors could help with creating a bottoms up approach for adopting self sovereign identity solutions that can scale to handle a growing amount of contributors over time. **Impact & performance incentives** Another exciting area worth ongoing thought is the measuring of impact that each contributor generates and their overall performance. Improving the ecosystems ability to better record and understand which contributors have been the most performant or that have helped to generate the most impact can help with making future funding decisions easier. The top performers could be paid bonus incentives for their contribution efforts which would help to better align the incentives by rewarding the best performers. If performance and impact can be more accurately measured there is an opportunity to explore the usage of algorithmic based solutions that help with suggesting what bonus or compensation each contributor could be paid based on the evidence of contribution history and the amount of impact they are generating. **Defining the future of work** Paying people for their time is not a novel concept. However an open source contributor funding process could become an evolution of the existing employment model that is adopted across most companies today. Open source contributors inherit many of the benefits that these previous working arrangements have but then go further by giving contributors more flexibility, autonomy and self ownership of their career trajectory and reputation. Contributors would be their own boss and would decide themselves who they work with and what they work on. A good contributor funding process could enable contributors to more freely move around ecosystems based on a provable reputation and be paid what they’re worth based on their contribution history, performance and impact. The tools and processes developed whilst experimenting and building out this funding process could ultimately change how people work in these emerging ecosystems. **Fixing open source funding** Trying to fix open source funding has been a growing problem for a number of years. Many open source libraries have become vital solutions and pieces of infrastructure for many large companies and widely used systems. Getting sufficient funding to pay for the contribution efforts that are needed to develop these software solutions has been an ongoing problem. Web3 ecosystems have an opportunity to fix open source funding. Funding contributors directly to work on open source initiatives is one way this problem could be solved. Contributor compensation could eventually achieve similar or higher levels of compensation than comparative roles in large tech companies as Web3 ecosystems grow and require highly skilled professionals. **Replacing founding entity structures** This suggested funding process has the opportunity to replace the founding entity structures. Founding entities are hopefully looking to give up the control and development of the network and give this stewardship and responsibility over to the community. The community should ideally have some way to influence who is paid to help improve and maintain the network. Achieving this will mean making the network more decentralised which would mean fulfilling the original intentions of the ecosystems, where these networks should be governed by the people that use them. The open source contributor funding process could help achieve this outcome as it provides a way for voters to fund contributors that can maintain and improve the network. This process could also help with reducing the potential issues of a single actor or small group of individuals from having excessive amounts of control and influence over the network. Once this funding process matures the employees inside the existing founding entities could start to migrate to working for the ecosystem through the open source contributor funding process. ## Future funding opportunity Open source contributors have the potential to help with many different responsibilities. Supporting protocol and software library development is a great place to start however as this funding process matures there is a opportunity to expand the responsibilities to also include network & infrastructure development, application development and ecosystem initiatives. If this contributor funding process proves effective it could even become one of the most adopted and effective funding processes for Web3 ecosystems. The analysis so far helps to suggest that it also could be far more effective than many of the idea funding approaches that we see today.
## Summary An open source contributor funding process represents a highly promising funding approach for Web3 ecosystems. This funding process has a massive amount of potential to improve how treasuries disburse assets to more consistently generate impact for ecosystems at scale. For **contributors,** this funding process represents a simpler and quicker approach for them to join an ecosystem and be considered as a candidate to receive funding. Contributors would have more flexibility to generate impact in the ecosystem in a multitude of ways based on their own preferences and skill sets. Contributors would not be tied to a single idea which would mean they can become increasingly more autonomous over time in deciding what they work on. All that matters for a contributor is that they generate as much impact as possible for the ecosystem. Contributors would benefit from less budgeting complexity by not needing to create proposals that use complex and estimated costings. Contributors would also have increased income stability due to being paid for a fixed term length. Over the long term this approach would give contributors more ownership and influence over their own career trajectory and how they build up their own reputation. For **voters,** this suggested contributor funding process could offer a far simpler and easier decision making process that is easier to scale for a growing population of community members. Voting could also get easier over time as community members learn about which contributors are the most performant as now they can simply reselect them in future voting decisions. For **Web3 ecosystems**, treasuries could become more effective at generating impact if assets are can be used more efficiently. Funds would always be used to pay for a contributors recent contribution efforts rather than sitting idle in over funded ideas. Contributor funding could provide a reliable long term approach for developing open source initiatives that help with improving an ecosystems network, infrastructure, protocols, software libraries and applications. As the contributor funding process matures there is even an opportunity that it could create a safe and reliable way for founding entities to push the stewardship of the ecosystem over to the community. # Contributor identity use cases A list of different self sovereign identity use cases that are relevant to contributor funding
Contributor funding will create a number of opportunities for identity related use cases. These use cases represent a bottom up approach that could increase the rate of adoption for self sovereign identity solutions. **Contributor selection credential** Contributors that get selected to receive funding and work within an ecosystem by the foundation or community could receive a credential to prove that they were selected to work as a contributor for a certain term length. This credential could then be used to sign messages, votes and reviews that cover a number of different use cases. This verifiable credential could be used for many of the other use cases mentioned below. **Contributor profiles** Contributors could create their own professional profile with their personal and professional information with any social links and relevant information about their historical contributions. This profile could then be used in contributor funding processes across many ecosystems where the profile could be submitted and then considered by the voters. **Contribution logs** Contributors could submit evidence of their recent contribution efforts in the form of a contribution log. These logs could be attached to the contributors profile and provide a growing amount of evidence about the contributions that each contributor has made over a specific time period. **Contributor skills & education credentials** Contributors could benefit from being able to attach any credentials that showcase their skills and educational background. These credentials could help to increase their reputation and chances of being selected as a funded contributor. **Contributor participation credentials** Contributors could be issued credentials to prove their participation in meetings, discussions and activities. These credentials could be useful for proving their participation and contribution to others and for building up their reputation over time. **Contributor peer review & feedback** Contributors could sign peer reviews and feedback they give to other contributors either during or after a fixed term length of contribution effort. These reviews and feedback could focus on performance, impact or their experiences with working with fellow contributors. Attestations could also be made about any mentorship and support that was provided. **Community review & feedback** Community members might also want to make their own reviews and give feedback to funded contributors. These attestations might comment on their performance and impact or about the support or mentorship they provided to certain community members or the wider community. Attestations could also just help to show gratitude towards certain contributors due to the impact they generated or their professional behaviour and contributions. **Contributor software & tool usage decisions** Contributors could make decisions about what software and tools they are going to use whilst executing different ideas. They also might want to make decisions about what software packages are most suitable to be integrated into any software they are developing. **Contributor scheduling & working hours decisions** Contributors could make decisions on their own or within groups about their working schedule and working hours to make decisions about when it might be most beneficial for them to work at similar times as a group. **Contributor scheduling & working hours discussions** Contributors could discuss their working hours and schedules for meeting by sharing their opinions and preferences through signed messages. **Contributor process parameter discussions** Contributors could sign messages with their opinions on different parameters that impact how contributors operate. Community members could then take these opinions into account when voting on any changes to those parameters that need to be handled by a wider community vote. **Contributor process parameter decisions** Contributors could make decisions about certain parameter changes that impact how they work and operate as individual contributors and as a group. **Contribution time allocation decisions** Contributors could indicate where they would prefer to spend their time or even vote on how their time is allocated. This could be useful in situations where multiple people wanted to work on a similar promising idea and a solution is needed regarding how contributors time gets allocated across different ideas. **Idea execution read & write access control** Contributor credentials could be used as an access control system that determines which contributors have access to writing new entries or changes to different repositories. This could enable contributors to change documentation, research, designs or code based on the validity of a verifiable credential. **Idea execution estimations** Contributors could sign their own estimations on how long they believe a certain piece of work might take when planning out the execution of ideas. **Idea discussions & feedback** Contributors could sign messages that discuss and provide feedback to ideas that have been suggested by community members. **Idea selection decisions** Contributors could vote on a list of suggested ideas with their opinion on which ideas look like the most promising ones to execute at that point in time. **Idea completion sign off & review** Contributors could sign off completed work and indicate that it is fully completed. Contributors could also verify other peoples work and sign this off with their own review. **Priority discussions & feedback** Contributors could sign messages that discuss and provide feedback to the priorities that have been suggested by community members. **Priority selection decisions** Contributors could vote on a list of suggested priorities with their opinion on which ones they believe are currently the highest priority.