Discussion sur l'entrepreneuriat Web3 : les projets de chiffrement, ont-ils vraiment besoin d'être Open Source ?

Dans le monde de Web3, l'Open Source est presque devenu une sorte de “politiquement correct”. La Décentralisation, la transparence, la vérifiabilité, ces idées sont naturellement liées au “code ouvert”. Un projet Blockchain qui n'est pas Open Source a souvent du mal à gagner la confiance de la communauté. Les investisseurs vont également douter : puisque vous dites que vous êtes Décentralisé, pourquoi cacher des choses ?

Cette notion n'est pas apparue de nulle part. Elle est issue du mouvement « Open Source » de l'internet.

Depuis les années 90 avec Linux, jusqu'aux années 2000 avec Apache et MySQL, puis à l'ère de l'internet mobile avec Android, le logiciel Open Source a progressivement établi un nouveau consensus : le code devrait appartenir à l'humanité tout entière, et non à une entreprise.

En 2009, lors de la naissance du Bitcoin, Satoshi Nakamoto a directement ouvert le code source sur SourceForge. Pas de validation par des sociétés d'audit, pas de permission gouvernementale, la seule confiance vient du fait que n'importe qui peut télécharger le code, faire fonctionner un nœud et vérifier les transactions. Ainsi, l'open source est devenu un principe dans le monde du Web3.

Cependant, la signification de l'Open Source va bien au-delà de la transparence. L'Open Source signifie que tout développeur peut fork, améliorer et soumettre du code. De nombreux projets Web3 connus ont établi un “consensus technique” avec la communauté et les développeurs grâce à l'Open Source.

Le plus typique est sans doute Ethereum. Son code source ouvert a non seulement été directement réutilisé, dérivant des centaines de chaînes compatibles EVM, mais a également attiré de nombreux développeurs à rejoindre en tant que contributeurs, propulsant l'upgrade continue du protocole lui-même. Par exemple, en 2015, le développeur communautaire Fabian Vogelsteller a proposé l'EIP-20 (qui est devenu plus tard l'ERC-20), établissant les bases des tokens et devenant la pierre angulaire de la prospérité de DeFi ; encore, en 2017, Dieter Shirley (l'architecte en chef de CryptoKitties) et d'autres ont proposé l'EIP-721, qui est devenu le standard de base pour les NFT ; jusqu'à ce que des chercheurs communautaires comme Eric Conner lancent l'EIP-1559, apportant des améliorations disruptives au mécanisme de frais de transaction, influençant le modèle économique d'Ethereum.

On peut dire que c'est grâce à l'Open Source qu'Ethereum continue d'attirer de nouveaux développeurs et que les “contributions externes” deviennent progressivement des “normes de l'industrie”, formant un véritable effet de réseau.

Mais le problème est que l'Open Source n'est pas un déjeuner gratuit. Ce qu'elle apporte, ce n'est pas seulement la confiance et la co-construction, mais cela signifie aussi “abaissement des barrières, dilution de la défense”, ainsi qu'une concurrence ouverte.

Lorsque vous exposez le code source au grand jour, les concurrents peuvent presque le copier à zéro coût. C'est ainsi qu'innombrables “tueurs d'Ethereum” sont nés dans l'histoire : d'EOS à Tron, puis à toute une série de chaînes compatibles EVM, la plupart d'entre elles réutilisent directement la bibliothèque de code d'Ethereum, ne faisant que des ajustements sur le mécanisme de consensus, les paramètres de performance ou les subventions financières.

La même histoire se reproduit au niveau de l'application. Le plus typique est l'été DeFi de 2020. Uniswap a créé un nouveau paradigme de trading décentralisé avec son modèle AMM, mais en raison de la nature entièrement open source du contrat, SushiSwap a directement copié le code avec presque aucun coût de développement et a ajouté des incitations supplémentaires à l'exploitation de la liquidité. En quelques jours, plus d'un milliard de dollars de liquidité d'Uniswap a été siphonné, et le marché a même pensé que SushiSwap allait complètement le remplacer.

Il s'avère que l'Open Source a abaissé le seuil d'innovation, mais a également amplifié la “concurrence vampirique”. Les projets Web3 ont besoin non seulement d'un avantage technologique, mais aussi d'une accumulation continue en termes de marque, d'écosystème et de gouvernance, sinon le simple code ne suffit pas à constituer une barrière.

Cela a également conduit à un paradoxe : plus un projet est ouvert, plus il est facile de susciter des concurrents ; et plus le code est fermé, plus il est difficile de gagner la confiance des utilisateurs et des investisseurs.

Alors, que doivent faire les entrepreneurs Web3 ? Portal Labs pense que les points suivants pourraient apporter un soutien.

Premièrement, considérez l'Open Source comme un point de départ, et non comme une fin.

Le code open source peut attirer des développeurs et des communautés, mais ce qui détermine réellement la valeur d'un projet, c'est la construction continue qui suit. La raison pour laquelle Ethereum peut traverser les cycles n'est pas en raison de l'ouverture du code EVM, mais plutôt parce qu'il a formé un mécanisme de proposition EIP, un soutien de la fondation et une communauté de développeurs à long terme, ces “systèmes d'accompagnement”.

Pour les entrepreneurs Web3, l'Open Source n'est qu'une première étape, la barrière de protection doit être construite grâce à la gouvernance, à l'écosystème et aux effets de réseau.

Deuxièmement, il faut travailler sur la différenciation.

Uniswap n'a pas réussi à stabiliser sa position en raison de la singularité de son code, mais parce qu'elle a continué à construire ses propres barrières en dehors de l'Open Source. Elle a constamment lancé des itérations V2 et V3, introduisant en premier lieu la conception de liquidité centralisée, améliorant l'efficacité de l'utilisation des fonds ; elle attire les développeurs et la communauté à former des liens à long terme grâce à la fondation et au mécanisme de gouvernance ; plus important encore, Uniswap est devenu le “point d'entrée par défaut” du DeFi, sa reconnaissance de marque et son exploration de la conformité lui confèrent une position difficilement remplaçable.

Pour les entrepreneurs Web3, si vous choisissez l'Open Source, vous devez réfléchir : si d'autres copient le code, peuvent-ils copier l'expérience produit, l'ambiance communautaire, l'architecture de conformité et les relations de coopération ? Et c'est souvent cela qui détermine réellement la survie à long terme.

Troisièmement, utiliser l'Open Source comme “levier”.

L'open source n'est pas seulement un risque, il peut également amplifier le potentiel. De nombreux projets adoptent le “open source stratifié” - le protocole de base est open source, facilitant la co-construction par la communauté ; les algorithmes clés ou la couche d'application restent fermés, créant un équilibre. Par exemple, la logique de mise en relation de base de DYDX est open source, mais son contrôle des risques et le cœur du moteur de mise en relation restent fermés, assurant un avantage différentiel.

Il y a aussi des équipes qui considèrent l'Open Source comme un outil d'expansion commerciale, en abaissant les barrières d'entrée pour permettre aux autres de favoriser la croissance de l'écosystème. Des exemples typiques incluent Cosmos SDK et Polkadot Substrate, qui, grâce à leur cadre sous-jacent entièrement open source, attirent d'innombrables projets de chaînes publiques pour un développement secondaire dans leur écosystème, finissant par transformer “l'innovation des autres” en un effet de réseau pour eux-mêmes.

L'Open Source est à la fois la pierre angulaire de la confiance dans le Web3 et une épée à double tranchant pour les entrepreneurs. Il peut attirer des développeurs et favoriser l'écosystème, mais il amplifie également la concurrence et dilue les fossés de protection. Cependant, l'Open Source n'est pas une question de “faut-il ou non”, mais de “comment l'ouvrir”. Les véritables entrepreneurs intelligents du Web3 ne seront ni aveuglément fermés, ni naïvement ouverts, mais trouveront un chemin intermédiaire qui leur est propre entre confiance et concurrence.

Si vous décidez d'ouvrir le code, voici la liste des suggestions d'open source de Portal Labs :

1. Définir les limites

La couche de protocole, les contrats intelligents et autres codes de base devraient être entièrement open source pour établir la transparence et la confiance. Les algorithmes commerciaux, la logique de mise en correspondance et les modèles de gestion des risques peuvent être fermés, créant ainsi un avantage unique.

Il est conseillé de gérer les dépôts séparément sur GitHub, en indiquant la licence open source (comme MIT, GPL), tout en maintenant les modules internes de manière indépendante et fermée.

2. Construction institutionnalisée

Étudier le modèle EIP d'Ethereum, établir un processus de proposition (PR → Révision → Vote de la communauté).

Il est possible de créer un Discord public/un forum et d'établir une section « Soumission de propositions » ; organiser un appel communautaire fixe une fois par mois pour examiner les propositions.

3. Itérations rapides

Open Source signifie que d'autres peuvent copier le code, donc votre fossé doit reposer sur la vitesse d'itération.

Il est recommandé d'établir un rythme de « une petite version toutes les deux semaines, une grande version tous les trois mois » et de publier la feuille de route sur le site officiel ou dans le projet GitHub.

4. Marque et confiance

Dans le monde de l'Open Source, la technologie peut être copiée, mais la confiance ne peut pas l'être. Les véritables barrières proviennent souvent de l'atmosphère communautaire et de l'exploration de la conformité.

Il est conseillé de considérer l'audit de sécurité, l'approbation de conformité et les activités communautaires comme des “compétences de base”, par exemple

• Rapports d'audit publics réguliers ;
• Inviter un cabinet d'avocats à fournir un avis de conformité ;
• En gardant les utilisateurs et les développeurs dans l'écosystème grâce à des hackathons et des conférences de développeurs.

5.Leverage écologique

Considérez l'Open Source comme un outil pour attirer les développeurs et les entreprises, plutôt que comme un simple “don de code”.

Par exemple :

• Fournir SDK/modèles, réduire le seuil de développement secondaire ;
• Établir un programme de subventions pour financer des applications basées sur votre protocole ;
• Intégrer avec trois à cinq partenaires écologiques clés (portefeuilles, échanges, plateformes de données).