Så här hanterar du ett lyckat InnerSource-program

  • 8 minuter

Här diskuterar vi hur du kan utforma ett InnerSource-program för att få ut det bästa av mönster med öppen källkod inom alla programvaruutvecklingsorganisationer.

Vad är InnerSource?

Vem som helst kan fritt använda, ändra och dela programvara med öppen källkod. Med hjälp av programvara med öppen källkod kan vem som helst visa, ändra och distribuera ett projekt för alla ändamål med tanken att delningskod leder till bättre och mer tillförlitlig programvara.

InnerSource är en metod för att tillämpa mönster med öppen källkod på projekt med en begränsad målgrupp. Ett företag kan till exempel upprätta ett InnerSource-program som speglar strukturen för ett typiskt projekt med öppen källkod, förutom att det endast är tillgängligt för företagets anställda. I själva verket är det ett program med öppen källkod bakom företagets brandvägg.

Fördelar med InnerSource

Ett InnerSource-program kan erbjuda många fördelar utöver vad traditionella modeller med sluten källkod ger.

För det första stöder de intern synlighet. Åtkomsten till källkod i andra företagsprojekt kan göra utvecklarna mer produktiva i sina egna projekt. De kan se hur olika team löser problem som liknar de som de står inför och hittar ofta kod och andra tillgångar som de kan återanvända. Åtkomsten till teamets ärenden, pull-begäranden och projektplaner ger också bättre förståelse för projektets hastighet och riktning.

Dessutom minskar de friktionen. Anta att ett konsumentteam är beroende av en felkorrigering eller en ny funktion för ett projekt som ägs av ett annat team. I ett InnerSource-program har de en kanal genom vilken de kan föreslå de ändringar de behöver. Och om dessa ändringar inte kan sammanfogas i av någon anledning har konsumentteamet möjlighet att förfalska projektet för att uppfylla deras behov.

Slutligen standardiserar de metoder. En vanlig utmaning på organisationer som utvecklar programvara är att olika team ofta utvecklar helt olika sätt att arbeta. Att skapa ett InnerSource-program är ett utmärkt tillfälle att anta standardkonventioner som kan användas i alla utvecklingsteam, även om de inte följer identiska metoder. Två team kanske till exempel föredrar olika processer för att ta emot bidrag. Om sättet att kommunicera de olika processerna är standardiserat blir det mycket enklare för alla att bidra i båda projekten.

Tips/Råd

Överväg att använda GitHub-diskussioner och GitHub Projects för att ytterligare stödja InnerSource-samarbete mellan team.

Det här är bara några exempel på fördelarna med InnerSource-program. Läs mer i En introduktion till InnerSource.

Konfigurera ett InnerSource-program på GitHub

Ange synlighet och behörigheter för lagringsplatsen

Du kan konfigurera GitHub-lagringsplatser med tre synlighetsnivåer. Användare som inte uppfyller synlighetskravet ser sidorna "hittades inte" när de försöker komma åt lagringsplatsen. Här är nivåerna:

  • Offentliga lagringsplatser är synliga för alla. Använd den här synligheten för projekt som verkligen har öppen källkod och som personer både inom och utanför organisationen ska komma åt.
  • Interna lagringsplatser är bara synliga för medlemmar i företaget som äger dem.

Anmärkning

Interna lagringsplatser är endast tillgängliga för GitHub Enterprise-kunder. Använd den här synligheten för InnerSource-projekt.

  • Privata lagringsplatser visas bara för ägaren och eventuella team eller individer ägaren lägger till. Använd den här synligheten för projekt som endast specifika användare och grupper ska ha åtkomst till.

När du har upprättat synligheten för lagringsplatsen kan du konfigurera behörigheter för enskilda användare eller team. Det finns fem behörighetsnivåer:

  • Läsnivå rekommenderas för icke-kodande deltagare som vill visa eller diskutera projektet.
  • Nivån Prioritera rekommenderas för deltagare som behöver hantera ärenden och pull-begäranden proaktivt utan skrivåtkomst.
  • Nivån Skriva rekommenderas för deltagare som aktivt push-överför kod till projektet.
  • Nivån Underhålla rekommenderas för projektledare som behöver hantera lagringsplatsen utan åtkomst till känsliga eller destruktiva åtgärder.
  • Nivån Admin rekommenderas för personer som behöver fullständig åtkomst till projektet, inklusive känsliga och destruktiva åtgärder som att hantera säkerhet eller att ta bort en lagringsplats.

Läs mer om åtkomstbehörigheter för lagringsplatsen efter nivå.

Skapa lagringsplatser som är enkla att identifiera

När ett InnerSource-program växer skalas sannolikt antalet lagringsplatser upp avsevärt. Även om det är bra att alla de här resurserna är tillgängliga för organisationen kan det bli svårt att hitta innehåll effektivt. För att proaktivt åtgärda det här problemet är det bästa praxis för team att överväga vad de kan göra för att göra det enklare för andra att hitta och arbeta med sina lagringsplatser.

Här är några beprövade metoder:

  • Använd ett beskrivande namn på lagringsplatsen, som warehouse-api eller supply-chain-web.
  • Ta med en kort beskrivning. En mening eller två bör vara tillräckligt för potentiella användare ska veta om projektet kanske passar deras behov.
  • Licensiera lagringsplatsen så att kunderna vet hur de kan använda, ändra och distribuera programvaran.
  • Inkludera en README.md fil i lagringsplatsen. GitHub använder den här filen som landningssida när personer besöker lagringsplatsen.

Lägga till en README-fil

En README-fil förmedlar förväntningar på projektet och hjälper dig att hantera bidrag. README-filer kan:

  • Berätta om projektets syfte och vision så att potentiella användare förstår om det passar deras behov.
  • Tillhandahåll visuella ledtrådar, som skärmdumpar eller kodexempel, som visar projektet i praktiken.
  • Inkludera länkar till en produktions- eller demoversion av appen för granskning.
  • Berätta om förutsättningar och distributionsprocedurer.
  • Inkludera referenser till de projekt som du är beroende av. Dessa referenser är ett bra sätt att främja andras arbete.
  • Använd Markdown för att vägleda läsarna genom korrekt formaterat innehåll.

Om du placerar din README.md-fil i lagringsplatsens rotkatalog, eller i den dolda .github katalogen eller docs katalogen, identifierar och lägger GitHub automatiskt upp README för besökare på lagringsplatsen. Om en lagringsplats innehåller mer än en README-fil väljs den fil som visas från platser i följande ordning:

  1. Katalogen .github
  2. Lagringsplatsens rotkatalog
  3. Katalogen docs

Kolla in några Utmärkta README-exempel.

När projektet har lanserats använder du e-post och andra nätverkskanaler för att marknadsföra det. Genom att nå ut till en lämplig målgrupp kan du få betydligt fler deltagare i projektet.

Läs mer om README-filer i GitHub-dokumentationen.

Hantera projekt på GitHub

När projekten får fäste kan tillströmningen av användare och bidrag kräva mycket arbete att hantera. Beroende på projektet kan en betydande mängd arbete krävas bara för att hantera projektdeltagarnas förväntningar.

För att proaktivt åtgärda det här problemet letar GitHub efter en CONTRIBUTING.md fil i roten (eller /docs/.github ) på en lagringsplats. Använd den här filen till att förklara hur bidrag hanteras i projektet. Den exakta informationen kan variera, men det är en bra idé att låta potentiella deltagare veta vilka konventioner projektet följer. Till exempel var teamet letar efter pull-begäranden, vilken information som begärs för felrapporter och så vidare.

Om det finns en CONTRIBUTING.md sådan visar GitHub en länk till den när användare skapar problem eller pull-begäranden för att uppmuntra dem att följa den.

Länkar till riktlinjer för bidrag.

Kolla in några Utmärkta CONTRIBUTING.md-exempel

Överväg också att lägga till en CODEOWNERS-fil på lagringsplatsen för att definiera individer eller team som ansvarar för att granska kodändringar.

Skapa mallar för problem och pull-begäranden

GitHub har stöd för startmallar för nya ärenden och pull-begäranden. Använd dessa mallar för att ange den inledande beskrivningstexten för ett nyligen skapat problem eller en pull-begäran.

Om ditt projekt till exempel har .github/ISSUE_TEMPLATE.md, när en användare startar processen för att skapa ett problem, ser de det här innehållet. I stället för att ständigt behöva referera till nödvändig information från en CONTRIBUTING.mdkan de bara fylla i problemet som ett formulär med hjälp av malltexten.

Ett nytt problem med mallen.

Samma sak gäller för pull-begäranden, förutom att sökvägen är .github/PULL_REQUEST_TEMPLATE.md.

Kolla in några Utmärkta GitHub-mallar för ärenden och pull-begäranden.

Definiera arbetsflöden

För projekt som uppmuntrar till externa bidrag ska du se till att ange vilket arbetsflöde projektet följer. Arbetsflödet bör innehålla information om var och hur grenar ska användas för buggar och funktioner. Den bör också innehålla hur pull-begäranden ska öppnas och all annan information som personer utanför lagringsplatsens team bör känna till innan de skickar kod. Om du inte har något arbetsflöde i åtanke än bör du överväga att använda GitHub-flödet.

Du bör presentera en strategi för hur versioner och distributioner ska hanteras. Dessa delar av arbetsflödet påverkar daglig förgrening och sammanslagning, så det är viktigt att kommunicera dem till deltagare. Läs mer om hur de relaterar till din förgreningsstrategi på Git.

Mäta programmets resultat

Alla team som börjar använda InnerSource bör tänka på vilka typer av mått de vill spåra för att mäta programmets resultat. Även om traditionella mått som ”lanseringstid” eller ”rapporterade buggar” fortfarande går att använda så kanske de inte visar på fördelarna med att använda InnerSource.

Överväg i stället att lägga till mått som visar hur externt deltagande förbättrade projektkvaliteten. Tar lagringsplatsen emot pull-begäranden från externa källor som åtgärdar buggar och lägger till funktioner? Finns det aktiva deltagare i diskussioner kring projektet och dess framtid? Inspirerar programmet till en utökning av InnerSource som kan ge fördelar i andra delar av organisationen?

Kort och gott är måtten svåra, särskilt när det gäller att mäta värdet och effekten av enskilda bidrag och teambidrag. När mått används på fel sätt kan det skada kulturen, befintliga processer och förvärra synen på organisationen eller ledningen. När du funderar på att mäta InnerSource-implementering bör du överväga följande vägledning om mått:

  • Mät process, inte utdata
    • Omsättningstid för kodgranskning
    • Storleken på pull-begäranden
    • Pågående arbete
    • Tid för att öppna
  • Mät mot mål och inte absoluta tal
  • Mäta team och inte individer
    • Antal unika deltagare i ett projekt
    • Antal projekt som återanvänder kod
    • Antal @mentions mellan team

Lär dig mer om de framgångar som andra har haft i dessa InnerSource-fallstudier.