Inner Source, vaak gestileerd als InnerSource, verwijst naar de acceptatie van open source-processen en ontwikkelingsmethodologieën binnen een organisatie. Overwegende dat “open source” impliceert het creëren van openbaar beschikbare tools, inner source betekent dat je aan interne projecten werkt met behulp van open-afgeleide benaderingen.
Open source workflows vergemakkelijken een gemakkelijke samenwerking en snelle iteratie. Met openbaar toegankelijke problemen en samenvoegverzoeken op platforms zoals GitHub kan iedereen bijdragen aan een project. Bugs worden snel, veilig en transparant ontdekt en gepatcht in een omgeving die regelmatig overleg tussen beheerders en gebruikers bevordert.
Dit model staat in schril contrast met de ontwikkeling van software binnen grote organisaties. In deze omgevingen worden tools ad-hoc ontwikkeld door individuele teams. Mensen werken in silo's, dragen bij aan hun individuele gebieden, zich niet bewust van overlappend werk dat elders plaatsvindt.
Introductie van Inner Source
De inner source-beweging past de lessen die zijn geleerd uit open source-ontwikkeling toe op de interne projecten van een organisatie. Het pleit ervoor om alle code voor iedereen zichtbaar te maken, een meer open cultuur te creëren waarin teams bestaande projecten kunnen vinden die ook nuttig kunnen zijn voor hun werk, en vervolgens hun eigen verbeteringen kunnen bijdragen.
In veel organisaties zullen nieuwe bronbronnen worden opgeslagen. worden opgesloten voor alleen de personen die eraan moeten werken. Het aannemen van een inner source-model betekent dat je standaard alles zichtbaar maakt. Dit moedigt teamleden aan om het hele codecorpus van de organisatie te verkennen en input te leveren voor discussies, zelfs als het project niet strikt binnen hun vakgebied valt.
Advertentie
Inner source gaat ook niet alleen over code. Het kan worden uitgebreid met bredere activa en documentatie die relevant zijn voor het bedrijf, de activiteiten en de software. Het doel is om individuen in staat te stellen zelf taken te selecteren en hun ervaring in te brengen waar ze denken dat het de organisatie ten goede zou komen, zelfs als ze worden ingehuurd in een specifiek aandachtsgebied.
Innerlijke Bron Voordelen
Voorstanders van “inner source” architecturen merken verschillende belangrijke voordelen van de aanpak op, waaronder minder verspilling, snellere lanceringstijden, minder spanning tussen teams en verbeterde codekwaliteit. Deze combineren om de productiviteit van de organisatie en de cultuur op de werkplek te verbeteren.
- Minder afval, verbeterd hergebruik– Grote organisaties kunnen uiteindelijk dezelfde code dupliceren in meerdere projecten die eigendom zijn van verschillende teams. Als teams niet met elkaar praten, kan het feit dat je nu drie vergelijkbare cachebibliotheken hebt onopgemerkt blijven. Door alle code intern te publiceren, worden anderen gewaarschuwd voor de aanwezigheid van gebruikelijke tools en wordt gedeelde iteratie op een enkele codebase aangemoedigd. Het wiel wordt niet meer opnieuw uitgevonden, houdt iedereen bij de les en versnelt de lanceringstijd.
- Verbeterde codekwaliteit– Code die in het openbaar is geschreven, is meer zichtbaar, dus bugs zullen waarschijnlijk eerder in het ontwikkelingsproces verschijnen. Als een gedeelde bibliotheek wordt overgenomen door een nieuw team, kunnen er problemen aan het licht komen die voorheen onopgemerkt waren. Het implementeren van fixes is gunstig voor alle projecten die de bibliotheek gebruiken.
- Minder spanning tussen teams– Hoewel de overstap naar een open model op het eerste gezicht misschien ongemakkelijk lijkt, is de ontwikkeling van innerlijke bronnen bedoeld om barrières te slechten en de samenwerking te verbeteren. Gesloten ontwikkeling kan ongemakkelijke situaties creëren wanneer je merkt dat een naburig team een betere versie heeft gebouwd van een bibliotheek die je hebt gebruikt. In een open model wordt dit opgelost door samen te itereren op een gedeelde codebase die de mogelijkheden bevat die nodig zijn voor de hele groep.
Inner source vlakt de organisatiestructuur af, waardoor alle ontwikkelaars hetzelfde inzicht krijgen in doorgaand werk. Het accepteren van bijdragen van buiten het team dat "bezit" een project biedt toegang tot frisse ogen en een uitgebreide pool van oplossingen.
Implementatie van een Inner Source Workflow
Op zijn eenvoudigst wordt innerlijke bron geïmplementeerd door naar uw versiebeheerplatform te gaan en de zichtbaarheid van projecten te wijzigen van privé naar intern. In de praktijk zul je een meer doordacht plan nodig hebben dan dit als je het innerlijke bronmodel met succes wilt introduceren in een bestaande teamomgeving.
Er zijn twee fundamentele aspecten bij elke transitie: communicatie en hulpmiddelen. De eerste verwijst naar het opleiden van teamleden over wat er gebeurt en hoe ze kunnen bijdragen aan geopende projecten. “Instellen en vergeten” toegangsniveaus zullen niet effectief zijn omdat mensen niet op de hoogte zijn van hun nieuwe vaardigheden en wanneer ze kunnen worden gebruikt.
Het tweede aspect, tools, omvat het selecteren van geschikte softwarehulpprogramma's om de open workflow te beheren. Een werkend softwareteam zal waarschijnlijk al een vorm van versiebeheer, zoals GitOps, gebruiken om hun code te beheren. Precieze gebruikspatronen kunnen echter binnen de organisatie aanzienlijk verschillen.
Advertentie
Inner Source doet een beroep op een uniform ontwikkelingsmodel dat consistent zal werken in alle projecten. Dit betekent dat u de mogelijkheden van Git en uw hostingplatform, zoals GitHub of GitLab, optimaal benut.
Bijdragers moeten in staat zijn om wijzigingen in een pull-verzoek in te dienen, die de beheerders vervolgens beoordelen en samenvoegen. Pull-aanvragen moeten worden aangevuld met een geslaagde testsuite die in een CI-pijplijn wordt uitgevoerd. Dit geeft het behoudende team het vertrouwen dat de verandering effectief is en zorgt ervoor dat alle code aan dezelfde normen voldoet. Door de codebase zelfverifiërend te maken door middel van geautomatiseerde tests en controles, wordt wrijving uit de ervaring weggenomen.
U moet ook overwegen hoe ondersteunende activa zoals documentatie en probleemlijsten worden opgeslagen en weergegeven. Maak een open teamwiki voor API-documenten en architectuurreferenties; zorg ervoor dat alle bugs en functieverzoeken op een centrale locatie worden bijgehouden. Hierdoor kunnen mensen uit de hele organisatie de informatie vinden die ze nodig hebben. Het stelt individuen ook in staat om willekeurige projecten in rustigere periodes te verbeteren – iedereen kan bugrapporten vinden en beginnen met het aanpakken ervan, wat leidt tot verbeteringen in alle downstream-opslagplaatsen.
Te overwegen nadelen
Innerlijke bron is al een realiteit bij veel organisaties. De potentiële voordelen zijn aantrekkelijk in situaties waar verhoogde efficiëntie en doorvoer gewenst zijn. Zoals met elke manier van werken, is het echter niet per se geschikt voor elke omgeving.
Een van de meest voorkomende zorgen over de innerlijke bron is de impact ervan op de beveiliging en het vrijgeven van informatie. De overeenkomsten tussen de innerlijke bron en het bredere open-source-ecosysteem strekken zich slechts zover uit: de code in een open bibliotheek of raamwerk bevat niets van gevoeligheid, terwijl u in uw rol op het werk te maken kunt hebben met streng bewaakte propriëtaire systemen.
Het is normaal dat sommige projecten altijd moeten worden vergrendeld, alleen toegankelijk voor belanghebbenden en het direct verantwoordelijke implementatieteam. Het bezitten van enkele projecten met een hoge inzet met een gevoelige bron, waar het niet veilig is om ze zichtbaar te maken in de hele organisatie, zou echter niet het einde moeten betekenen van een innerlijk broninitiatief.
Advertentie
Het is nog steeds de moeite waard om projecten te openen die veilig kunnen worden blootgelegd. U kunt ook de niet-gevoelige delen van privéprojecten abstraheren in nieuwe gedeelde bibliotheken die openbaar toegankelijk zijn. Dit brengt de voordelen van innerlijke bron dichter bij uw gevoelige activa zonder ze daadwerkelijk te onthullen.
Een andere uitdaging van innerlijke bron is het communiceren van verwachtingen aan ontwikkelaars. Ontwikkelaars kunnen op hun hoede zijn bij het verkennen van open projecten, vooral als de innerlijke bron wordt geïntroduceerd in een historisch gesloten organisatie. Dit kan op verschillende manieren worden aangepakt, zoals tijd vrijmaken voor ontwikkelaars om code te inspecteren die door andere teams is geschreven.
Het kan ook handig zijn om klein te beginnen en alleen kernbibliotheken bloot te leggen die nuttig zijn voor veel verschillende teams in de organisatie. Een goede keuze kan een bekende maar privécomponent zijn die de reputatie heeft onbetrouwbaar of verouderd te zijn – denk “foutmelding opnieuw met de ApiClient.” Door dat onderdeel te openen, kunnen ontwikkelaars hun eigen oplossingen bijdragen wanneer ze die nodig hebben, waardoor de productiviteit wordt verbeterd en de organische groei van de innerlijke bronmentaliteit wordt bevorderd.
Als je deze techniek toch probeert, wees dan voorzichtig om eerst de oorspronkelijke projectauteurs te waarschuwen – zelfs als het leidt tot een grotere efficiëntie in het algemeen, zouden sommige individuen anderen kunnen behandelen die bijdragen aan code die voorheen "hun" was" als een belediging. Communiceer waarom innerlijke bron wordt geïntroduceerd in de organisatie, evenals de specifieke redenen voor het openen van individuele projecten.
Conclusie
Inner source verwijst naar het nemen van ontwikkelmethoden uit de open source-gemeenschap en deze toepassen op interne projecten en processen. Het faciliteert onbelemmerde toegang tot nuttige code en documentatie terwijl het samenwerking en communicatie bevordert.
Op de juiste manier geïmplementeerd, kan inner source een onderscheidend punt zijn voor een organisatie die redundantie vermindert, de doorvoer verhoogt en een meer rechtvaardige ontwikkelingscultuur bevordert. Door ervoor te kiezen om projecten standaard open te laten, kunnen de oorspronkelijke auteurs gebruikmaken van het menselijke talent van de hele organisatie. Op dezelfde manier als toonaangevende open source frameworks en bibliotheken de collectieve capaciteiten van de gemeenschap oogsten, zo kan inner source interne tools creëren die verder gaan dan wat een enkel team zou kunnen bereiken.
Advertentie
Inner source kan dat wel lastig zijn om gelijk te krijgen. Het kan leiden tot pushback van code-eigenaren en behoedzaamheid van ontwikkelaars. Houd bij het introduceren van enige vorm van innerlijke bronontwikkeling mensen op dezelfde lijn door verwachtingen en werkprocedures duidelijk te documenteren. Iedereen moet zich op zijn gemak voelen bij het bijdragen om de volledige voordelen van innerlijke bron duidelijk te maken.