Comment puis-je trouver un bon projet open source à rejoindre?
Je viens de commencer à travailler il y a un an et je veux rejoindre un projet open source pour les mêmes raisons que n'importe qui d'autre: aider à créer quelque chose d'utile et développer mes compétences.
Mon problème est que je ne sais pas comment trouver un projet où je vais m'intégrer.
Comment trouver un projet adapté aux débutants? Quels attributs dois-je rechercher? Quels sont les signes avant-coureurs qu'un projet pourrait ne pas être le bon choix? Existe-t-il des outils pour aider à jumeler les gens avec des projets open source?
Il y a une question similaire ici , mais cette question concerne l'emploi et se limite à PHP/Drupal.
Ma première contribution open source a été pour une bibliothèque que j'avais précédemment utilisée (et qui aurait beaucoup souffert sans) sur un précédent projet payant. Lors de mon utilisation initiale, j'avais repéré un bogue dans le code, j'ai donc créé un correctif, rejoint le projet et soumis pour examen.
Environ 8 mois plus tard, alors que j'avais du temps libre, j'ai décidé de redonner (et de travailler sur mes compétences de développement) en contribuant davantage au projet. J'ai donc cloné le référentiel et commencé à me familiariser avec la base de code. Après quelques semaines de soumission de correctifs mineurs à la base de code et de surveillance des demandes de fonctionnalités, j'ai récupéré une demande de fonctionnalité pour ajouter un module assez important au projet.
Étant donné que la génération de nombreux correctifs individuels est assez fastidieuse pour tout développement significatif, j'ai cloné le référentiel dans une branche sur git hub et j'ai commencé à découper le code. Quelques semaines et plusieurs milliers de lignes de code plus tard, le chef de projet et moi-même avons travaillé à l'intégration et au test de mes correctifs dans la bibliothèque d'une manière compatible avec le reste de la base de code.
Ce fut un processus inestimable que j'ai beaucoup appris de:
- Quand j'ai commencé, je ne savais pas comment utiliser Git, à la fin, je pouvais créer efficacement des branches de suivi à distance et les fusionner ou les rebaser dans la branche principale sans casser une sueur.
- J'ai commencé dans VS 2008 et j'ai fini par migrer vers Linux et Monodevelop pour travailler sur l'écriture de code (parce que VS est retardé en Unicode et que les fins de ligne sont vraiment pénibles dans git). Il s'avère qu'il n'y a pas grand-chose que vous ne pouvez pas faire dans * nix que vous pouvez faire dans * dows.
- Je n'avais jamais vraiment fait de tests unitaires auparavant, Nunit est un jeu d'enfant et écrire des tests unitaires est assez élémentaire.
- J'ai dû apprendre à avaler ma langue et à écouter ainsi qu'à pratiquer la patience. Il ne sert à rien de prendre une position ferme sur votre position sur un projet open source parce que toutes les personnes impliquées sont bien informées (probablement plus que vous) et capables d'accepter/rejeter vos idées sur la base de la substance et non de la livraison. C'est extrêmement humiliant et gratifiant à la fois.
- Le simple fait d'avoir un autre développeur qualifié sur une grande base de mon code a souligné des défauts de mon style que je n'avais jamais envisagés auparavant (ainsi que des défauts de son code). Pour moi, j'ai appris qu'il est plus facile/mieux de définir des constantes que d'utiliser un tas de nombres magiques avec des commentaires détaillés.
Ce projet particulier était basé sur la génération et le décodage de paquets de mise en réseau à tous les niveaux des protocoles de mise en réseau. J'ai un intérêt personnel pour le réseautage de niveau inférieur, donc c'était génial d'avoir des discussions avec un autre développeur avec un intérêt et des connaissances partagés dans le domaine.
Si vous voulez simplement vous mouiller les pieds: trouvez un projet que vous utilisez déjà; cloner le référentiel; et commencez à voir si vous pouvez corriger certains bugs et/ou ajouter des tests unitaires. Il semble intimidant de regarder la base de code de quelqu'un d'autre avec des yeux neufs, mais c'est une compétence extrêmement précieuse à apprendre. Soumettez quelques correctifs. Vous pouvez vous attendre à ce que votre code soit attentivement examiné au début. Ne vous inquiétez pas, c'est une partie normale du processus pour gagner la confiance des administrateurs du projet.
Après avoir établi une base de mérite avec le (s) administrateur (s) du projet, commencez à rechercher plus de responsabilités telles que proposer de nouvelles fonctionnalités ou demander à être affecté à la mise en œuvre de demandes de fonctionnalités.
Si vous ne trouvez pas un projet déjà existant sur l'un des principaux réseaux de référentiels open source (github, sourceforge, google code) pensez à une application que vous aimeriez vraiment utiliser qui n'existe pas encore et démarrez la vôtre.
Soyez prêt à être humilié et attendez-vous à ce que le travail soit rejeté en faveur de nouvelles révisions. Le mythe selon lequel n'importe qui peut ajouter du code à un projet open source est complètement faux. Il y a toujours un gardien entre vous et l'accès Push. Plus votre code est bon, moins il sera examiné à long terme à mesure que vous gagnez la confiance des administrateurs du projet. Si c'est votre projet, vous serez ce gardien.
Mise à jour:
J'y ai juste réfléchi et j'ai réalisé que je n'ai pas pris la peine de mentionner le projet auquel une grande partie de ma réponse fait référence. Pour ceux qui veulent savoir, c'est SharpPcap . Le développeur principal Chris Morgan est très professionnel et sur le point. Il fait un sacré travail de gestion du projet et m'a beaucoup appris sur ce qu'il faut pour mûrir un projet OSS.
En raison de contraintes de temps personnelles, je n'ai pas été en mesure de contribuer au code depuis plus d'un an, mais j'essaie toujours de redonner en me cachant sur Stack Overflow et en répondant à des questions sur SharpPcap à l'occasion.
Voici ce que je vous propose de faire pour trouver votre match parfait:
Si vous avez un projet open-source que vous utilisez, connaissez et appréciez déjà, il devrait être votre premier candidat à essayer. Sinon, pensez à ce que vous aimeriez faire en général et recherchez un projet dans ce domaine.
Lorsque vous avez trouvé un projet potentiel, ne vous précipitez pas dessus. Essayez de l'utiliser vous-même. Est-il aussi bon en action qu'il n'y paraît d'après la description et les critiques? Sinon, ce n'est pas un bouchon complet; c'est peut-être l'occasion pour vous de vous lancer et de vraiment faire la différence. Après tout, personne n'a besoin d'un autre développeur pour un produit parfait. Mais cela vous donnera un aperçu important si vous souhaitez faire partie de ce projet, tout en acquérant une expérience de première main avec les nouvelles technologies dans un domaine qui vous intéresse.
Avant de commencer à investir trop de temps dans le projet et à en apprendre les tenants et les aboutissants, pensez également à vous promener dans les listes de diffusion, les forums et même le système de suivi des bogues du projet pendant quelques semaines. Si vous commencez à contribuer régulièrement au projet, vous y passerez beaucoup de temps.
Découvrez: aimez-vous traîner là-bas, ou est-ce un frein pour vous? Avez-vous l'impression que ce projet a une communauté bonne et énergique ou est-il en train de mourir lentement? Les personnes clés semblent-elles encourager et encadrer les nouveaux arrivants ou vous serez seul?
Suivez ces étapes pour plusieurs projets, potentiellement dans des domaines différents et vous êtes moins susceptible de subir une déception qui survient lorsque vous rejoignez une mauvaise équipe. Une telle expérience peut potentiellement vous décourager de recommencer à l'avenir.
Quelques réflexions supplémentaires:
Si le projet qui vous intéresse vraiment est un projet de grande envergure avec beaucoup de développeurs et d'activités autour de lui, vous aurez probablement du mal à y établir une réputation suffisante pour obtenir, disons, des droits ou un rôle intéressant dans la communauté. Dans ce cas, envisagez de rejoindre un projet dérivé associé avec une visibilité moindre. Par exemple, au lieu d'essayer de commencer à contribuer à jQuery, essayez de trouver le plugin jQuery qui vous conviendra le mieux. Plus tard, vous pouvez envisager de "monter".
Si vous aimez un projet mais vous sentez intimidé par sa taille, sa complexité ou les exigences de qualité du code, envisagez de commencer par les rôles de support, comme les tests, la maintenance de la documentation ou la vérification du rapport de bogue. Si vous demandez dans la liste de diffusion du projet de quel type d'aide ils ont le plus besoin en ce moment, ils seront plus qu'heureux de vous y guider. :)
De cette façon, vous apprendrez le projet et bâtirez votre réputation là-bas tout en y contribuant beaucoup plus que si vous commenciez à soumettre des correctifs inférieurs aux normes qui seraient rejetés plusieurs fois jusqu'à ce qu'ils soient prêts.
Le dernier et le plus important: si vous vous brûlez au même endroit, continuez; n'abandonnez pas.
J'espère que cela pourra aider.
Je vous recommande fortement de trouver un projet open source qui a votre sincère intérêt et que vous activement tilisez.
La raison est simple: elle fait la différence entre une corvée et un hobby.
Jetez un œil à votre ordinateur. Quel logiciel avez-vous mis dessus qui est Open Source? Une supposition serait Chrome ou Firefox, ou peut-être Open Office ou un client Instant Messenger. Sont-ils parfaits ou y a-t-il juste une petite chose que vous aimeriez changer si vous le pouviez?
S'il y en a, c'est maintenant le moment de faire quelque chose.
Je suggérerais de trouver (ou de démarrer) un projet comme les gens le font depuis des années, commencer à utiliser un logiciel Open Source pour faire des choses. Cela peut vous sembler banal, peut-être même trop simplifié. Pourtant, il est vraiment difficile de décrire la satisfaction d'utiliser quelque chose, de trouver un bogue, de saisir la source et de le corriger. Ou, peut-être le changer pour qu'il fonctionne comme vous le souhaitez.
De plus, ne vous contentez pas de pirater pour vous impliquer. 95% de mes correctifs pour le noyau Linux ne verront jamais le jour, je sais pour sûr que personne ne voudrait d'eux sauf moi, et je ' Je serais probablement obligé de subir une évaluation psychiatrique si un autre pirate du noyau compétent les voyait. Mais j'aime toujours mon implémentation de piglatin_printk() qui a commencé comme un gag du 1er avril il y a plusieurs années :)
Bien que oui, mettre votre code et votre processus de réflexion devant de nombreuses autres personnes compétentes est inestimable, tout comme apprendre à communiquer et à collaborer. Un projet solo est un excellent moyen de vous montrer quoi ne pas faire. Astuce, il ne suffit pas d'utiliser un logiciel de contrôle de version, des listes de diffusion et un suivi des bogues.
Pour commencer, je suggère de fouiller Ohloh pour trouver un logiciel qui pourrait vous intéresser en utilisant , d'abord. Téléchargez-le, construisez-le, jouez avec. Ensuite, allez chercher autre chose. Finalement, vous finirez par vouloir améliorer quelque chose, ou réaliserez que vous avez l'envie d'implémenter quelque chose de complètement différent de ce que vous avez trouvé.
L'autre chose qui aide est de travailler pour une entreprise ouverte et amicale. Mon entreprise utilise beaucoup Xen, donc ils n'ont aucun problème avec moi pour trouver des bogues intéressants et les corriger, car nous aurions besoin de le faire de toute façon. Cela ne dérange pas non plus les employés de participer à des choses comme les RFC et les projets de spécifications, car nous utiliserons finalement le résultat.
OpenHatch a été créé spécialement pour cela.
Citer:
OpenHatch est un organisme à but non lucratif dédié à la mise en correspondance des contributeurs potentiels de logiciels libres avec les communautés, les outils et l'éducation.
Vous pouvez parcourir les projets par type, technologie, niveau de compétence requis, etc. et trouver ce qui correspond à votre niveau.
Une chose que j'ai remarquée à plusieurs reprises en ce qui concerne les personnes qui cherchent à se lancer dans le développement open source est qu'elles sont dépassées par la complexité et l'ampleur des grands projets. J'ai fait face au même problème il y a quelques années, et d'après mon expérience, il vaut mieux ne pas regarder les grands projets tout de suite.
Après avoir passé quelque temps à regarder des projets qui pourraient me plaire, j'ai réalisé qu'ils étaient toujours hors de ma portée et j'ai ensuite commencé à travailler sur de très petits projets par moi-même. Je tiens à simplement publier le code sur Github, que ce soit vraiment pertinent ou que d'autres personnes commencent à l'utiliser. Finalement, les gens pourraient commencer à s'intéresser à ce que vous faites. Même autrement, vous gagnerez en confiance et en capacité technique pour passer lentement à des projets plus gros et plus populaires.
Quand j'ai commencé, j'ai cherché en ligne des options et il s'est avéré difficile de trouver quelque chose dans lequel vous pouvez vous enfoncer en tant que débutant.
Certains projets sont difficiles à contribuer non pas parce qu'ils sont trop avancés mais parce que la communauté n'est pas accueillante. Alors, ne vous découragez pas lorsque vous frappez un mur.
Au cours de la recherche, j'ai décidé de dresser une liste de 10 projets open source que les débutants peuvent commencer à soutenir sans processus trop stressants. Voici le lien à utiliser:
Dix projets pour les débutants à soutenir et à apprendre
J'espère que vous le trouverez utile et que vous pourrez toujours en ajouter d'autres si vous en trouvez de cool!
Je recommande la lecture: http://open-advice.org/ .
Il vise à aider ceux qui créent et maintiennent des communautés, et ceux qui ne savent pas avec certitude laquelle ils veulent rejoindre ou comment le faire.
A défaut, trouvez un projet qui a une mission qui résonne avec vous, ou bifurquez et contribuez à celui qui vous est déjà utile.
Bonne chance.
Il existe un nouveau site Web spécialement pour cela appelé Code 52 qui encourage les nouveaux développeurs à s'impliquer dans l'open source en démarrant un nouveau projet OSS chaque semaine.
L'idée est que cela semblera beaucoup moins intimidant pour les personnes qui n'ont jamais été impliquées dans l'open source auparavant et, espérons-le, se sentiront plus enclines à s'impliquer dans d'autres projets OSS.
Je vous propose de démarrer vous-même un projet sur un sujet qui vous intéresse.
Beaucoup peut être appris en travaillant sur un projet en général. Il n'est pas nécessaire de voir comment quelqu'un d'autre code pour apprendre à mieux coder. Et parfois, vous verrez réellement ce qu'il ne faut pas faire, car les autres personnes ne sont souvent pas plus expérimentées que vous.
Il est généralement utile de voir le code des autres, mais vous rencontrerez le code d'autres personnes dans votre propre projet uniquement via les bibliothèques et les composants que vous utilisez.
L'expérience vous apprendra ce qui est une bonne et une mauvaise pratique.
Je suis propriétaire d'un projet sur google code, et je recherche des contributeurs. (Pourtant, je vais pas abuser de cette réponse pour la publicité.) Par conséquent, mon avis pourrait être intéressant pour vous.
Vous devrez d'abord découvrir ce qui vous intéresse vous. Ensuite, développer une expertise dans certains domaines liés à vos intérêts. Trouvez ensuite un projet où votre expertise est demandée et nécessaire.
Plus le projet est petit, moins il y a de contributeurs, plus il y a de chances que des contributeurs soient recherchés et vous pouvez contacter directement les auteurs/propriétaires du projet. Dites-leur a) quelle est votre expertise b) où vous voyez qu'elle pourrait être appliquée dans le projet c) ce que vous pensez pouvoir réaliser.
Rappelez-vous: simplement connaître un ou deux langages de programmation traditionnels est pas expertise.