6 lessen die ik heb geleerd bij het ontwikkelen van open source-projecten

Het perspectief van een datawetenschapper

Open-source is zo'n geweldig concept! Door de bronnen, vaardigheden en kennis van een hele gemeenschap te bundelen, kunnen tools ontstaan ​​die we op zichzelf niet hadden kunnen maken. De tools die uit deze samenwerkingen voortkomen, zijn werkelijk meer dan de som der delen.

Als gevolg hiervan gebruiken wij datawetenschappers deze vrij beschikbare software die zoveel technologieën aanstuurt, terwijl we nog steeds de mogelijkheid hebben om betrokken te zijn bij de ontwikkeling ervan.

De afgelopen jaren had ik het geluk betrokken te zijn bij open-source en kreeg ik de kans om verschillende pakketten te ontwikkelen en te onderhouden!

Het ontwikkelen van open source is meer dan alleen coderen

Gedurende deze tijd waren er tal van hindernissen die moesten worden overwonnen en lessen die moesten worden geleerd. Van lastige afhankelijkheden en API-ontwerpkeuzes tot communicatie met het gebruikersbestand.

Werken aan open source, of je nu als auteur, beheerder of ontwikkelaar bent, kan behoorlijk intimiderend zijn! Met dit artikel deel ik enkele van mijn ervaringen op dit gebied, wat hopelijk degenen helpt die open-source willen ontwikkelen.

Wanneer u open-sourcesoftware maakt, maakt u het pakket doorgaans niet exclusief voor uzelf. Gebruikers met allerlei verschillende achtergronden zullen gebruik maken van uw software. Goede documentatie helpt deze gebruikers al een heel eind op weg.

Onderschat echter niet de impact die documentatie kan hebben op de bruikbaarheid van uw pakket! Je kunt het gebruiken om complexe algoritmen uit te leggen, uitgebreide tutorials te geven, use cases te laten zien en zelfs interactieve voorbeelden mogelijk te maken.

Vooral data science-gerelateerde software kan moeilijk te begrijpen zijn als het om complexe algoritmen gaat. Door deze verklaringen als een verhaal te benaderen, heb ik ze vaak intuïtiever kunnen maken.

Geloof me, het schrijven van goede documentatie is een vaardigheid op zich.

Een ander voordeel is dat het schrijven van solide documentatie de tijd die aan problemen wordt besteed, verlaagt. Er is minder reden voor gebruikers om vragen te stellen als ze de antwoorden in uw documentatie kunnen vinden.

Het maken van documentatie is echter meer dan alleen het schrijven ervan. Door uw algoritme of software te visualiseren, kunt u deze intuïtief maken. Je kunt er heel veel van leren Jay Alammar wanneer u algoritmische principes in uw documentatie wilt visualiseren. Zijn visualisaties kwamen zelfs in de ambtenaar terecht numpy documentatie!

Uw gebruikersbestand, de community, is een belangrijk onderdeel van uw software. Omdat we open-source ontwikkelen, kunnen we met zekerheid zeggen dat we willen dat zij bij de ontwikkeling worden betrokken.

Door met de community in gesprek te gaan, verleid je hen om problemen en bugs te delen, maar ook om verzoeken en geweldige ideeën voor verdere ontwikkeling te melden! Dit alles helpt om iets voor hen te creëren.

De open-sourcegemeenschap is echt meer dan de som der delen

Veel kernfuncties in BERTopic, zoals online onderwerpmodellering, zijn geïmplementeerd omdat er veel vraag naar was door de gebruikers. Als gevolg hiervan is de community behoorlijk actief en heeft ze enorm geholpen bij het opsporen van problemen en het ontwikkelen van nieuwe functies.

Of uw pakket nu miljoenen keren of slechts een paar keer zal worden gebruikt, het maken ervan is een uitstekende gelegenheid om meer te leren over open-source, MLOps, unit-testen, API-ontwerp, enz. Ik heb meer over deze vaardigheden geleerd bij het ontwikkelen van open-source dan ik in mijn dagelijkse werk zou hebben.

Er schuilt ook een enorme leermogelijkheid in de interactie met de gemeenschap zelf. Zij zijn degenen die je vertellen welke ontwerpen ze leuk vinden of niet. Soms heb ik hetzelfde probleem in de loop van een paar maanden verschillende keren zien opduiken. Dit geeft aan dat ik het ontwerp moest heroverwegen, aangezien het niet zo gebruiksvriendelijk was als ik had verwacht!

Bovendien heeft het ontwikkelen van open-sourceprojecten mij de mogelijkheid gegeven om samen te werken met andere ontwikkelaars.

Buiten het werk aan uw eigen open-sourceprojecten werken, heeft zijn nadelen. Het belangrijkste vind ik dat het onderhouden van het pakket, het beantwoorden van vragen en het deelnemen aan de discussies behoorlijk wat werk kan zijn.

Het helpt zeker als je intrinsiek gemotiveerd bent, maar het kost toch behoorlijk wat tijd om alles bij elkaar te houden.

Gelukkig kunt u naar uw community kijken om u te helpen bij het beantwoorden van vragen, het presenteren van gebruiksscenario's, enz.

In de loop van de afgelopen jaren heb ik geleerd wat meer ontspannen te zijn als het gaat om het doorbreken van veranderingen. Zeker als het om afhankelijkheden gaat, kun je soms zoveel doen!

Weten hoe vaak uw pakket wordt gebruikt, is een enorme hulp om te begrijpen hoe populair het is. Velen gebruiken echter nog steeds Github-sterren om een ​​pakket gelijk te stellen aan kwaliteit en populariteit.

Als datawetenschappers moeten we eerst begrijpen wat we precies meten. GitHub-sterren zijn niets meer dan een gebruiker die een ster aan een pakket geeft. Het betekent niet eens dat ze de software hebben gebruikt of dat deze daadwerkelijk werkt!

Technisch gezien kan ik duizend mensen betalen om mijn repo's een ster te geven. In plaats daarvan concentreer ik me op een verscheidenheid aan statistieken, zoals downloads en forks, maar ook het aantal problemen dat ik dagelijks krijg.

Het is bijvoorbeeld leuk als jouw pakketten in de spotlight komen te staan Hacker News maar het vertelt u niet of het consequent wordt gebruikt.

Als psycholoog ben ik vaak veel bezig met het ontwerp van mijn pakketten. Dit omvat zaken als documentatie en tutorials, maar het vertaalt zich zelfs in de manier waarop ik codeer.

Door ervoor te zorgen dat het pakket gemakkelijk te gebruiken en te installeren is, wordt de adoptie veel eenvoudiger. Vooral als je je richt op ontwerpfilosofieën zoals modulariteit en transparantie, worden sommige pakketten geweldig om te gebruiken.

Door het perspectief van een psycholoog te nemen bij het ontwikkelen van nieuwe functies, is het veel gemakkelijker geworden om te weten waar je je op moet concentreren. Waar zijn gebruikers naar op zoek? Hoe kan ik coderen op een manier die het algoritme verklaart? Waarom gebruiken gebruikers dit pakket eigenlijk? Wat zijn de grootste nadelen van mijn code?

De tijd nemen om de gemiddelde gebruiker te begrijpen, stimuleert de adoptie

Al het bovenstaande leidt vaak tot een fundamentele maar belangrijke regel;
Houd het supereenvoudig

Persoonlijk, als ik een nieuw pakket moeilijk te installeren en te gebruiken vind, is de kans kleiner dat ik het in mijn workflow zal gebruiken.

Als je, net als ik, gepassioneerd bent door AI, Data Science of Psychologie, voeg me dan gerust toe LinkedIn of volg mij verder Twitter. Je kunt ook een deel van mijn inhoud vinden op mijn Persoonlijke website.

Alle afbeeldingen zonder bronvermelding zijn gemaakt door de auteur

6 lessen die ik heb geleerd bij het ontwikkelen van open-sourceprojecten, opnieuw gepubliceerd vanuit de bron https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 via https://towardsdatascience.com/feed

<!–

->