R-pakketten vereisen, net als alle software, onderhoud. Pakketonderhoud omvat:

• Bugs oplossen wanneer deze ontdekt worden.
• Aanpassen aan updates in pakketafhankelijkheden.
• Het bieden van enige mate van ondersteuning aan gebruikers en bijdragers.
• Indien gewenst, code refactoren of nieuwe functionaliteit toevoegen.

Zonder onderhoudsinspanningen loopt een pakket het risico zijn waarde te verliezen. Toch kan het onderhouden van een pakket gedurende jaren of zelfs decennia een uitdaging zijn, omdat het veel tijd kost. Daarom is het belangrijk dat elke pakketbeheerder een strategie hanteert om de onderhoudsinspanning vol te houden. In deze blogpost deel ik mijn eigen ervaringen met verschillende strategieën die ik zelf heb onderzocht. Voor de leesbaarheid heb ik ze gecategoriseerd in:

• Financiering: Manieren om onderhoudstijd te betalen.
• Gemeenschap: Manieren om anderen te betrekken.
• Omvang: Strategische beslissingen over de aanpak van onderhoudswerkzaamheden.

Voordat ik begin, is het misschien goed om mijn eigen pakketonderhoudservaring kort samen te vatten. Ik heb het R-pakket GGIR gemaakt en onderhoud het sinds 2013. GGIR is een verwerkingspijplijn voor gegevens van draagbare bewegingssensoren die worden gebruikt in slaap- en fysieke activiteitsonderzoek. GGIR is ontworpen voor onderzoekers met doorgaans beperkte tot geen programmeervaardigheden. Als zodanig probeert GGIR het hele proces te automatiseren, van verwerking van ruwe binaire gegevens en kwaliteitsbeoordeling tot het genereren van onderzoeksvriendelijke samenvattingsrapporten. De groeiende vraag naar verbeteringen en ondersteuning voor GGIR in 2019 bracht mij ertoe om mijn eigen bedrijf te starten, Accelting.

Financiering: Manieren om onderhoudstijd te betalen.

Onderzoeksbeurzen

Het verkrijgen van een onderzoeksbeurs kan resulteren in een aanzienlijke hoeveelheid middelen (tijd van mensen) voor een bepaalde periode. Deze optie is het meest realistisch als u een academicus bent. Er zijn misschien niet veel financieringsoproepen gewijd aan onderhoud van onderzoekssoftware, maar het kan mogelijk zijn om wat tijd voor pakketonderhoud in een subsidieaanvraag op te nemen als het een logische stap is om uw onderzoeksdoelen te bereiken. Het aanvragen van onderzoeksbeurzen is niet per se iets dat een niet-academische pakketauteur zou doen, maar ze zouden de academici die het pakket gebruiken kunnen aanmoedigen om rekening te houden met pakketonderhoudstijd in hun subsidieaanvragen. Dat gezegd hebbende, bestaan ​​er enkele softwarebeurzen ^.

Mijn ervaring: Tot nu toe hebben meerdere gebruikers van mijn pakket succesvol onderzoeksbeurzen aangevraagd om verbeteringen van het pakket te betalen. Ik vraag zelf geen beurzen aan omdat ik denk dat het overtuigender is als een pakketgebruiker erom vraagt.

Onderhoud als betaalde service

Pakketbelanghebbenden zijn degenen die profiteren van het voortdurende onderhoud van het pakket. Hieronder vallen:

i. De pakketgebruikers. ii. Degenen die profiteren van het werk dat pakketgebruikers doen, bijvoorbeeld collega’s van de pakketgebruiker of hun supervisor. iii. Uzelf, omdat het goed op uw cv zou kunnen staan ​​als beheerder.

Onderhoud als betaalde service heeft als voordeel dat je als pakketbeheerder aan andere stakeholders duidelijk maakt dat je tijd en expertise niet gratis zijn. Ik zie hier drie varianten op:

1. Als onderdeel van uw reguliere baan met betalingen die rechtstreeks naar uw werkgever gaan in ruil voor de uren die u aan het pakket werkt. Dit vereist dat het werk in lijn is met de missie van de organisatie waarvoor u werkt, wat de reikwijdte van het onderhoudswerk dat u kunt doen, kan beperken.
2. Als bijbaan in de vrije tijd. Enkele tips: zorg ervoor dat je jezelf niet overbelast met contractuele verplichtingen, want zelfs drie uur vrije tijd per week naast een fulltime baan kan al als een last voelen. Let ook op dat niet alle arbeidscontracten vrije tijd consultancy toestaan.
3. Een eigen (fulltime) bedrijf dat zich bezighoudt met het onderhouden van het R-pakket.

Mijn ervaring: Voor optie 1 en 2 had ik geluk dat mijn werkgever destijds (2016-2019) mij faciliteerde om ze te doen. Optie 1 was goed voor mij om een ​​aantal goed gedefinieerde grotere verbeteringen aan te brengen in het pakket dat was gedefinieerd in projecten van 3-6 maanden. Terwijl optie 2, die ik daarna deed, geweldig was voor het doen van projecten die 0-10 dagen tijdsinvesteringen vereisten die te klein waren om interessant te zijn voor mijn werkgever, maar perfect om een ​​aantal problemen op te lossen. De afgelopen vijf jaar heb ik optie 3 gevolgd, wat goed was om beschikbaar te zijn voor zowel kleine als grote projecten. Mijn klanten behoren doorgaans tot groep ii die hierboven is vermeld, omdat ze ofwel een budget hebben of weten hoe ze het kunnen vinden.

Onbetaalde vrijetijdsbestedingen

Onbetaalde vrijetijdsbestedingen kunnen soms een aantrekkelijke optie zijn als u de maker van het pakket was en geen van de andere opties in deze lijst haalbaar of direct beschikbaar voor u zijn. Het werk in uw vrije tijd doen heeft als voordeel dat u het kunt doen wanneer het u uitkomt, zonder tijdsdruk. U kunt zelfs een deel van de vrijetijdsbestedingen zien als een investering in uw persoonlijke vaardigheden. Verder kunnen vrijetijdsbestedingen een effectieve oplossing zijn wanneer de hoeveelheid werk relatief laag is en de verwachte impact hoog. Het nadeel van het werken aan het pakket in uw vrije tijd is dat het andere belanghebbenden de indruk kan geven dat uw tijd en expertise gratis zijn, wat niet het geval is.

Mijn ervaring: Ik doe dit voornamelijk door snelle gebruikersondersteuning te bieden. Het bieden van een bepaald niveau van gratis ondersteuning voelt noodzakelijk om voldoende kansen te genereren voor de andere strategieën in deze lijst. Soms leidt een beetje gratis ondersteuning bijvoorbeeld tot betaalde ondersteuning en soms wordt een gebruiker met vragen een bijdrager. Ik vind het niet leuk om gebruikers te vragen mij te sponsoren via een patron-account of iets dergelijks, zoals ik een paar jaar geleden motiveerde.

Gemeenschap: Manieren om anderen te betrekken.

Gebruikersbasis vergroten

Probeer de gebruikersbasis van uw pakket te vergroten en vergroot daarmee het aantal belanghebbenden dat u mogelijk kan helpen. Bijvoorbeeld door actief reclame te maken voor uw pakket als u dat nog niet eerder hebt gedaan of door de krachten te bundelen met een vergelijkbaar en/of aanvullend pakket, zoals het faciliteren van elkaars dataformaten.

Mijn ervaring: Ik heb prioriteit gegeven aan het functioneel maken van het pakket voor alle soorten data die in ons onderzoeksveld worden gebruikt en het pakket biedt de gebruiker veel parameters om de functionaliteit aan te passen aan hun eigen behoeften. Tot slot heb ik een online trainingscursus gemaakt om nieuwe gebruikers op weg te helpen.

Academische studentenprojecten

Studentenprojecten kunnen helpen bij het beoordelen, testen en verbeteren van een pakket. Studenten verwachten echter actieve coaching en projectdoelen die relevant zijn voor hun diploma.

Mijn ervaring: Eén PhD-student, Jairo Migueles, die het pakket gebruikte in zijn thesisproject (2016-2020) hielp bugs te repareren en de code te verbeteren. Momenteel is er nog een PhD-student, Gaia Segantin, die de uitgebreide, bijna boekachtige narratieve documentatie die we onlangs hebben toegevoegd, proefleest. Hun inspanningen zijn waardevol geweest.

Bouw een ontwikkelaarscommunity

Het laten groeien van een community van code-bijdragers rond uw pakket kan de werklast van individuele bijdragers verminderen. Of dit het voor u gemakkelijker maakt, hangt echter echt af van het type bijdragers en hoe goed ze zijn. Het nadeel van een grotere community is dat er een sterkere behoefte is aan een goede centrale coördinatie om de kwaliteit te waarborgen. Google Season of Code ^{en Google Seizoen van Docs zijn mogelijke wegen.}

Mijn ervaring: Ik heb verschillende bijdragers gehad die aan de code hebben gewerkt of hebben geholpen bij het beantwoorden van vragen van gebruikers. Mijn inspanningen om de community te laten groeien, zijn beperkt tot het hebben van wat documentatie over hoe bij te dragen en proberen om in het algemeen gastvrij te zijn voor bijdragers. Ik weet niet zeker wat ik nog meer kan doen om de community te laten groeien. De meeste van mijn pakketgebruikers zijn zelf geen R-programmeurs, omdat het pakket is ontworpen voor gebruikers met zeer beperkte R-ervaring, wat goed is voor het opbouwen van een brede gebruikerscommunity, maar niet per se voor het opbouwen van een brede ontwikkelaarscommunity. Ik heb Google Season of Code en Google Season of Docs overwogen, maar heb de deadline al twee keer gemist omdat de toepassingsvensters voor organisaties niet duidelijk voor me waren.

Besteed het onderhoudswerk uit

Uitbesteden aan commerciële partijen kan een optie zijn als u zelf geen toegang hebt tot software engineers en geen tijd, maar wel over financiële middelen beschikt en als u duidelijke doelstellingen voor pakketonderhoud hebt gedefinieerd.

Mijn ervaring: Ik heb een aantal onderhoudswerkzaamheden uitbesteed aan andere freelancers, wanneer ik er zelf geen tijd voor had of wanneer ik vond dat mijn vaardigheden op een bepaald gebied onvoldoende waren.

Omvang: Strategische beslissingen over de aanpak van onderhoudswerkzaamheden.

Focus op publicaties

Als u een academicus bent, richt u zich op academische publicaties die over het pakket gaan of die het pakket gebruiken. Hierbij is het doel dat u zich richt op de pakketkwesties die relevant zijn voor uw eigen onderzoek. De kracht van deze aanpak is dat het bewijs genereert voor de waarde van specifieke aspecten van uw pakket of specifieke use cases.

Mijn ervaring: R-pakket GGIR begon op basis van mijn eigen gepubliceerde proefschrift en profiteerde van aanvullende publicaties in latere jaren. Na verloop van tijd leerde ik dat een sterke focus op publicaties het moeilijker maakt om ook mijn programmeervaardigheden te verbeteren en tijd te hebben voor de grotere programmeeruitdagingen. Dus verlegde ik mijn focus naar het aanmoedigen van academische pakketgebruikers om de nodige onderzoekspublicaties te doen.

Volg communitygidsen voor pakketontwikkeling

Het volgen van de rOpenSci-pakketontwikkelingsgids vermindert de inspanning die nodig is om het pakket te onderhouden en maakt het voor buitenstaanders gemakkelijker om bij te dragen. Het spreekt voor zich dat communityrichtlijnen geen tijd (salaris) genereren voor mensen om het onderhoud daadwerkelijk uit te voeren. Daarom is het het beste om communityrichtlijnen te volgen in combinatie met andere opties die in deze blogpost worden genoemd.

Mijn ervaring: Ik begon mijn pakket in 2013 toen ik geen collega’s had die me konden coachen. Door het pakket in te dienen bij CRAN werd ik me bewust van de community-standaarden van die tijd en werd ik me daaraan gehouden. Verder leerde ik over unit-testing en de concepten van schone code in de baan die ik had tussen 2015 en 2019, wat ook hielp om de kwaliteit van het pakket te verbeteren. Ik weet dat het pakket nog steeds niet perfect is, maar ik zie het als een geleidelijk proces waarbij ik elk jaar probeer het pakket een beetje meer te laten voldoen aan de standaarden.

Kosten verlagen

Probeer de hoeveelheid pakketcomponenten die u zelf ontwikkelt en onderhoudt tot een minimum te beperken. Probeer hiervoor zoveel mogelijk te vertrouwen op kant-en-klare oplossingen die door anderen zijn ontwikkeld en onderhouden, hetzij commercieel of open source.

Mijn ervaring: Ik heb een paar slechte ervaringen gehad met afhankelijkheden die verouderd waren, waardoor ik voorzichtiger ben geworden met het toevoegen van afhankelijkheden. Ook vind ik het soms lastig om kant-en-klare oplossingen te vinden voor wat ik nodig heb. Dat gezegd hebbende, als ik een goed onderhouden R-pakket vind dat een functionaliteit biedt die ik nodig heb in een paar regels code die ik niet gemakkelijk zelf kan schrijven in basis-R-code, dan zal ik het beschouwen als een afhankelijkheid in overeenstemming met de richtlijnen van https://r-pkgs.org/dependencies-mindset-background.html.

Doe wat niemand verwacht: stop met onderhoud

Uw onvermoeibare inspanningen om het pakket te onderhouden, kunnen de exacte reden zijn waarom andere belanghebbenden niet ingrijpen. Aankondigen om het onderhoud van het pakket te stoppen, kan belanghebbenden ertoe aanzetten om te helpen een oplossing te vinden. Het stoppen van onderhoud kan in verschillende smaken voorkomen:

1. Volledig permanent pensioen: Niet beschikbaar voor enig werk, behalve voor overdracht aan een nieuwe onderhouder.
2. Gedeeltelijk permanent pensioen: alleen beschikbaar voor essentieel onderhoud.
3. Volledige tijdelijke onderbreking: Niet beschikbaar voor enig werk gedurende X maanden, maar daarna weer terug.
4. Gedeeltelijke tijdelijke onderbreking: Alleen beschikbaar voor essentieel onderhoud gedurende X maanden en terugkeer daarna.

Let op dat deze aanpak misschien wel beter is dan alleen een beheerder in naam zijn zonder tijd te besteden aan het pakket. Door de onderhoudsstatus duidelijk te communiceren aan gebruikers en potentiële bijdragers, vermijdt u valse verwachtingen.

Terzijde: als er een ander R-pakket is met vergelijkbare functionaliteit als het uwe, dan kan het de moeite waard zijn om te overwegen om het onderhoud te stoppen en uw pakket af te schaffen, omdat dit kan helpen om de schaarse onderhoudsinspanningen te kanaliseren naar dit andere pakket.

Mijn ervaring: Op dit moment zou het doen van een van deze dingen in strijd zijn met mijn zakelijke belangen, aangezien onderhoudsverzoeken een potentiële bron van inkomsten voor mij zijn. Als ik echter mijn bedrijf stopzet, zou het stoppen van het onderhoud (geheel, tijdelijk of gedeeltelijk) een strategie kunnen zijn.

Afronden

Ik hoop dat u deze lijst met duurzaamheidsstrategieën nuttig vond, voor uw eigen pakket of om te leren hoe u het pakket van iemand anders kunt ondersteunen. Als u denkt dat ik een optie heb gemist of het niet eens bent met de opties die ik heb genoemd: laat dan uw mening achter in de comments!

Dankbetuigingen

Deze blogpost is gebaseerd op een blogpost die ik in 2017 schreef, maar dan bijgewerkt met mijn ervaringen van de afgelopen 7 jaar en nu toegespitst op de rOpenSci-community.

Verwant