Idea for Anytypes future - Distribution of Equity / A Share (Sharings)

Just thought about how Anytype (and free open source projects in general) can hold up with the speed of developement of Notion (proprietary).

Equity / Shares for the people from which the codecontribution was taken and put into the maincode of Anytype (traceable with GitHub right?). I can imagine this could lead to a high amount of high quality contribution in coding and ideas.

One possible factor for the amount of the won equity could be: Code. The number of lines of code in relation to the overall lines of Code. → code-amount-% = equity-%. //Valued amount of Code: That which it will be in the end when Anytype takes the code, which will be the shortest possible form of writing the function then I guess anyways.

feel free to riff on this Idea

Edit 1 (28.03.2022 - 23:17 UST)
uh i have another one on how to gain equity: The amount of characters/lines in a wiki-article that Anytype chose to show on the website/main documentary in relation to the total characters/lines of documentation. And that then also in relation with the main ‘equity-settings’ for all parts where one can get equity.

Equity Settings
Elements: Code, Articles.
Distribution: Code 80%, Text 20%.

Edit 2 (28.03.2022 - 23:17 UST)
Max Equity then of course only goes for/up to 49%, for contributions-people. Anytypes coreteam stays with 51%.

What do you think?

1 Like

there’s problem that length of the code is not a measure of quality or benefit.
some codework is also deleting/refactoring

I’m thinking more in “bounties” - say there’s a requested feature, and if you provide it, you get some “points” (stated beforehand of course). on github, each issue/PR can have this value assigned.

I agree with @jan.peterka that amount of code/documentation (added, changed, removed) does not always correlate to amount to work or quality of work. It will also incentivize more elaborate code or documentation. Too short is not good (code will become hard to debug, documentation won’t be understandable) but too long has the same effect (code will become hard to debug and potentially less efficient, documentation becomes hard to read or contains irrelevant details).

Bounty-based sounds like an improvement as the incentives are focused on the solution to work. It should work for both code (review) and documentation, but it makes it difficult to allow for ad hoc work if there is no bounty for it.

@jan.peterka any suggestions for this by any chance? :slightly_smiling_face:

I can imagine something like reverse bounties: I did or made x or y, what do you offer to have it merged into the made code/documentation?

1 Like

“inverse bounties” of some sort seem to complement bounties quite nicely.

i can think of multiple approaches:

  1. “I’m thinking about doing X, how big interest is in community?”, making it to bounty before you start.

  2. “I did X, how much do you want it?” as I understand what you suggested. I don’t like that - if I already have the code/writing/… done, don’t merging it beacuse of low reward seems like a waste.

  3. “I did X, it’s merged, do you want to support me?” somewhat more like “donation” system - if you like it, if it makes your life easier, you can give something

  4. system where all new work is “voted” on, and some given amount of share is split between it by how much “praise” it got from community

in all these scenarios I can imagine it’s difficult to reward all meaningful work - refactorings for example I think may be underappreciated, even though they are often key parts of work to make project working.

1 Like

Hi @jan.peterka, thanks for your additions! I agree with your notes about the different approaches for setting up a bounty. I think we should also try to prevent immensely complex setups to define what each kind of contribution is worth to the application and its users. I would prefer a simple setup with under and overrating of contributions in a certain percentage of the cases than a very complex setup with a lower percentage of under and overrating of contributions (as it will never be perfect).

Hopefully someone in the community or in the Anytype team has a nice idea for important but difficult to “score” work like refactoring code or documentation.

1 Like