The League of Extraordinary Developers Part II: The Prestige
With the recent “Homestead” release of Ethereum, I’ve found my thoughts turned distinctly in the blockchain direction. Today’s exercise in Practical Imagination is an updated and improved version of my “one software company to rule them all” notion that takes advantage of the idea of “self organizing collective intelligences” (SOCI).
Like all SOCI, the League proceeds through a series of phase transitions. It begins very simply and might very well live or die without doing much. But if it is able to attract enough of the right kind of attention and energy to “level up” it will proceed to its next phase. And so on and so on. If it can make it through three or so transitions, it will have become something very interesting indeed: a decentralized collaborative organization that includes nearly all of the best software developers and is responsible for nearly all important software development in the world. Sound fun? Read on!
Phase One:
The League begins without much fanfare. Perhaps no more than a League token built on the Ethereum blockchain using the Backfeed protocols and maybe some simple web tech like a wiki and a slack channel.
Oh, and a few Members. This is the most important part — the early members of the League need to be open source software developers (perhaps initially focused on blockchain development) with substantial real-world credibility and a willingness to invest some time curating the world of open source software.
This curation function is entirely driven by the Backfeed protocols. I’m not going to go into the details, but it sort of works like this:
- Founding League members have a “Credibility” rating that is determined by the Backfeed protocols and lives on the blockchain.
- League Members “Evaluate” software contributions made by anyone to any project. This is up to the Member. They might focus on particular kinds of projects (say on the blockchain as a space) or on specific projects (e.g., the most valuable contributions to Ethereum) or on specific contributors (e.g., going out and Evaluating Gavin or Vitalik’s most valuable contributions). Some might focus on recent or contemporary contributions. Others might go back to the beginning of time and Evaluate the core contributors to things like Apache, Linux and Python.
- When a “critical mass” (as determined by the Backfeed protocols) of Credibility has Evaluated a particular contribution, the protocols kick in and allocate an appropriate number of League Tokens to the contribution and, thence, to the Contributor.
- If the Contributor then decides to claim their tokens, they become a Member of the League and begin the process of building Credibility with which to Evaluate other contributions.
What happens during this Phase One, then, is the creation of a sort of “Open Source Software Hall of Fame” or a “Who’s Who of OSS” curated by and for the developers themselves.
As the curation rolls out, two kinds of status emerge. The folks who hold lots of Tokens show up as major Contributors. These are the people responsible for much of the value in open source. And not just in a “Top 10 List” kind of format, but with a deep link to the actual work that was the most important.
The second kind of status is that of Curator. You earn Credibility by being the first person to accurately (as determined by the Protocols) evaluate contributions. So, folks like Linus and Guido might hold a lot of Tokens, but unless they are active and effective in Curation, they won’t necessarily have much Credibility as Curators.
While being a high Credibility Curator might not be as sexy as having a lot of contribution Tokens, Cred is important. Because Token rewards are conditioned on a critical mass of Credibility, high Cred Curators are the folks who are going to determine who receives Tokens on a go-forward basis. It is interesting to imagine who the great evaluators and Curators of open source might be.
(For those who have read this far and are worried about gaming the system, don’t worry, the Backfeed Protocols have been very carefully designed to resist efforts to game Token awards. This is complicated, but for now just assume it to be the case. Notably, the Protocols keep very close track on precisely which Members and which Credibility have been responsible for Evaluations. The result is a graph that can be used to derive a view of “the whole League” but at the same time captures the real clusters and relationships between and among the Members. For example, the current Bitcoin block size debate might show up revealing that both Gavin Andresen and Gregory Maxwell have significant Credibility within the League, but that they each represent different sub-communities within the Bitcoin sub-set of the League.)
The result of a successful Phase One, then, would be a rich, nuanced and transparent accounting of some large portion of who has been an important contributor to the history of open source software and a qualified community of Curators empowered to identify which people, projects and activities are the most valuable right now.
Phase Two
Phase Two begins when people start to care about Guild Tokens and Credibility. Which is to say, when people start to modify their behaviour in order to receive Tokens or Credibility. Even if this incentive structure is only very minor in the beginning, it can have significant results: those projects that are most likely to deliver Tokens will be more likely to attract contributors.
This can become a very powerful self-reinforcing feedback loop. High Credibility Curators serve a stigmergetic function by providing signs and signals of which projects are the most valuable and who is doing the best work moving the ball forward (i.e., is making the best contributions). “League” projects begin to have status in and of themselves — they get more attention from Curators, they get more energy from contributors.
This stigmergetic structure helps the entire community to orient, allocate their attention and their energy. The evolution of the open source community into a self organizing collective intelligence.
Phase Three
Phase Three begins when League tokens are monetized.
This results from two observations:
- League Tokens can be used to access (i.e., pay for) things.
2. It is possible for anyone to buy League Tokens (not be awarded them).
The Backfeed protocols contemplate this move from the beginning. While the primary way that people get League Tokens in the beginning is by earning them (being awarded them as a result of contributions), there is always a way to buy tokens (at some price) directly from the protocols.
In the beginning, of course, no-one buys tokens and the price is nominal. But lets imagine League Members have developed a game. And that the team behind it decides to make this game cost tokens. If you want to play the game, you are going to have to get tokens from somewhere. If you are a League Member with lots of Tokens, no problem. But if you aren’t you are either going to have to buy them from a League Member or directly from the Backfeed protocols.
Either way, the League Tokens acquire a new, monetary, value. Its easy enough, of course, to make a distinction between Tokens that have been earned and Tokens that have been bought. So the Tokens don’t lose their ability to confer prestige even as they start to provide a new value: income.
Naturally, if this idea gets any traction we can expect feedback loops to kick in. The more projects that require Tokens to play, the more “market demand” there is for Tokens. The more of these kinds of projects created by the League, the more valuable League tokens become.
Accordingly, everyone holding League tokens will have some level of incentive to see monetized projects be successful. And monetized League projects will tend to get more Curator and contributor attention. Feedback loop closed.
Consider what would happen, for example, if a critical mass of contributors to existing open source projects decided to do a hard fork and focus their efforts on League-powered branches of the software. Imagine if software like the VLC player, the Apache server or Bittorrent were to implement token-powered models. These applications alone would represent an enormous demand for Tokens.
Open source never was supposed to have to be free (as in beer). It’s just that until now monetization of open source software was nearly impossible without deeply violating its ethos and intent. With the emergence of cryptocurrency, this no longer needs to be the case.
Would this happen? Maybe, maybe not. There is, after all, a lot of momentum and prestige already associated with these older projects and it might not be appropriate to drive a hard fork like this. But it is possible. And if even a small amount of open source value is monetized to provide income for open source developers, this is a meaningful and powerful change.
fin
If the League transitions through these three phases, it is entirely plausible to imagine a renaissance in the open source movement. Flows of monetized League Tokens could at long last enable tens of thousands of developers to quit their day jobs and focus on the software projects that they (and the League) think are the most important. These developers, unconstrained by corporate requirements and hierarchical decision-making, could unleash a torrent of innovation. A SOCI of tremendous power and impact.
Moreover, with the approach outlined here, many of the people who have contributed value in the form of open source over the years will be rewarded with League Tokens. At long last appropriately compensated for the enormous value that they have contributed to our shared digital world.
Better late than never.
