Designing a “Mass Maintenance” BuidlerBoard | BeWater.xyz

*https://buidlerboard.bewater.xyz*

0x01 Talk is Cheap, Show me the Code

In the Web3 world, there’s a well-known saying:

Talk is Cheap, Show me the Code.

Sometimes this saying is questioned; other times, it’s validated.

However, just like students studying economics believe that “in the long run, prices will fluctuate around value”, as Buidlers, many of us also believe that:

In the long run, the value of the project fluctuates around the value of the code.

The biggest advantage of adopting this as a “principle” is that it offers an excellent balance between “mental load” and “effectiveness”.

We can naturally increase our mental load and design a more complex “project evaluation standard”, thereby increasing our “evaluation effect” of the project. But for buidlers, mind is the most valuable resource. So, do we really want to do this? Are we sure that “optimization” is not picking up sesame seeds and throwing away watermelons 😂?

Reference: “Independent Hacker Startup Operating System”

After trying various approaches, many Buidlers, including myself, end up returning to this simple principle. The easiest way to decide whether to participate in a project is to open its GitHub Org, browse through the repositories, and within 30 seconds, we often reach a conclusion.

In reality, BuidlerBoard — a subjective leaderboard that exists in the minds of all Buidlers — has already been around for a long time. As Buidlers, the projects we contribute to through Pull Requests reflect the Repos and Developers listed on our mental BuidlerBoard.

0x02 A “Crowdsourced” BuidlerBoard

BeWater’s current initiative is to take this subjective BuidlerBoard and “upgrade” it into a “crowdsourced” BuidlerBoard.

Many interesting innovations come from this “publicization” attempt.

• Bitcoin: Originally, centralized institutions maintained their own ledgers. Upgrading to “collective maintenance by many nodes” led to Bitcoin.
• WeChat Read: Initially, people made personal reading notes, but upgrading to “collective reader-maintained notes” evolved the experience.
• …

So, the BuidlerBoard project is essentially exploring the following questions:

• How would a “crowdsourced” BuidlerBoard evolve if launched?
• What new possibilities arise if this BuidlerBoard becomes infrastructure?

0x03 How will BuidlerBoard evolve?

The first version of BuidlerBoard has been released, including Developer-based BuidlerBoard:

and BuidlerBoard based on Repo code repository:

In addition to some conventional fixes such as mobile phone adaptation, there are some “evolutionary space” as follows:

• Project submission portal

Developers can submit a link🔗 to add a Repo to the data source. This feature is key to enabling “crowdsourced maintenance.”

• Two versions are divided into Github BuidlerBoard and BeWater Projects BuidlerBoard

The initial release covers all open-source GitHub projects. In the future, to encourage participation in the BeWater Hackathon Platform, a dedicated BeWater Projects BuidlerBoard may be introduced for registered Projects and Buidlers.

• On-chain Integration

Store BuidlerBoard data on the blockchain.

Here are some suggestions from Jolestar:

Put the builder and repo info on chain, and sync the git root to chain periodically. And I suggest training an AI to give a score to the builder.

Use Cases:

1/ Provide commit proof or contribute proof via the git root.

2/ Projects can airdrop to the builder via the info on-chain or proof.

3/ The AI agent on-chain can evaluate the builder and give a grant.

— — https://github.com/orgs/BeWaterXYZ/discussions/575

💡Since 24 years, BeWater has started the practice of Web3 and Open-Source in project governance, hoping to transform from “traditional software engineering model” to “no-access, 🌏globalized, self-evolving Web3 software engineering model” (ᕦʕ •ᴥ•ʔᕤ):

*https://github.com/orgs/BeWaterXYZ/*

• Algorithm update

From the perspective of traditional software engineering, software is considered an inorganic substance, while from the perspective of “Web3 software engineering”, we consider software as “living organisms”, which is also the key point and difficulty in understanding the new model of “Web3 software engineering”.

If we consider software as an inorganic substance, then the design principles of “no mistakes” and “no flaws” should be taken as the design principles at the very beginning, just like a skilled craftsman carving a work;

However, if we consider software as a “living organism”, then the design principles become “simple” and “self-evolvable”. Think about the origin of life under natural occurrence! The extremely simple initial principles combined with the deduction of time eventually evolved into complex and robust living organisms.

Similarly, we need to start with “simple principles” and give them space and time to evolve.

Take BuidlerBoard as an example, using a simple algorithm as the initial design — —

Use the number of stars as the basis for sorting Developers and Repos.

After that, we let the evolution of this algorithm be driven by the community — — Is there a more reasonable sorting algorithm? Come to Github Discussion to make your suggestions:

ε(´｡•᎑•`)っ ~ https://github.com/orgs/BeWaterXYZ/discussions