Quels facteurs déterminent le succès d'un projet open source? [fermé]

Question

Nous avons une série d’applications et de bibliothèques source fermées, pour lesquelles nous pensons qu’il serait judicieux d’ouvrir le code source.

Ce qui nous a bloqués jusqu'à présent, c'est l'effort nécessaire pour nettoyer la base de code et documenter la source avant de s'ouvrir.

Nous voulons ouvrir la source uniquement si nous avons une chance raisonnable que les projets aboutissent - c’est-à-dire des contributeurs. Nous sommes convaincus que le code serait intéressant pour un grand nombre de développeurs.

Quels facteurs, excluent le "caractère intéressant" et "utilité" du projet, déterminez-vous le succès d'un projet open source?

Exemples:

• Propreté du code
• Disponibilité des commentaires de code source
• API entièrement ou partiellement documentées
• Choix de la licence (GPL vs LGPL vs BSD, etc ...)
• Choix du référentiel public
• Investissement dans un site Web public

Answer 1

Plusieurs facteurs déterminent le succès du code. Tous ces objectifs doivent être atteints pour la moindre chance d’adoption.

• Marché - Il doit exister un marché pour votre projet open source. Si votre projet est un presse-agrumes orange dans l'espace, je doute que vous ayez beaucoup de succès. Vous devez vous assurer que votre projet est largement adopté par les utilisateurs et les développeurs. Il y a deux fois plus de chances de réussir si vous pouvez obtenir que d'autres sociétés l'adoptent également.
• Documentation - La clé est la documentation précédente. Cette documentation comprend du code commenté, des décisions architecturales et des notes d'API. Même si votre documentation contient des bugs, ou des bugs concernant votre logiciel, tout va bien. Rappelez-vous, la transparence est la clé.
• Liberté - Vous devez autoriser votre code à être "gratuit". - J'entends par là libre comme dans la parole, pas comme dans la bière. Si vous avez l’impression que votre marché est une bibliothèque pour d’autres sociétés, une licence BSD est optimale. Si votre logiciel est destiné à être utilisé sur les ordinateurs de bureau, alors GPL est votre choix.
• Transparence - Vous devez écrire un logiciel dans un environnement transparent. Une fois que vous allez open source, il n'y a pas de secrets cachés. Vous devez expliquer tout ce que vous faites et ce que vous faites. Cela va faire chier les développeurs pas comme les autres
• Communauté de développeurs - Une communauté de développeurs forte est requise. Cela doit être existant. Environ 5% seulement des utilisateurs contribuent au projet. Si quelqu'un remarque qu'il n'y a pas eu de parutions depuis un an, ils ne penseront pas: "Wow, ce logiciel est terminé", ils penseront que "les développeurs doivent le vider". Laissez vos développeurs travailler dessus, même si cela signifie qu'ils vous coûtent de l'argent.
• Communications - Vous devez vous assurer que votre communauté est capable de communiquer. Ils doivent pouvoir archiver les bogues, discuter des solutions de contournement et publier des correctifs. Sans retour d'information, il est inutile d'ouvrir le projet avec une source ouverte
• Disponibilité - Rendre votre code facile à obtenir est nécessaire, même si cela signifie faire chier les avocats. Vous devez vous assurer que votre projet est facile à télécharger et à utiliser. Vous ne voulez pas que l'utilisateur ait à passer par 18 écrans de nag et signer un contrat pour ce faire. Vous devez rendre les choses simples et propres

Answer 2

Je pense que le facteur le plus important est le nombre d'utilisateurs qui utilisent votre projet. Autrement, c’est un tas de choses vraiment bien écrites, utiles et bien documentées qui ne se trouvent pas sur un serveur ...

Answer 3

Pour acquérir des contributeurs, vous avez d’abord besoin d’utilisateurs, puis de lacunes. Vous devez activer le bouton "C’est cool, mais j’aurais vraiment aimé que cela soit ou était différent de cette façon". S'il vous manque une fonctionnalité évidente, il est fort probable qu'un utilisateur deviendra un contributeur pour l'ajouter.

Answer 4

La chose la plus importante est que le programme soit bon. Si ce n'est pas bon, personne ne l'utilisera. Vous ne pouvez pas espérer que l'œuf et la poule vont s'inverser et que les gens vont le prendre pour acquis jusqu'à ce que tout soit rentable.

Bien sûr, " bien " signifie simplement "mieux que toute autre option pratique pour un nombre significatif de personnes", cela ne signifie pas qu'il est strictement le meilleur, mais seulement qu'il possède certaines fonctionnalités qui le rendent, pour beaucoup de gens, meilleur que les autres options. Parfois, le programme n’a d’équivalent nulle part ailleurs, auquel cas il n’existe pratiquement aucune obligation à cet égard.

Lorsqu'un programme est bon, les gens l'utiliseront. De toute évidence, il doit avoir un marché parmi les utilisateurs - un bon programme qui fait quelque chose que personne ne veut, n'est pas très bon, peu importe la qualité de sa conception. On peut parler de marketing, mais les produits vraiment bons, jusqu’à un certain point, ont tendance à se vendre eux-mêmes. Il est beaucoup plus difficile de promouvoir quelque chose qui n’est pas bon. Il est donc clair que la priorité absolue doit être le produit lui-même, et non sa promotion.

La vraie question est donc: comment le rendez-vous bon? Et la réponse à cette question est une équipe de développement dédiée et compétente. Une personne peut rarement créer elle-même un bon produit. même s'ils sont bien meilleurs que les autres développeurs, les perspectives multiples ont un effet incroyablement utile sur le projet. C'est pourquoi il est si utile de parrainer des entreprises. Cela incite les autres développeurs (de l'entreprise) à prendre conscience du problème et à donner leur propre opinion. Ceci est particulièrement utile dans le cas où le développement du programme nécessite une expertise considérable qui n’est pas couramment disponible dans la communauté.

Bien sûr, je dis tout cela par expérience. Je suis l'un des principaux développeurs de x264 (actuellement le plus actif), l'un des encodeurs vidéo les plus populaires. Nous avons deux développeurs principaux, plusieurs développeurs mineurs de la communauté qui apportent des correctifs et un parrainage d'entreprise de Joost (Gabriel Bouvigne, qui gère les algorithmes de contrôle des contrôles), d'Avail Media (pour qui je travaille parfois sous contrat et qui embauche actuellement des codeurs). ajouter le support d’entrelacement MBAFF), et parmi quelques autres qui apparaissent de temps en temps.

Un bon développeur ne fait pas un projet - beaucoup de bons développeurs le font. Et le résultat final de ceci est un programme qui code la vidéo plus rapidement et avec une qualité bien meilleure que celle de la plupart des concurrents commerciaux, matériels ou logiciels, même ceux avec des budgets de développement extrêmement élevés.

Answer 5

En examinant ces problèmes, consultez la version en ligne d'un cours sur l'open source à l'UC Berkeley , intitulé Développement et diffusion de l'information numérique en open source: perspectives techniques, économiques, sociales et juridiques. Il est co-enseigné par Mitch Kapur (fondateur de Lotus) et Paula Samuelson, professeur de droit. L’année dernière, j’ai fait un long trajet et jeté le son du cours sur mon iPod - ils parlent beaucoup de ce qui fonctionne, de ce qui ne fonctionne pas et pourquoi, dans une perspective très large (bien qu’évidemment académique).

Answer 6

Des livres ont été écrits sur le sujet. En fait, vous pouvez trouver un livre gratuit ici: produire un logiciel open source

Answer 7

Vraiment, je pense que la réponse est "comment vous gérez le projet".

Tous vos exemples sont importants, oui, mais l'essentiel est de savoir comment gérer les interactions entre développeurs, comment les correctifs, etc. sont gérés / acceptés, qui est le "responsable" et comment ils gèrent cette responsabilité, et ainsi de suite. .

Comparez et mettez en contraste (l'historique n'est pas difficile à retracer!) la gestion du développement de Class :: DBI et DBIx :: Class en Perl.

Answer 8

Je lisais ce soir un excellent article sur l'aspect convivialité des projets open source réussis ou infructueux.

Extrait:

  

Beaucoup de bande passante a été gaspillée en raison du manque de convivialité dans les logiciels libres / logiciels libres (ci-après «OSS»). Le débat se poursuit actuellement sur les blogs, les forums et les fils de commentaires de Slashdot. Certaines personnes disent que la mauvaise convivialité est endémique dans le monde des logiciels libres, tandis que d'autres disent que la facilité d'utilisation des logiciels libres est grande, mais que le véritable problème réside dans les utilisateurs fermés qui s'attendent à ce que chaque programme clone Microsoft. Certaines personnes affirment que les problèmes d’assurance-chômage sont des douleurs de croissance temporaires, tandis que d’autres affirment que le modèle de développement du logiciel libre produit systématiquement une mauvaise interface utilisateur. Certaines personnes prétendent même que la GPL récompense indirectement les logiciels difficiles à utiliser! (Pour mémoire, je ne suis pas d'accord.)

     

http://humanized.com/weblog/2007/10/05/ make_oss_humane /

Answer 9

Ouvrez-le simplement. Très probablement, personne ne commencera à contribuer pour le moment. Mais au moins, vous pouvez écrire dans les communiqués de presse que votre produit est en GPL ou autre.

La première étape est que les gens commencent à l'utiliser ...
Et peut-être qu'après, les utilisateurs se sentiront à l'aise, ils commenceront à contribuer

Answer 10

Les réponses de tout le monde ont été bonnes jusqu'à présent, mais il manque un élément, à savoir un bon contrôle. Rien ne tue un projet open source plus rapidement que de ne pas avoir une sorte de gestion de projet. Ne dites pas aux gens quoi faire au point d’ajouter une structure et des tâches aux développeurs que vous espérez attirer.

Les projets désorganisés se désagrègent rapidement. Ce n'est pas un oiseau que vous laissez simplement aller et regardez-le s'envoler.