Thinking about the future of DAO owned open source software repositories (via the SNS)

Developers
1

Just wanted to ramble/bounce a few rough ideas off of you all regarding what the future of open source software could look like with web3 - a preface that I’m relatively new to both open source and tokenization, so I am definitely not any sort of expert in this area, and would love any feedback or ideas you all have.



I’ve been thinking about the future of my open source project CanDB (i.e. how it should be licensed, owned, and operated), and after a few discussions with some people much more experienced than myself in the crypto and software licensing space, it lead me to ponder upon what the ownership and contribution model might look like for web3 and IC projects going forward.

Let’s say a project starts out with a founding team, and wants developers to start using the software so they can improve upon it and attract other developers.

That project can release tokens to developers based on adoption stage (early/late/mature), various usage and/or contribution metrics, and also through outside funding support or a token swap. One key goal, however is that ownership over the prioritization of features & maintenance (bug fixes, support) is primarily disbursed among the developers and teams that use and contribute to the project, and less amongst investors who may or may not use the software.

One of the main questions/concerns around this approach is how to balance the liquidity of ownership so that developers can sell their stake/influence while ensuring that developers are the primary owners, protecting the independence and open source nature of said project. This would be to guard against the scenario where a large corporate entity or investor comes in and buys out control over the project, and then puts an overly restrictive license on the software, making it no longer open source and jeopardizing all the teams that depend on that software.

A dififerent potential solution to this would be to make the tokens purely influence/voting-based, and make them soul-bound (non-transferable). Of course, this then opens up incentives to groups of individuals to band together and sell their identities and voting power to others if the incentives are high enough.


I guess this post has more questions then answers :laughing: …you’re welcome?

4 Likes
2

Tagging @lastmjs because he has been thinking a lot about this as well.

I’m curious, if you don’t mind me asking, what is your background? I admire your work btw.

3

Hey

In order to only emit tokens to developers you can do the following.

Imagine, we have a Jira-like dapp, that is capable of minting new project tokens, each time someone resolves a task. Like, literally you have a board of tasks, where each task offers some tokens as a reward for the person who closes it.
These tasks could be created personally by the project owner as well as by the project’s community (via voting procedure).

Once you have such a dapp, the scenario you’ve mentioned is possible:

  1. You, as a founder, initialize the project - build an MVP, start community accumulation process and find some early developer-followers, who are interested into committing to your project.
  2. You create a first task in the Jira-dapp, where you describe all the work you’ve done and evaluate this work in some abstract amount of your project’s tokens, e.g. 1 billion. You resolve your own task and receive these tokens.
  3. Once you have these tokens, you start a DAO, that is somehow connected to these tokens and understands them as a voting power source.
  4. You switch the ownership of everything related to your project to this new DAO - including your board in the Jira-dapp. Now, your DAO controls everything about your project, even task-tracking.
  5. Now, you’re still the project owner, because you’re the only member of your DAO, but you’re ready to decentralize this control.
  6. You create new tasks (via your DAO) within the Jira-dapp, and assign them to your developer-followers and yourself. Everything that adds value to your project, should be reflected via such a task. Each task could be evaluated in such a way, so when you resolve it, you get some fair amount of tokens. For example, initially you had 1 billion tokens and this amount is equal to 100% of value that is already in your project, so each task could be evaluated as a percentage of a value it would add to the project when resolved, and it should mint the same percentage of token’s total supply to the resolver.
  7. You and your followers resolve these tasks and receive tokens. DAO decentralizes.
  8. You just work on your project with your team, and they are now primary stakeholders of your project.

The rest depends on the organization you want to build for your project.

There is no way of fixing that, except for waiting for People Parties and restricting a total amount of tokens each identity can hold to some small value (like 0.1% of total supply), so no-one would ever be able to take control over the project. But this means, that you (as a founder) will also be forced to follow these rules and to sell your tokens. So this can be only done when your project is mature enough to continue emerging without you.

2 Likes
4

Hey LightningLad, thanks for the kind words, and glad you’re as excited about scalable infrastructure on the IC as I am :blush:

My background is as a full-stack software engineer. I’ve worked at small (~6 person engineering team) startups all the way to building out scalable cloud infrastructure at AWS. In terms of my project experience, I really enjoy wearing many different hats throughout the process and building products from conception to release.

I love playing chess, geeking out on baseball stats, and my two cats :smirk_cat: If you ever see any bugs or typos in anything I write, you can blame it on my cats (they’re all over my keyboard) :sweat_smile:

3 Likes
5

I love this idea - it seems however that there would need to be a good amount of thought put into task-to-token weighting and how that weight might change over time. Otherwise you might end up with a system where only the lowest hanging fruit get picked and all the hardest tasks remain in the backlog.

I hate to think pessimistically, but having a pay-for-task bounty type of system also encourages developers to be mercenaries rather than to work together to find a common solution or to allow others to piggy-back off of the work that they started (but may have not finished or are blocked). There should be some mechanisms put in place that encourage the developers to collaborate and work together to solve larger problems that aren’t just simple one-off type of tasks.

For example, how would one reward the role/contributions of the senior/lead developer, that does primarily design work & engages with tasks that are hard to assign “points”, such as feature scoping and spending time to help & educate or unblock the tasks of others along the way?

There’s probably some hybrid approach that solves this, where as you said here:

So members of the core team receive recurring rewards based on their continued efforts and contributions, and then a series of task “bounties” exist that can be picked up by the community and evaluated on the merits of the work submitted the the developer. Sort of like the developer grants program, but a bit more directed towards the roadmap of the project and with rewards that are specifically targeted towards the difficulty of the work.



I’m assuming also that this project governance might follow the DFINITY model and have the main code repo on GitHub (until a good enough IC equivalent is built) with contributors being allowed to make commits, but then make decisions on how a release gets published out through a private key controlled by the DAO, and a workflow where the code wasm hash needs to match what was approved.

There would also need to be different models for pushing out “emergency fixes” to the repository or “rolling it back”.

The emergency issue is more pertinent for a DAO controlling an application, but a DAO controlling an open source library doesn’t necessarily need to act as fast to fix issues, as any issues can be rolled back by the individual application owners that utilize that library. The DAO can then have time to triage the issue and to say “while we diagnose this issue, just use the previous version or commit hash xxx in vessel”.

I know this may not be popular, but limiting token transfer & soul-bound tokens could temporarily be enforced with some web2 workflow where you give contributors the option to go through to proof of identity process in return for increased contributor/task rewards - it could even use an IC backed 3rd party service like NFID.

I’m sort of on the fence on this part though, as I value and understand that one may have very good reasons to remain anonymous.

1 Like
6

Sorry I missed this reply :sweat_smile:

It sounds like you have a good breadth of knowledge. Your work and commentary suggests good depth as well. I’m glad you’re building on the IC :slight_smile: