6 lärdomar jag lärde mig av att utveckla Open-Source-projekt

En dataforskares perspektiv

Öppen källkod är ett så fantastiskt koncept! Genom att kombinera källor, färdigheter och kunskaper från en hel gemenskap kan verktyg skapas som vi inte kunde ha gjort isolerat. Verktygen som kommer ut ur dessa samarbeten är verkligen mer än summan av deras delar.

Som ett resultat av detta använder vi datavetare denna fritt tillgängliga programvara som driver så många tekniker samtidigt som vi har möjlighet att vara delaktiga i utvecklingen.

Under de senaste åren har jag haft turen att vara involverad i öppen källkod och haft möjlighet att utveckla och hantera flera paket!

Att utveckla öppen källkod är mer än bara kodning

Under denna tid fanns det massor av hinder att övervinna och lärdomar att dra. Från knepiga beroenden och API-designval till kommunikation med användarbasen.

Att arbeta med öppen källkod, oavsett om det är författare, underhållare eller utvecklare, kan vara ganska skrämmande! Med den här artikeln delar jag några av mina erfarenheter inom detta område som förhoppningsvis hjälper dem som vill utveckla öppen källkod.

När du skapar programvara med öppen källkod, gör du vanligtvis inte paketet exklusivt för dig själv. Användare, från alla typer av olika bakgrunder, kommer att använda din programvara. Korrekt dokumentation kommer långt för att hjälpa dessa användare att komma igång.

Underskatta dock inte vilken inverkan dokumentation kan ha på användbarheten av ditt paket! Du kan använda den för att förklara komplexa algoritmer, ge omfattande handledningar, visa användningsfall och till och med möjliggöra interaktiva exempel.

Speciellt datavetenskapsrelaterad programvara kan vara svår att förstå när den involverar komplexa algoritmer. Att närma sig dessa förklaringar som en berättelse har ofta hjälpt mig att göra dem mer intuitiva.

Tro mig, att skriva bra dokumentation är en färdighet i sig.

En annan fördel är att att skriva gedigen dokumentation minskar tiden som läggs på frågor. Det finns mindre anledning för användare att ställa frågor om de kan hitta svaren i din dokumentation.

Men att skapa dokumentation är mer än att bara skriva den. Att visualisera din algoritm eller programvara gör det mycket intuitivt. Man kan lära sig ganska mycket av Jay Alammar när du vill visualisera algoritmiska principer i din dokumentation. Hans visualiseringar hamnade till och med i det officiella numpy dokumentation!

Din användarbas, gemenskapen, är en viktig komponent i din programvara. Eftersom vi utvecklar öppen källkod är det säkert att säga att vi vill att de ska vara delaktiga i utvecklingen.

Genom att engagera dig i communityn lockar du dem att dela problem och buggar, men också presentera förfrågningar och bra idéer för vidareutveckling! Alla dessa hjälper till att skapa något för dem.

Gemenskapen med öppen källkod är verkligen mer än summan av dess delar

Många kärnfunktioner i BERTopic, som ämnesmodellering online, har implementerats eftersom de var mycket efterfrågade av dess användare. Som ett resultat är communityn ganska aktiv och har varit till stor hjälp för att upptäcka problem och utveckla nya funktioner.

Oavsett om ditt paket kommer att användas miljontals gånger eller bara ett fåtal, är att skapa ett en utmärkt möjlighet att lära sig mer om öppen källkod, MLOps, enhetstestning, API-design, etc. Jag har lärt mig mer om dessa färdigheter i att utveckla öppen källkod än jag skulle ha i mitt dagliga jobb.

Det finns också en enorm möjlighet att lära sig genom att interagera med själva samhället. Det är de som talar om för dig vilken design de gillar eller inte. Ibland har jag sett samma problem dyka upp flera gånger under loppet av några månader. Detta tyder på att jag borde tänka om designen då den inte var så användarvänlig som jag hade räknat med!

Utöver det har utvecklingen av öppen källkodsprojekt gett mig möjligheten att samarbeta med andra utvecklare.

Att arbeta med egna projekt med öppen källkod utanför arbetet har sina nackdelar. För mig är det viktigaste att underhålla paketet, svara på frågor och delta i diskussionerna kan vara ganska mycket arbete.

Det hjälper definitivt om du är inneboende motiverad men det tar fortfarande ganska lång tid att se till att allt hålls ihop.

Lyckligtvis kan du vända dig till din community för att hjälpa dig när du svarar på frågor, visar upp användningsfall osv.

Under de senaste åren har jag lärt mig att vara lite mer avslappnad när det kommer till att bryta förändringar. Speciellt när det gäller beroenden, ibland finns det bara så mycket man kan göra!

Att veta hur ofta ditt paket används är en enorm hjälp för att förstå hur populärt det är. Men många använder fortfarande Github-stjärnor för att likställa ett paket med kvalitet och popularitet.

Som dataforskare måste vi först förstå vad det är som vi exakt mäter. GitHub-stjärnor är inget annat än en användare som ger en stjärna till ett paket. Det betyder inte ens att de har använt programvaran eller att den faktiskt fungerar!

Tekniskt sett kan jag betala tusen personer för att stjärna mina repor. Istället fokuserar jag på en mängd olika statistik, som nedladdningar och gafflar, men också antalet problem jag får dagligen.

Det är till exempel bra om dina paket visas på Hacker News men det säger inte om det används konsekvent.

Som psykolog tenderar jag att fokusera mycket på utformningen av mina paket. Detta inkluderar saker som dokumentation och handledning, men det översätter till och med hur jag kodar.

Att se till att paketet är lätt att använda och installera gör adoptionen mycket enklare. Speciellt när du fokuserar på designfilosofier som modularitet och transparens, blir vissa paket en blast att använda.

Att ta en psykologs perspektiv samtidigt som man utvecklar nya funktioner har gjort det mycket lättare att veta vad man ska fokusera på. Vad letar användarna efter? Hur kan jag koda på ett sätt som förklarar algoritmen? Varför använder användare egentligen detta paket? Vilka är de största nackdelarna med min kod?

Att ta sig tid att förstå den genomsnittliga användaren driver antagandet

Allt ovanstående leder ofta till en grundläggande men viktig regel;
Håll det superenkelt

Personligen, om jag tycker att ett nytt paket är svårt att installera och använda, är det mindre troligt att jag använder det i mitt arbetsflöde.

Om du, precis som jag, brinner för AI, datavetenskap eller psykologi får du gärna lägga till mig LinkedIn eller följ mig vidare Twitter. Du kan också hitta en del av mitt innehåll på min Personlig webbplats.

Alla bilder utan källa har skapats av författaren

6 lärdomar jag lärde mig av att utveckla Open-Source-projekt återpublicerade från källa https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 via https://towardsdatascience.com/feed

<!–

->