"Curly and Bazaar" que seuls ceux qui travaillent dans une entreprise solide veulent lire

À propos de "Curly and Bazaar"

Depuis combien de temps lisez-vous?

D'une manière ou d'une autre, "Mythe de la Lune", "Bear and Waltz" ou "Extreme Programming (White)" Je pense personnellement que c'est l'un des supports de lecture classiques de la programmation, comme "Book)".

Cependant, j'ai lu les trois livres que j'ai énumérés, mais en fait, la cathédrale et le bazar sont passés.

La raison en est qu'il s'agit d'un livre développé sur le modèle de développement des logiciels OSS, en particulier Linux. À cette époque, lorsque je lisais et que je cherchais des supports de lecture classiques, ce n'était pas un sujet très intéressant. Parce que j'écrivais exclusivement des logiciels professionnels et sur site.

J'ai ressenti une couleur de cheveux très différente de celle de "Human Moon Myth" qui critique la facilité des interventions du personnel, "Kuma to Waltz" qui enseigne la gestion des risques et "Extreme Programming" qui ressent le développement agile. droite.

La page d'introduction du livre d'Amazon dit également "un livre incontournable pour les utilisateurs de Linux et de l'open source (OSS)", et bien sûr je pense que c'est correct, mais ** je pense qu'il est facile de trop restreindre les lecteurs. C'est vrai **. [^ 1]

En particulier, c'est un livre qui montre comment le développement de logiciels devrait être dans un monde où tout devient de plus en plus ouvert maintenant.

J'ai dit que c'était un livre, mais c'est un livre que j'ai écrit sur OSS. Les livres et traductions eux-mêmes sont OSS sous Creative Commons.

• Curly and Bazaar

En fait, en plus de ce qui précède, la version du livre comprend "Know Asphere Clearing" et "[Magic Pot](https://cruel.org/freeware/magicpot. html) », et une interview du traducteur Yamagata Sensei est également incluse dans l'ensemble, mais cette fois nous couvrirons jusqu'à« Garai and Bazaar ». C'est assez intéressant donc si vous ne l'avez pas lu, faites-le. La quantité de PDF est d'environ 40 pages, ce qui est très facile à lire.

Incompréhension de la métafa de "Curly and Bazaar"

Si vous connaissez un peu les cathédrales et les bazars, ou si vous connaissez l'histoire de la bataille entre les OSS et les grandes entreprises (entreprises de fenêtres, entreprises bleues, entreprises rouges, etc.), les «cathédrales» sont des grandes entreprises manuelles. Vous pourriez penser au développement propriétaire et fermé, et au bazar comme au développement de logiciel libre avec OSS.

Je veux que les gens qui le pensent le lisent. Parce que ** la cathédrale et le bazar ne sont pas des métaphores des grandes entreprises et des OSS. ** **

Citons le texte. La cathédrale est le modèle suivant.

Mais à un niveau supérieur, je pensais aussi qu'il y aurait une complexité inévitable qui nécessiterait une approche plus centralisée et plus apriori. Le logiciel le plus important (OS et de très gros outils comme Emacs) doit être assemblé comme une cathédrale, et un sorcier ou un petit groupe de magiciens doit l'assembler complètement isolé et soigneusement. Je pensais que je devais publier la version bêta jusqu'à ce qu'elle soit terminée.

Oui, ** une cathédrale est un modèle de série qui suppose une grande conception dès le départ **.

Alors, quel est le modèle du bazar?

J'ai été totalement surpris par le style de développement de Linus Tovals sorti tout le temps, laissant tout ce qui me restait et ouvrant tout dans le désordre.

Un bazar est un modèle de développement ouvert et itératif qui suppose des cycles de publication fréquents **.

En d'autres termes, dans le langage profane d'aujourd'hui (bien que pleinement conscient qu'il y a une influence comme définition),

• ** Garan = cascade et centralisé **
• ** Bazar = Agile et auto-organisé **

Je pense que cela peut être dit.

Bien sûr, il existe de nombreux modèles de cathédrales dans les grandes entreprises, et il existe de nombreux modèles de bazars dans OSS, mais la cathédrale et le bazar se réfèrent uniquement au modèle de développement, pas à la forme du projet. Ce que je veux dire, c'est que ** certains éléments de bazar peuvent être appliqués même en développement fermé au sein d'une entreprise **.

Ce qui est écrit dans "Curly and Bazaar"

Ce qui est écrit dans la cathédrale et le bazar est ** une analyse de «pourquoi le modèle de bazar fonctionne» **. Et il convient de noter que cette analyse a été effectuée dans les années 1990.

Parce qu'à cette époque, même Git n'existait pas, encore moins Github (Linus a créé Git juste après que cette phrase ait été traduite en japonais). Bien sûr, il n'y a pas non plus de Slack. Il n'y a que des listes de diffusion et des premiers WWW.

Ce n'est qu'une vieille histoire pour ceux qui connaissent Github moderne, mais qu'en est-il de votre organisation? ** Le système interne de partage d'informations n'a-t-il pas été arrêté dans les années 90? ** N'y a-t-il pas encore beaucoup de gens qui communiquent principalement par e-mail et le code source est finalement téléchargé sur le serveur de fichiers partagé, même s'il n'y a que SVN?

Oui, même dans une telle situation, vous pouvez voir dans ce livre que le modèle du bazar fonctionne. Cela signifie: "Si vous êtes satisfait, n'importe quelle entreprise peut le faire."

Comment fonctionne le modèle du bazar

Alors, pourquoi le modèle de bazar non ordonné fonctionne-t-il, "Je le libère tout le temps, je le laisse à moi et j'ouvre tout au désordre?"

Il y a de nombreux points dans ce livre, mais je pense personnellement que les trois suivants sont importants.

• ** Animé par la passion personnelle du développeur ** ――Au contraire, si vous perdez votre passion, sortez du
• ** Traitez les utilisateurs comme des co-développeurs **
• Devenir un excellent testeur bêta, débogueur et fixateur
• ** Continuer à attirer l'intérêt et la passion des utilisateurs **
• Libérations fréquentes --Visualisation de la contribution

Avant tout, même s'il s'agit d'un modèle de bazar, c'est le chef du bazar, Linus sous Linux et RMS chez Emacs. Cela peut être un individu ou une équipe, mais dans tous les cas, le bazar a quelqu'un qui peut librement déterminer son cours (et se voir confier par tout le monde de le faire). Le projet est animé par la passion personnelle de la personne.

Et dans le bazar, les utilisateurs des logiciels et des bibliothèques sont traités comme des co-développeurs. Bien entendu, la condition serait que l'utilisateur soit également passionné par l'utilisation du logiciel.

Et il y a des développeurs passionnés, des utilisateurs passionnés, et une autre chose dont nous avons besoin est un mécanisme pour garder la passion. Ceci est assuré par des communiqués fréquents, la visualisation des contributions et plus spécifiquement la transparence du projet lui-même.

Les développeurs passionnés ouvrent leur logiciel, acquièrent des utilisateurs enthousiastes grâce à des versions et des contributions fréquentes, et les contributions de ces utilisateurs enthousiastes développent davantage le projet.

De manière très simple, ce flux est le fonctionnement du modèle de bazar.

Le modèle du bazar est-il applicable au sein de l'entreprise?

Lors de l'examen du processus ci-dessus, est-il possible d'introduire un tel processus dans l'entreprise?

Je pense personnellement que je peux le faire. Je pense qu'il existe une approche appelée «OSS interne» pour certaines grandes entreprises et «OSS partiel» pour les petites et moyennes entreprises.

OSS interne

Littéralement, il s'agit de publier le code source en interne et de promouvoir le projet. Vous pouvez publier chaque projet lui-même, mais si cela est difficile, vous pouvez penser aux outils, aux bibliothèques ou au code IaC utilisés dans ce projet. Je pense que l'important n'est pas seulement de le rendre public, mais de l'utiliser correctement dans notre projet, et de lui donner une certaine propriété en lui donnant la propriété du dépôt.

Pour raconter et entendre diverses histoires, je pense que Google est l'entreprise qui le fait le plus activement. Bien sûr, Google lui-même joue un rôle assez pionnier dans OSS, mais plus que cela, Google crée de nouveaux produits et OSS à partir de ses propres outils.

Kubernetes, par exemple, n'est plus la norme pour les outils d'orchestration de conteneurs, mais il doit à l'origine être dérivé des outils internes et fermés de Google. En conséquence, Kubernetes est devenu OSS, mais il semble que d'autres outils qui sont sur GCP utilisent à bon escient les outils internes et les déploient dans les produits. N'est-ce pas la preuve que le modèle de bazar interne fonctionne?

OSS partiel

Il s'agit d'une méthode dans laquelle la partie principale reste propriétaire sans être convertie en OSS, et les outils périphériques sont convertis en OSS. Shiguredo est celui qui vient à l'esprit de cette manière. Shiguredo est fermé et professionnel sur son produit de base "WebRTC SFU Sora", mais ses outils périphériques sont souvent OSS. [^ 2]

Et concernant le groupe OSS, des fonctions sont ajoutées tandis que des discussions animées sont en cours sur le serveur Discord, et en même temps la vitesse de développement est maintenue, l'ouverture attire les développeurs, et probablement les ventes de Sora lui-même sont également considérables. Il semble qu'ils apportent une contribution.

De cette manière, il devrait être possible * d'incorporer l'aspect OSS en tant qu'entreprise et d'incorporer les avantages de la méthode bazar **.

Quelles sont les conditions dans lesquelles une entreprise peut adopter le modèle du bazar?

Cependant, je ne pense pas que ce processus fonctionne pour aucune entreprise. Si la «transparence» et le «mou» ne sont pas assurés au sein de l'entreprise, il sera difficile de la développer.

transparence

La première chose dont vous avez besoin est la transparence. Dans chaque projet, il est très important de présenter une feuille de route pour l'avenir ainsi que l'état actuel du type de technologie en cours de fabrication.

Qu'il soit publié en interne ou en externe, il devrait être difficile de le faire utiliser en premier lieu à moins qu'il ne fasse toujours appel à une transparence technique sans dissimulation étrange.

Mou

Ce n'est pas un outil de chat. C'est ici.

Que ce soit à l'intérieur ou à l'extérieur de l'entreprise, ces activités OSS ne sont pas possibles si l'opération est réduite à 100%. La règle des 20% de Google est bien connue, mais le modèle du bazar ne fonctionnera que si vous avez le temps de vous consacrer à la fabrication de produits en premier lieu.

À la fin

C'est pourquoi je l'ai écrit régulièrement. Personnellement, j'ai toujours l'impression d'avoir une bonne perspective sur la façon de développer le logiciel de l'entreprise, alors je l'ai écrit brièvement.

Je pense que je vais relire le classique. C'était un bon livre.

[^ 1]: Je pense que cela peut être peu disposé pour la communauté OSS, et le processus de développement qui n'est pas vraiment ouvert et le processus OSS sont fondamentalement complètement différents! Je pense qu'il y a des critiques. En tant qu'essence [^ 2]: En fait, on peut dire que Sora lui-même ressemble assez à OSS en raison de sa fréquence de sortie élevée et de sa feuille de route ouverte.