Hvorfor open source kan trumfe indre kilde til internt samarbejde

Microsofts administrerende direktør Satya Nadella (centrum på foto)

Billede: James Martin / CNET

Microsoft går i gang med "indre kilde" og forsøger at anvende open source-principper på intern engineering. Hvis du synes, det lyder baglæns, i betragtning af at Microsoft sandsynligvis allerede er verdens største open source-bidragyder (som målt ved, at de samlede medarbejdere aktivt bidrager til GitHub), har du helt klart ikke arbejdet for et stort firma, der forsøger at nedbryde interne barrierer for samarbejde.

Som nogle virksomheder finder, kan open source med fuld fedt faktisk være den lettere måde at opnå internt samarbejde på.

Hvorfor åbne inde?

Hvis du har arbejdet for en stor virksomhed, ved du, hvor vanskeligt internt samarbejde kan være. Bare fordi to ingeniørhold deler den samme firewall, betyder det ikke, at de åbner kodeopbevaringssteder for hinanden. Det betyder heller ikke, at de investerer tiden i dokumentation for at gøre det let at forbruge deres kode, selvom adgang til lageret er åbent. Det eneste, ingeniører inden for den samme store organisation måske deler, er faktisk en medarbejderemblem.

Open source vs. proprietær software: Et kig på fordele og ulemper (Tech Pro Research)

Derfor er den indre kilde en spiludveksler. Som Mary Jo Foley har skrevet på ZDNet, selvom Microsoft ikke opfandt indre kilde, kan det være en af ​​de største bestræbelser på at implementere det inden for en Fortune 500-organisation:

Open source-principper såsom mere open code-deling og redigering; muligheden for at oprette nye kodegrener for større kodegenbrug; kodetestning bliver en del af programmeringsprocessen; mere og bedre dokumentation er kernen i, hvordan Indre kilde kan / bør fungere. Indvendige kildeværktøjer og metoder kan bruges til at udvikle åbne og / eller lukkede kildeprojekter og produkter. I modsætning til tilfældet med open source, skal disse processer deles af teams på tværs af en enkelt organisation, ikke nødvendigvis af offentligheden.

Alt dette giver mening og bør hjælpe ingeniørhold med at samarbejde i en organisation.

Åben, men måske ikke 100%

For dem, der er for utålmodige til at vente på endnu et program til at gå i spidsen, har open source-community-guru John Mark Walker tilbudt endnu et tip: Gå hele vejen med open source. Som han begrunder, "En af de lidt kendte hemmeligheder er, at open source tillader eng ineering -team i det samme firma at kollapse orate uden at ledelsen kommer i vejen."

Hvis ingeniører går denne rute, skal de selvfølgelig være forsigtige med at udsætte følsomme data undervejs. Der kan faktisk være for stor gennemsigtighed. For eksempel, i et forsøg på at operere på offentlig GitHub, har jeg set produktteams link til lukkede dokumenter. Selvom kun dem med de rigtige legitimationsoplysninger kan få adgang til disse filer, kan enhver se URL'en, og den URL kan godt indeholde oplysninger, der virkelig ikke burde være offentlig.

Eller tag en anden tilsyneladende uskyldig praksis, jeg har set, med produkthold, der linker til feedback, de har modtaget (igen, på offentlige GitHub). I nogle tilfælde kan denne feedback afsløre downloadnumre, produktoptagelse eller andre data, som en virksomhed foretrækker at holde private. Som en produktleder fortalte mig: "Jeg ser masser af fordele ved at have koden i det fri, men det at have diskussionerne i det åbne virker som et felt af landminer og begrænser hvor meget mit team og jeg føler, at vi kan bidrage til samtaler."

Kort sagt, open source kan være en fantastisk måde at samarbejde i en organisation og på tværs af forskellige organisationer, men især med projekter, hvor et enkelt firma dominerer, kan vi blive for afslappet med privat information, der ikke har plads på det offentlige GitHub. På samme måde holdes nogle indvendige kildetypesamtaler også bedst i et enkelt team, skønt det er næsten altid en god ide at have koderegistret åben for andre (og dokumenteret godt, så det er tilgængeligt for andre).

Microsoft regner ud af dette, både med hensyn til indre kilde og open source. Du ville gøre det godt at følge, mens du sørger for at du ikke afslører alt, hvad der kommer til at fremstille denne produktpølse.

Open Source Ugentlig nyhedsbrev

Du vil ikke gå glip af vores tip, tutorials og kommentarer til Linux OS og open source-applikationer. Leveres tirsdage

Tilmeld dig i dag

© Copyright 2021 | mobilegn.com