6 Leksjoner jeg lærte av å utvikle åpen kildekode-prosjekter

En dataforskers perspektiv

Åpen kildekode er et fantastisk konsept! Ved å samle kildene, ferdighetene og kunnskapen til et helt fellesskap, kan det skapes verktøy som vi ikke kunne ha laget isolert. Verktøyene som kommer ut av disse samarbeidene er virkelig mer enn summen av delene deres.

Som et resultat bruker vi dataforskere denne fritt tilgjengelige programvaren som driver så mange teknologier, samtidig som de fortsatt har muligheten til å være involvert i utviklingen.

I løpet av de siste årene har jeg vært så heldig å være involvert i åpen kildekode og hatt muligheten til å utvikle og administrere flere pakker!

Å utvikle åpen kildekode er mer enn bare koding

I løpet av denne tiden var det mange hindringer å overvinne og lærdom å lære. Fra vanskelige avhengigheter og API-designvalg til kommunikasjon med brukerbasen.

Å jobbe med åpen kildekode, enten som forfatter, vedlikeholder eller utvikler, kan være ganske skremmende! Med denne artikkelen deler jeg noen av mine erfaringer på dette feltet som forhåpentligvis hjelper de som ønsker å utvikle åpen kildekode.

Når du lager åpen kildekode-programvare, lager du vanligvis ikke pakken eksklusivt for deg selv. Brukere, fra alle typer forskjellige bakgrunner, vil bruke programvaren din. Riktig dokumentasjon hjelper disse brukerne langt i å komme i gang.

Men ikke undervurder effekten dokumentasjon kan ha på brukbarheten av pakken din! Du kan bruke den til å forklare komplekse algoritmer, gi omfattende opplæringsprogrammer, vise brukstilfeller og til og med tillate interaktive eksempler.

Spesielt datavitenskap-relatert programvare kan være vanskelig å forstå når det involverer komplekse algoritmer. Å nærme seg disse forklaringene som en historie har ofte hjulpet meg med å gjøre dem mer intuitive.

Stol på meg, å skrive god dokumentasjon er en ferdighet i seg selv.

En annen fordel er at det å skrive solid dokumentasjon reduserer tiden brukt på saker. Det er mindre grunn for brukere til å stille spørsmål hvis de finner svarene i dokumentasjonen din.

Å lage dokumentasjon er imidlertid mer enn bare å skrive den. Visualisering av algoritmen eller programvaren gjør det langt på vei intuitivt. Du kan lære ganske mye av Jay Alammar når du ønsker å visualisere algoritmiske prinsipper i dokumentasjonen. Visualiseringene hans havnet til og med i det offisielle Klumpete dokumentasjon!

Din brukerbase, fellesskapet, er en viktig komponent i programvaren din. Siden vi utvikler åpen kildekode, er det trygt å si at vi ønsker at de skal være involvert i utviklingen.

Ved å engasjere seg i fellesskapet lokker du dem til å dele problemer og feil, men også ha forespørsler og gode ideer for videre utvikling! Alle disse er med på å skape noe for dem.

Åpen kildekode-fellesskapet er virkelig mer enn summen av delene

Mange kjernefunksjoner i BERTopic, som nettbasert emnemodellering, har blitt implementert siden de ble sterkt etterspurt av brukerne. Som et resultat er fellesskapet ganske aktivt og har vært en enorm hjelp til å oppdage problemer og utvikle nye funksjoner.

Enten pakken din vil bli brukt millioner av ganger eller bare noen få, er å lage en en utmerket mulighet til å lære mer om åpen kildekode, MLOps, enhetstesting, API-design osv. Jeg har lært mer om disse ferdighetene i å utvikle åpen kildekode enn jeg ville hatt i min daglige jobb.

Det er også en enorm læringsmulighet ved å samhandle med samfunnet selv. Det er de som forteller deg hvilke design de liker eller ikke. Noen ganger har jeg sett det samme problemet dukke opp flere ganger i løpet av noen måneder. Dette indikerer at jeg burde tenke nytt om designet da det ikke var så brukervennlig som jeg hadde forutsett!

På toppen av det har utvikling av åpen kildekode-prosjekter gitt meg muligheten til å samarbeide med andre utviklere.

Å jobbe med egne åpen kildekode-prosjekter utenom jobben har sine ulemper. For meg er det viktigste at det kan være ganske mye arbeid å vedlikeholde pakken, svare på spørsmål og delta i diskusjonene.

Det hjelper definitivt hvis du er iboende motivert, men det tar fortsatt litt tid å sørge for at alt holdes sammen.

Heldigvis kan du se til fellesskapet ditt for å hjelpe deg når du svarer på spørsmål, viser brukstilfeller osv.

I løpet av de siste årene har jeg lært å være litt mer avslappet når det kommer til å bryte endringer. Spesielt når det gjelder avhengigheter, noen ganger er det bare så mye du kan gjøre!

Å vite hvor ofte pakken din brukes er en enorm hjelp for å forstå hvor populær den er. Imidlertid bruker mange fortsatt Github-stjerner for å sette likhetstegn mellom en pakke og kvalitet og popularitet.

Som dataforskere må vi først forstå hva det er vi nøyaktig måler. GitHub-stjerner er ikke noe mer enn en bruker som gir en stjerne til en pakke. Det betyr ikke engang at de har brukt programvaren eller at den faktisk fungerer!

Teknisk sett kan jeg betale tusen mennesker for å stjernebeholdningen min. I stedet fokuserer jeg på en rekke statistikker, som nedlastinger og gafler, men også antallet problemer jeg får på daglig basis.

For eksempel er det flott hvis pakkene dine blir omtalt Hacker Nyheter men den forteller deg ikke om den brukes konsekvent.

Som psykolog har jeg en tendens til å fokusere mye på utformingen av pakkene mine. Dette inkluderer ting som dokumentasjon og veiledninger, men det oversetter til og med hvordan jeg koder.

Å sørge for at pakken er enkel å bruke og installere gjør adopsjon mye enklere. Spesielt når du fokuserer på designfilosofier som modularitet og åpenhet, blir noen pakker en blast å bruke.

Å ta perspektivet til en psykolog mens du utvikler nye funksjoner har gjort det mye lettere å vite hva du skal fokusere på. Hva leter brukerne etter? Hvordan kan jeg kode på en måte som forklarer algoritmen? Hvorfor bruker brukerne egentlig denne pakken? Hva er de største ulempene med koden min?

Å ta seg tid til å forstå den gjennomsnittlige brukeren fører til bruk

Alt det ovennevnte fører ofte til en grunnleggende, men viktig regel;
Hold det superenkelt

Personlig, hvis jeg synes en ny pakke er vanskelig å installere og bruke, er det mindre sannsynlig at jeg tar den i bruk i arbeidsflyten min.

Hvis du, som meg, brenner for AI, datavitenskap eller psykologi, kan du gjerne legge meg til Linkedin eller følg meg videre Twitter. Du kan også finne noe av innholdet mitt på min Personlig nettsted.

Alle bilder uten kildekreditt ble laget av forfatteren

6 leksjoner jeg lærte av å utvikle åpen kildekode-prosjekter publisert på nytt fra kilde https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 via https://towardsdatascience.com/feed

<!–

->