Inner Source, ofta stiliserad som InnerSource, hänvisar till antagandet av processer med öppen källkod och utvecklingsmetoder inom en organisation. Medan “öppen källkod” innebär skapandet av allmänt tillgängliga verktyg, inre källkod innebär att du arbetar med interna projekt med öppna metoder.
Arbetsflöden med öppen källkod underlättar enkelt samarbete och snabb iteration. Allmänt tillgängliga frågor och sammanslagningsförfrågningar på plattformar som GitHub låter vem som helst bidra till ett projekt. Buggar upptäcks och korrigeras snabbt, säkert och transparent i en miljö som främjar regelbunden diskussion mellan underhållare och användare.
Denna modell kan stå i skarp kontrast till hur mjukvara utvecklades inom stora organisationer. I dessa miljöer utvecklas verktyg på ett ad hoc-sätt av individuella team. Människor arbetar i silos, bidrar till sina individuella områden, omedvetna om överlappande arbete som pågår någon annanstans.
Introducing Inre Source
Den inre källrörelsen tillämpar lärdomar från utveckling av öppen källkod till en organisations interna projekt. Den förespråkar att göra all kod synlig för alla, skapa en mer öppen kultur där team kan hitta befintliga projekt som också kan vara användbara för deras arbete, och sedan bidra med sina egna förbättringar.
I många organisationer kommer nya källförråd vara låsta till just de individer som behöver arbeta med dem. Att anta en inre källmodell innebär att göra allt synligt som standard. Detta uppmuntrar teammedlemmar att utforska hela organisationens kodkorpus och ge input till diskussioner, även om projektet inte strikt ligger inom deras ämnesområde.
Annons
Inre källa handlar inte bara om kod heller. Det kan utökas till att omfatta bredare tillgångar och dokumentation som är relevant för verksamheten, dess verksamhet och dess programvara. Målet är att ge individer möjlighet att själv välja uppgifter och bidra med sina erfarenheter där de känner att det skulle gynna organisationen, även om de anställs inom ett specifikt fokusområde.
Inner Source Benefits
Förespråkare av “inre källa” arkitekturer noterar flera betydande fördelar med metoden, inklusive minskat slöseri, snabbare lanseringstider, mindre spänningar mellan team och förbättrad kodkvalitet. Dessa kombineras för att förbättra organisationens produktivitet och arbetsplatskultur.
- Minskat avfall, förbättrad återanvändning– Stora organisationer kan sluta med att duplicera liknande kod över flera projekt som ägs av olika team. Om team inte pratar med varandra kan det faktum att du nu har tre liknande cachningsbibliotek gå obemärkt förbi. Publicering av all kod internt kommer att uppmärksamma andra på förekomsten av vanliga verktyg och uppmuntra sedan delad iteration på en enda kodbas. Hjulet slutar uppfinnas på nytt, håller alla igång och påskyndar lanseringens tidsram.
- Förbättrad kodkvalitet– Kod skriven i det öppna är mer exponerad så buggar kommer sannolikt att dyka upp tidigare i utvecklingsprocessen. Om ett delat bibliotek antas av ett nytt team kan problem dyka upp som inte märkts tidigare. Att implementera korrigeringar kommer att gynna alla projekt som använder biblioteket.
- Mindre spänningar mellan team– Även om övergången till en öppen modell kan verka obekvämt till en början, är inre källutveckling tänkt att bryta ner barriärer och förbättra samarbetet. Sluten utveckling kan skapa oroliga situationer när du hittar ett angränsande lag som har byggt en bättre version av ett bibliotek du har använt. I en öppen modell löses detta genom att iterera tillsammans på en delad kodbas som inkluderar de möjligheter som behövs för hela gruppen.
Inre källa plattar ut organisationsstrukturen, vilket ger alla utvecklare samma syn på pågående arbete. Acceptera bidrag från utanför teamet som “äger” ett projekt ger tillgång till nya ögon och en utökad pool av lösningar.
Implementera ett arbetsflöde för inre källor
Som enklast implementeras den inre källan genom att gå till din versionskontrollplattform och ändra synligheten för projekt från Privat till Intern. I praktiken kommer du att behöva en mer genomtänkt plan än så här om du framgångsrikt ska introducera den inre källmodellen till en befintlig teammiljö.
Det finns två grundläggande aspekter i varje övergång: kommunikation och verktyg. Den förstnämnda syftar på att utbilda teammedlemmar om vad som händer och hur de kommer att kunna bidra till öppnade projekt. “Ställa in och glömma” åtkomstnivåer kommer att vara ineffektiva eftersom människor kommer att vara omedvetna om sina nya förmågor och när de kan användas.
Den andra aspekten, verktyg, handlar om att välja lämpliga programvaruverktyg för att hantera det öppna arbetsflödet. Ett fungerande mjukvaruteam kommer förmodligen redan att använda en form av versionskontroll, som GitOps, för att hantera sin kod. Exakta användningsmönster kan dock variera avsevärt inom organisationen.
Annons
Inre source kräver en enhetlig utvecklingsmodell som kommer att fungera konsekvent i alla projekt. Detta innebär att du använder funktionerna hos Git och din värdplattform, som GitHub eller GitLab, till fullo.
Bidragsgivare bör kunna skicka in ändringar i en pull-begäran som underhållare sedan granskar och slår samman. Pull-förfrågningar bör kompletteras med en godkänd testsvit som körs i en CI-pipeline. Detta ger det underhållande teamet förtroende för att förändringen är effektiv och säkerställer att all kod uppfyller samma standarder. Att göra kodbasen självverifierande genom automatiska tester och kontroller hjälper till att ta bort friktion från upplevelsen.
Du bör också överväga hur stödtillgångar som dokumentation och ärendelistor lagras och exponeras. Skapa en öppen teamwiki för API-dokument och arkitekturreferenser; se till att alla buggar och funktionsförfrågningar spåras på en central plats. Detta kommer att låta människor från hela organisationen hitta den information de behöver. Det ger också individer möjlighet att tillhandahålla förbättringar av godtyckliga projekt i lugnare perioder – vem som helst kan hitta felrapporter och börja åtgärda dem, vilket leder till förbättringar i alla nedströmsförråd.
Nackdelar att överväga
Inre källa är redan en realitet hos många organisationer. De potentiella fördelarna är lockande i situationer där ökad effektivitet och genomströmning önskas. Som med alla metoder för arbete, är det inte nödvändigtvis lämpligt för alla miljöer.
En av de vanligaste farhågorna om inre källa är dess inverkan på säkerhet och informationsutlämnande. Likheterna mellan den inre källkoden och det bredare ekosystemet med öppen källkod sträcker sig bara så långt: koden i ett öppet bibliotek eller ramverk innehåller ingenting av känslighet, medan du kan hantera noggrant skyddade proprietära system i din roll på jobbet.
Det är naturligt att vissa projekt alltid kommer att behöva vara låsta, endast tillgängliga för intressenter och det direkt ansvariga implementeringsteamet. Att ha några projekt med hög insats med känslig källa, där det inte är säkert att göra dem synliga i hela organisationen, borde dock inte betyda slutet på ett initiativ från den inre källan.
Annons
Det är fortfarande värt att öppna upp projekt som säkert kan exponeras. Du kan också abstrahera de okänsliga delarna av privata projekt till nya delade bibliotek som är offentligt tillgängliga. Detta bringar fördelarna med inre källa närmare dina känsliga tillgångar utan att faktiskt avslöja dem.
En annan utmaning för inre källa är att kommunicera förväntningar tillbaka till utvecklarna. Utvecklare kan vara försiktiga med att utforska öppna projekt, särskilt om inre källa introduceras till en historiskt stängd organisation. Detta kan åtgärdas på en mängd olika sätt, som att tilldela tid för utvecklare att inspektera kod skriven av andra team.
Det kan också vara bra att börja i liten skala och bara exponera kärnbibliotek som kommer att vara användbara för många olika team i hela organisationen. Ett bra val kan vara en välkänd men privat komponent som har rykte om sig att vara opålitlig eller föråldrad – tänk “rapporterade fel med ApiClient igen.” Genom att öppna upp den komponenten kan utvecklare bidra med sina egna korrigeringar när de behöver dem, vilket förbättrar produktiviteten och främjar organisk tillväxt av den inre källmentaliteten.
Om du försöker den här tekniken, var noga med att varna de ursprungliga projektförfattarna först – även om det leder till större effektivitet överallt, kan vissa individer behandla andra som bidrar till kod som tidigare var “deras” som en kränkning. Kommunicera varför inre källa introduceras till organisationen, samt de specifika anledningarna till att öppna enskilda projekt.
Slutsats
Inre källa avser att ta utvecklingsmetoder från open source-gemenskapen och tillämpa dem på interna projekt och processer. Det underlättar obehindrad tillgång till användbar kod och dokumentation samtidigt som det främjar samarbete och kommunikation.
Rätt implementerad kan inre källa vara en särskiljande punkt för en organisation som minskar redundans, ökar genomströmningen och främjar en mer rättvis utvecklingskultur. Om du väljer att lämna projekt öppna som standard låter de ursprungliga författarna utnyttja hela organisationens mänskliga talang. På samma sätt som ledande ramverk och bibliotek med öppen källkod skördar gemenskapens kollektiva förmågor, så kan inre källkod skapa interna verktyg som går utöver vad ett enskilt team skulle kunna uppnå.
Annons
Inre källa kan vara knepigt att få rätt. Det kan leda till pushback från kodägare och försiktighet från utvecklarnas sida. När du inför någon form av inre källutveckling, håll människor på samma sida genom att tydligt dokumentera förväntningar och arbetsrutiner. Alla måste känna sig bekväma med att bidra för att de fulla fördelarna med inre källa ska bli uppenbara.