Så här etablerar du ett program med öppen källkod

Slutförd

Här går vi igenom några viktiga saker att tänka på när du etablerar ett program med öppen källkod.

Vad menar vi med "öppen källkod?".

Ett program med öppen källkod är mer än offentlig åtkomst till en kodbas. Det handlar om att öppna ett levande projekt där alla som vill delta kan göra det. När det körs korrekt för ett lämpligt projekt kan ett program med öppen källkod bidra till betydande förbättringar av produktens kvalitet.

En av de viktigaste orsakerna till att företag driver projekt med öppen källkod är att de vill engagera communityn. Populära projekt får betydande bidrag från communityn, och de får dem gratis.

Det handlar inte nödvändigtvis om altruism. Människor och organisationer använder projekt eftersom de ser en personlig eller affärsförmån. När projektet inte uppfyller deras behov eller förväntningar kan de använda möjligheten att åtgärda buggar eller lägga till funktioner. I stället för att hålla tillbaka dessa förbättringar i privata förgreningar är de tvungna att bidra med dessa ändringar tillbaka till källlagringsplatsen för att bli en del av projektbaslinjen. Den här goda förbättringscykeln är anledningen till att många företag producerar programvara med hjälp av modellen med öppen källkod.

Målen inom öppen källkod

Som en sammanfattning så finns det tre dimensioner för deltagande i program med öppen källkod:

• Konsumenter som studerar eller använder andras lagringsplatser.
• Deltagare som aktivt deltar i förbättringen av andras lagringsplatser.
• Producenter som skapar och underhåller sina egna lagringsplatser som är öppna för andra.

När en organisation funderar mer på vad de vill få ut av de olika dimensionerna är det en idé att ta en titt på var organisationen befinner sig i dag. Det finns fem processnivåer inom varje dimension.

• Ad hoc, som inte har någon process på plats. Framgången är beroende av individers enskilda arbete.
• Hanterat, med en delvis dokumenterad process. Framgången är beroende av disciplin.
• Definierad, som har en dokumenterad, standardiserad och integrerad process. Framgången är beroende av automatisering.
• Mätningar, som har en process som hanteras kvantitativt. Framgången är beroende av mätvärden som jämförs med affärsmål.
• Optimerad, som har en process som kontinuerligt och tillförlitligt förbättras genom både inkrementella och innovativa förändringar. Framgången är beroende av att minska risken för ändringar.

Om du vill få en bättre förståelse för var din organisation står kan du titta på självutvärderingar med öppen källkod.

Vad ska jag använda öppen källkod för?

Många projekt är inte avsedda för storhet med öppen källkod. Dina kriterier kan variera beroende på företagets mål och processnivå, men här är några rekommenderade kriterier att tänka på innan du öppnar ett projekt:

• Innehåller projektet immateriell egendom som du vill skydda? I så fall skulle det en öppen källkod innebära att den avslöjas. Använd inte öppen källkod för den här typen av projekt om du inte känner att fördelarna överväger riskerna.

• Är projektet i ett stabilt tillstånd med bra kod kvalitet? Projektet behöver inte vara perfekt, men potentiella deltagare kan gå därifrån om projektet är i dåligt skick till att börja med.

• Är projekt användbart för personer utanför företaget? Om inte, får du förmodligen inte något deltagande.

• Kan personer utanför företaget bidra? De behöver åtkomst till alla projektberoenden, byggprocesser och allt annat som behövs för att köra projektet. Om de inte kan köra den kan de inte bidra.

• Har ditt team bandbredden som krävs för ett program med öppen källkod? Annars väntar du tills du gör det. Om du har öppen källkod för ett projekt och inte stöder det kan du förlora din möjlighet att skapa en betrodd community.

Det här är bara några exempel på frågor att överväga. Din organisation kan ha andra affärs- eller efterlevnadsproblem att tänka på.

Utforma ett program med öppen källkod

Att driva ett program med öppen källkod liknar att driva ett InnerSource-program, men för en offentlig publik. Därför finns det några fler överväganden.

Hantera communityns förväntningar

Filer som README.md och CONTRIBUTING.md är ännu viktigare eftersom de exponeras för personer som inte har din organisationskontext. De måste utvärderas utifrån någon utanför företaget för att säkerställa klarhet.

Dessutom är din uppförandekod en viktig princip att uttrycka. Standarden är att lägga till en CODE_OF_CONDUCT.md fil i lagringsplatsens rot och använda den för att förklara det beteende som förväntas av deltagarna i din community. Flera grupper i din organisation bör granska det här dokumentet, inklusive ditt juridiska team. Som tur är finns det många standardregler att börja med. Många projekt använder de här koderna som de är. Läs mer i guiden för uppförandekoder med öppen källkod.

Förbereda medarbetare för att underhålla en lagringsplats

Anställda kanske inte har erfarenhet av att arbeta med communityn med öppen källkod. För att hjälpa dem att förbereda sig rekommenderar vi att företaget erbjuder en uppsättning guider som täcker de viktigaste sakerna som alla bör känna till innan de kommer igång. Dessa guider bör publiceras på en intern lagringsplats eller portal som regelbundet underhålls och endast är tillgänglig för företagets anställda. Följande guider är några av de viktigaste:

• En "Ska vi göra det här projektet till öppen källkod?"-guide som tillhandahåller ett ramverk för att avgöra om ett kandidatprojekt ska göras till öppen källkod eller inte. Den här guiden kan struktureras som ett flödesschema, en uppsättning frågor eller en lista med saker att tänka på.

• En checklista för installation som innehåller alla arbetsobjekt som ett team måste slutföra före och efter starten av ett projekt med öppen källkod. Den här listan bör omfatta att förvärva godkännande för projektet med öppen källkod, kodgranskningar för att säkerställa att känsliga data tas bort innan projektet går live, ett varumärke eller projektsökning med öppen källkod för att säkerställa att det inte finns någon namnkonflikt och så vidare.

• En kontaktlista för nyckelpersoner i din organisation som kan behöva kontaktas om direkt stöd från de ansvariga krävs. Listan bör innehålla personer från IT-säkerheten, anläggningssäkerheten, juridiska teamet, PR och så vidare.

• En länk till en startlagringsplats som kan klonas som utgångspunkt. Den bör innehålla ett README-exempel, licens, förhållningsregler, bidragsguide och andra hjälpfiler som alla företagets projekt med öppen källkod måste ha. Den ska inte innehålla något du inte vill ska skickas ut offentligt av misstag.

• En underhållsguide som förklarar det ansvar som en underhållare har för att hålla lagringsplatsen felfri. Dessa ansvarsområden omfattar att hålla lagringsplatsens dokumentation uppdaterad, se till att problem och pull-begäranden uppmärksammas av rätt personer i tid och så vidare.

• En kommunikationsguide som ger vägledning till förvaltare av lagringsplatser för några av de ämnen som du föredrar att inte ta med i offentliga filer som README.md, CONTRIBUTING.md eller CODE_OF_CONDUCT.md. Dessa ämnen kan vara känsliga affärsämnen, till exempel att inte diskutera konkurrenter. eller mer allmänna beteendeämnen, till exempel hur du korrekt känner igen de främsta bidragsgivarna.

• En intern faq som ger godkända svar på vanliga frågor. Den här listan är särskilt användbar om det finns juridiska subtiliteter i de ämnen som ditt företag kan diskutera under underhåll av ett program med öppen källkod.

• En licensprincip som listar vilka licenser som har godkänts eller avvisats av den juridiska avdelningen för användning eller bidrag med öppen källkod.