Over the last half a year or so when it comes to contributing to fractal DAOs, my perspective has been about prioritizing consensus before doing. I thought that we have to build consensus on what to do next as a group and then do it together in a coordinated way. This did bring some positive results
However one of my expectations for this period of time was that we would upgrade Optimism Fractal software. It was clear that the current design of it was sub-optimal. And so, in line with my perspective that we ought to do things together, I tried to reach consensus on how we want to do it (development process) and what we want to do (design of a new Optimism Fractal software). Even though I spent a lot of time collaborating on this with others the result was a failure - almost no progress was made on updating Optimism Fractal software (we have produced multiple potential designs though).
I conclude that when it comes to the design and development of software for fractals it is not something that group consensus should even be deciding. Group consensus can decide what software to use, but it cannot efficiently decide what software to create. Or in other words, group consensus is great at judging and selecting software, but it is terrible at creating new software (unless you're replicating what's already done).
Obviously, I'm not saying that groups of people cannot create software well. I'm saying that decentralized group consensus cannot create software. So you either have to have a hierarchical management structure for decision-making or use an open source Linux-like model.
Linux is probably the most successful global collaborative software project that has ever existed. If we want to do decentralized collaboration it's a no-brainer that we should look to learn from it.
How does Linux manage to be such a successful decentralized collaborative project without any management hierarchy? The trick is that the maintainers of Linux codebase do not try to direct the development. They simply either accept or reject the code already developed. This saves a huge amount of overhead. There are many other benefits and interesting features of Linux development process[1] but one of the things I want to mention here is that this is the thing that enables Linux to have so many contributors. If they tried to manage developers then adding every new developer would add add communication overhead, which would eventually limit the amount of developers that could work on a project. If you don't try to do top-down management of development you simply do not have this problem.
The group of maintainers that maintain Linux repository have a hierarchical structure where each subsystem of Linux has one maintainer and the top maintainer acts as a final gatekeeper for what gets merged. The top maintainer usually also appoints maintainers for subsystems. This is an efficient structure for decision-making because final decisions have to be made by individuals, not groups.
You might think that this is a benevolent-dictator model, with the top-maintainer holding keys to change whole maintainer hierarchy as well as override any decisions they make. In a sense, you would be right. But you miss the point until you realize the limited scope of this dictatorship. Top-maintainer can only control one repository. Creating and cloning repositories is so easy and cheap, that it does not actually give top-maintainer much real power. If people stop liking decisions top-maintainer makes they can always start using a new repository. The only way for the current main repository to maintain its status as the main repository for a project is for the top-maintainer to make decisions that make everyone happy or at least are neutral and fair for everyone.
The idea of not directing development but selecting what's already developed is even more relevant for fractals than it is for Linux. Fractals do not use the benevolent dictator model that Linux maintainers use. Typically the only means of making decisions for a fractal is the consensus process which usually takes at least 4-6 contributors agreeing on a proposal. Obviously, this makes it much harder to make decisions than in the Linux model. Therefore, if overhead in directing software development would be a problem for Linux it is even more a problem for fractals.
This does not mean that fractal should not have any control over its own code. It's just that this influence over the code should be exercised through selecting code rather than organizing the development of code (alternatively fractal would probably need to provide funding for developers in order to organize development effectively). Every time we select something we express our values, because we select according to our values. The same holds for fractals. Developers whose apps get rejected or accepted will get the message about values of a fractal and therefore they have information to make a better version next time. Furthermore, a more refined feedback mechanism could be created where developers would get comments about why their code was accepted/rejected, although that would probably happen naturally even without introducing any formalized process. If there are multiple candidates they could even be ranked.
I propose that this principle of selecting over directing should be applied when creating and adopting all code for a fractal (deployed smart contracts as well as frontend).
It has to be noted that if there's no coordination in a fractal about who works on what it means that we will likely end up having multiple apps competing to be selected. Which brings me to my next point.
What if instead of seeing the development of fractal software as a collaborative effort we embrace it as a contest that a fractal hosts? A place where developers (and teams of developers) compete to determine the best fractal DAO software with the winning software becoming the "official" app of a fractal?
Why would developers participate you ask? Of course, a fractal does not have any treasury and therefore cannot offer any prize or reward, so you might think a fractal does not have anything to give. This brings me to a very important point. A Fractal does have the most valuable thing to give: usage from real users. The usage of code is the main currency for an open source development. This is what motivates donations, grants and other types of funding in this ecosystem and with metric-based retroactive funding (RetroPGF) this is even more relevant. Fractals are great for anyone creating DAO software because they have users interested in decentralized governance and even more importantly they have great potential for onboarding new users.
One thing that struck me lately about my time in fractal DAOs is how often people put solutions before the problems (I'm surely guilty of this as well). In a typical discussion, you will get a bunch of ideas about what we could do and only later we talk about the problems we are solving and why we prioritize these problems over others. My theory is that this is a sign that we are unconscious of one of the needs we all have that fractal is serving us. A typical person in this space is creative and passionate. Visionaries - someone who has and follows his own vision. An important type of reward for this kind of person is to have his ideas and creations adopted, implemented, and spread. This is why, I believe, we put solutions before the problems so often. In short - it serves our need to be creators. More specifically, anytime someone adopts a solution we were inspired by, it confirms the vision we believe in and this confirmation energizes us in our pursuit of our vision, which makes us more psychologically healthy and happy.
So let's stop thinking that fractals have to somehow incentivize developers to contribute. The only thing a fractal needs to do is to give creative freedom for builders and then recognize and use their work. The usage of their work is the reward. There are enough builders who would love to have fractals use their software. The reason for the lack of development progress on fractals is because those builders have been trying to collaborate and learn what to build from a fractal instead of just building what they believe in and proposing it for a fractal. This can partly solved by a fractal clearly communicating that it is not going to tell anyone what to create and how, it will simply wait for completed products and then select the best.
Another part of a solution is to advertise and implement a non-linear development process. What do I mean by that?
One of the things that is often preventing us from creating effectively in the present is a concern that what we do right now will somehow eliminate our path towards our long-term vision. In other words, we have a long-term vision and we want to make sure that the step we make right now is aligned with that vision. This can be paralyzing. This is very relevant for DAOs the way we usually think about them. We assume that future updates have to be made by improving existing codebase, updating existing deployment of contracts. If this is true, that severely weakens the contest idea I suggested above. What would happen is that some ideas would get rejected during the first contest of competition and then implementers of those ideas would have to give up on their line of work, because they know that all updates will happen on a different line of work.
I think this is a wrong perspective for fractals that have only non-transferable token and hold no assets (e.g.: Optimism Fractal Eden Fractal). These kinds of fractals can fork easily (use different smart contract deployed at a different address) and this should be utilized. It means that fractal can adopt completely different codebases from season to season. Ideally, these implementations would have the same interface but right now it only means that they have to implement a non-transferable token called Respect. It should be up to developers of these competing versions to offer a smooth path to migrate to their new deployment.
This is what I call non-linear type of development. It simply means that a fractal adopts a new version for the next season without having to ensure compatible with past and future development initiatives.
For the contest idea I suggested earlier, it means that developers who lose in the competition for this season can continue development of their version and win the next season. In fact, they would have an advantage over the current winner. The winner for this season will be busy supporting users and maintaining existing features while projects which lost can develop new features. Not to mention the potential multiplicity of fractals - so if you didn't win in a contest for one fractal you can try for others.
This creates an environment where there are no absolute losers. Only continuous competition with all competitors getting better and better. A recipe for a great sport.
The standard relationship between a software developer and his client is that the client pays money and in exchange developer builds what the client wants. Public goods funding in the crypto space is different. Builders build what they want and if users find that valuable public good funding program tries to reward the builder appropriately. When compared with standard client-developer relationship builders here lose predictability with regards to their payment, but this is compensated by the creative freedom to build what they genuinely believe in. This is a trade-off that makes sense for a lot of builders in crypto space.
So for fractals to get contributions from developers they either have to pay them or they at least have to not mess with the equation in the public goods funding model. In other words, if a fractal cannot pay developers it cannot tell developers what to build. But fractals do have the power to provide something that developers need - a signal of recognition (an evaluation) for their work. Fractals can issue that signal in multiple ways: through the usage of their work (onchain transactions), respect game or votes by respect holders. This signal helps developers justify the public goods funding they receive, therefore they have an incentive to build what fractal actually needs. But it should be up to developers to figure out the needs of a fractal rather than fractal telling a developers what to build.
Fractals help solve one of the hardest problems in public goods funding - recognition of public goods while having a say in what gets developed through the means that is most natural to them.
We often try to be nice and talk in terms of "how do we collaborate" and avoid any notion that we are competing. Well, the fact that we avoid talking about competition does not change the fact that it exists. The fact is that a lot of times you have multiple projects working on overlapping features and to say that those projects are not competing for users would be a blatant lie. Competition exists among participants of a fractal either way. But competition does not mean disrespect. Far from it. In sports great competitors have great respect for each other. Fractals have great potential to create great competition while contributing positively to the ecosystem. We should capitalize on that instead of trying to force collaborative development everywhere.
"Cathedral and the Bazaar" by Eric S. Raymond is a great read if you want a more in-depth analysis of Linux-like development process ↩
