Menestyvän InnerSource-ohjelman hallinta

  • 8 minuuttia

Tässä aiheessa kerrotaan, miten voit suunnitella InnerSource-ohjelman, jolla voit hyödyntää ohjelmistokehitysorganisaation parhaita mahdollisia avoimen lähdekoodin malleja.

Mikä on InnerSource?

Kuka tahansa voi vapaasti käyttää, muokata ja jakaa avoimen lähdekoodin ohjelmistoja. Avoimen lähdekoodin ohjelmistoa käyttämällä kuka tahansa voi tarkastella, muokata ja jakaa projektia mihin tahansa tarkoitukseen sillä ajatuksella, että koodin jakaminen johtaa parempiin ja luotettavampiin ohjelmistoihin.

InnerSource on käytäntö soveltaa avoimen lähdekoodin malleja projekteihin, joiden yleisö on rajallinen. Yritys voi esimerkiksi muodostaa InnerSource-ohjelman, joka peilaa tyypillisen avoimen lähdekoodin projektin rakennetta, paitsi että se on vain kyseisen yrityksen työntekijöiden käytettävissä. Itse asiassa se on avoimen lähdekoodin ohjelma yrityksesi palomuurin takana.

InnerSource-edut

InnerSource-ohjelma voi tarjota lukuisia etuja, jotka ylittävät perinteisten suljettujen lähdekoodien mallien tarjoamat.

Ensinnäkin ne tukevat sisäistä näkyvyyttä. Muiden yritysprojektien lähdekoodin käyttö voi auttaa kehittäjiä työskentelemään omissa projekteissaan entistä tuottavammin. He näkevät, miten eri tiimit ratkaisevat samanlaisia ongelmia kuin mitä heillä on edessään, ja löytävät usein koodia ja muita resursseja, joita he voivat käyttää uudelleen. Tiimiongelmien, pull-pyyntöjen ja projektisuunnitelmien käyttö tarjoavat heille myös entistä paremmat tiedot projektin nopeuden ja suunnan ymmärtämiseksi.

Seuraavaksi ne vähentämään kitkaa. Oletetaan, että kuluttajatiimi on riippuvainen toisen tiimin omistaman projektin ohjelmavirhekorjauksesta tai uudesta ominaisuudesta. InnerSource-ohjelmassa heillä on kanava, jonka kautta he voivat ehdottaa tarvitsemiaan muutoksia. Ja jos näitä muutoksia ei voida yhdistää jostain syystä, kuluttajatiimillä on mahdollisuus luoda projekti tarpeidensa mukaisesti.

Lopuksi ne yhdenmukaistaa käytäntöjä. Kehitysorganisaatioiden yleinen haaste on se, että eri tiimit eroavat usein toimintatavoistaan. InnerSource-ohjelman rakentaminen on erinomainen tilaisuus noudattaa vakiokäytäntöjä, joita voidaan käyttää kaikissa kehitystiimissä, vaikka ne eivät noudattaisikaan identtisiä käytäntöjä. Kaksi tiimiä voi esimerkiksi haluta eri prosessit osuuksien vastaanottamiseen. Kun ne standardoivat tapaa, jolla he viestivät eri prosesseistaan, kenen kanssa he ovat mukana, on paljon helpompi osallistua kumpaankin.

Juomaraha

Harkitse GitHub-keskustelujen ja GitHub-projektien käyttöä tukeaksesi edelleen InnerSource-yhteistyötä tiimien välillä.

Nämä esimerkit ovat vain muutamia InnerSource-ohjelmien tarjoamia etuja. Lisätietoja on artikkelissa Johdanto InnerSource-.

InnerSource-ohjelman määrittäminen GitHubissa

Säilön näkyvyyden ja käyttöoikeuksien määrittäminen

Voit määrittää GitHub-säilöihin kolme näkyvyystasoa. Käyttäjät, jotka eivät täytä näkyvyysvaatimuksia, näkevät "ei löydy" -sivuja yrittäessään käyttää säilöäsi. Tasot ovat:

  • julkiset säilöt näkyvät kaikille. Tätä näkyvyyttä voidaan käyttää projekteissa, jotka ovat aidosti avoimen lähdekoodin tyyppisiä, ja jotka tarjoavat pääsyn organisaatiosi sisä- ja ulkopuolella oleville henkilöille.
  • Sisäiset tietovarastot näkyvät vain ne omistavan yrityksen jäsenille.

Huomautus

Sisäiset säilöt ovat vain GitHub Enterprise -asiakkaiden käytettävissä. Käytä tätä näkyvyyttä InnerSource-projekteissa.

  • Yksityiset -säilöt näkyvät vain omistajalle ja heidän lisäämilleen tiimeille tai yksityishenkilöille. Käytä tätä näkyvyyttä projekteissa, joihin vain tietyillä käyttäjillä ja ryhmillä tulisi olla käyttöoikeus.

Kun olet muodostanut säilön näkyvyyden, voit määrittää käyttöoikeudet henkilö- tai tiimikohtaisesti. Käyttöoikeustasoja on viisi:

  • luku- taso on suositeltavaa muille kuin koodausosallistujalle, jotka haluavat tarkastella projektia tai keskustella siitä.
  • Triage taso on suositeltavaa osallistujille, joiden on hallittava ongelmia ja pull-pyyntöjä ennakoivasti ilman kirjoitusoikeuksia.
  • Kirjoitus -tasoa suositellaan osallistujille, jotka aktiivisesti työntävät projektiin.
  • on suositeltavaa ylläpitää tasoa projektipäälliköille, joiden on hallittava säilöä ilman luottamuksellisten tai tuhoisien toimien käyttöoikeutta.
  • järjestelmänvalvojan tasoa suositellaan henkilöille, jotka tarvitsevat täydet käyttöoikeudet projektiin, mukaan lukien arkaluonteiset ja tuhoisat toimet, kuten suojauksen hallinta tai säilön poistaminen.

Lue lisätietoja säilön käyttöoikeuksista tasonmukaan.

Löydettävissävien säilöjen luominen

InnerSource-ohjelman kasvaessa säilöjen määrä todennäköisesti kasvaa merkittävästi. Vaikka on hienoa, että kaikki nämä resurssit ovat organisaation käytettävissä, voi olla haaste löytää sisältöä tehokkaasti. Jotta ongelma voidaan ratkaista ennakoivasti, tiimien on hyvä miettiä, mitä ne voivat tehdä, jotta muiden on helpompi löytää ja käsitellä säilöjään.

Parhaita käytäntöjä ovat esimerkiksi seuraavat:

  • Käytä kuvailevaa säilön nimeä, kuten warehouse-api tai supply-chain-web.
  • Sisällytä lyhyt kuvaus. Virkkeen tai kahden pitäisi riittää, jotta mahdolliset käyttäjät tietävät, sopiiko projekti heidän tarpeisiinsa.
  • Säilön käyttöoikeus, jotta asiakkaat tietävät, miten he voivat käyttää, muuttaa ja jakaa ohjelmistoa.
  • Sisällytä README.md-tiedosto säilöön. GitHub käyttää tätä tiedostoa aloitussivuna, kun käyttäjät käyvät säilössä.

README-tiedoston lisääminen

README-tiedosto ilmoittaa projektisi odotuksista ja auttaa sinua hallitsemaan työpanoksia. README-tiedostot voivat:

  • Määritä projektin tarkoitus ja visio, jotta mahdolliset kuluttajat ymmärtävät, sopiiko se heidän tarpeisiinsa.
  • Tarjoa visuaalisia apuvälineitä, kuten näyttökuvia tai koodinäytteitä, jotka kuvaavat projektia käytännössä.
  • Sisällytä linkit sovelluksen tuotanto- tai esittelyversioon tarkistettavaksi.
  • Määritä odotukset edellytyksille ja käyttöönottotoimille.
  • Sisällytä viittaukset projekteihin, joihin luotat. Nämä viittaukset ovat hyvä tapa edistää muiden työtä.
  • Markdown-syntaksin avulla voit ohjata lukijoita läpi oikein muotoillun sisällön.

Jos laitat README.md tiedostosi arkistosi juurihakemistoon tai piilotettuun .github hakemistoon docs , GitHub tunnistaa ja näyttää README-tiedostosi automaattisesti arkiston kävijöille. Jos arkistossa on useampi kuin yksi README-tiedosto, näytettävä tiedosto valitaan sijainneista seuraavassa järjestyksessä:

  1. Hakemisto .github
  2. Arkiston juurihakemisto
  3. Hakemisto docs

Tutustu joihinkin Mahtavat README-esimerkit.

Kun projekti käynnistyy, ylennä se sähköpostikanavan ja muiden verkkokanavien avulla. Sopivan yleisön saavuttaminen voi lisätä merkittävästi hankkeiden osallistumista.

Lue lisää README-tiedostoista GitHub-dokumentaatiosta.

Projektien hallinta GitHubissa

Kun projektit saavat pitoa, käyttäjien ja osallistumisten tulva voi vaatia paljon työtä. Projektista riippuen saatat tarvita huomattavan paljon työtä vain projektin osallistujien odotusten hallitsemiseen.

GitHub etsii ennakoivasti CONTRIBUTING.md-tiedostoa säilön pääkansiosta (tai /docs tai /.github). Tämän tiedoston avulla voit selittää projektin osallistumiskäytännön. Tarkat tiedot saattavat vaihdella, mutta on hyvä kertoa mahdollisille osallistujille, mitä käytäntöjä projekti noudattaa. Esimerkiksi siellä, missä tiimi etsii pull-pyyntöjä, mitä tietoja ohjelmavirheraportteihin pyydetään ja niin edelleen.

Jos CONTRIBUTING.md on olemassa, GitHub näyttää linkin siihen, kun käyttäjät luovat ongelmia tai pull-pyyntöjä kannustaakseen heitä noudattamaan sitä.

Osallistuminen ohjeisiin -linkit.

Tutustu Awesome CONTRIBUTING.md -esimerkkeihin

Harkitse myös, CODEOWNERS-tiedoston lisäämistä säilöön koodin muokkauksen tarkistamisesta vastaavien henkilöiden tai ryhmien määrittämiseksi.

Aihe- ja pull-pyyntömallien luominen

GitHub tukee aloitusmalleja uusille aiheille ja pull-pyynnöille. Näiden mallien avulla voit antaa juuri luodun ongelman tai pull-pyynnön ensimmäisen kuvaustekstin.

Jos projektissasi on esimerkiksi .github/ISSUE_TEMPLATE.md, aina, kun käyttäjä aloittaa ongelman luomisprosessin, hän näkee tämän sisällön. Sen sijaan, että heidän pitäisi jatkuvasti viitata tarvittaviin tietoihin CONTRIBUTING.md, he voivat vain täyttää ongelman kuten lomakkeen käyttämällä mallitekstiä.

Uusi mallia käyttävä ongelma.

Se on sama pull-pyynnöille, paitsi että polku on .github/PULL_REQUEST_TEMPLATE.md.

Tutustu joihinkin Awesome GitHub -ongelma & pull-pyyntömalleista.

Määritä työnkulut

Jos projekti tukee ulkoista osallistumista, muista määrittää, mitä työnkulkua projekti seuraa. Työnkulun tulee sisältää tietoja siitä, missä ja miten haaroja tulisi käyttää virheiden ja ominaisuuksien kanssa. Sen tulee sisältää myös se, miten pull-pyynnöt avataan, ja muut säilön ulkopuoliset henkilöt tietävät ennen koodin työntämista. Jos sinulla ei vielä ole mielessäsi työnkulkua, kannattaa harkita GitHub-työnkulkua.

Kerro julkaisujen ja käyttöönottojen hallintastrategiasta. Nämä työnkulun osat vaikuttavat päivittäiseen haarautumiseen ja yhdistämiseen, joten on tärkeää välittää ne osallistujille. Lue lisää siitä, miten ne liittyvät Git-haarautumisstrategiaasi.

Ohjelman onnistumisen mittaaminen

Kaikkien InnerSourceen menevien tiimien tulisi miettiä, millaisia mittareita he haluavat seurata seuratakseen ohjelmansa onnistumista. Vaikka perinteiset mittarit, kuten "aika markkinoille" ja "raportoidut ohjelmistovirheet", ovat edelleen sovellettavissa, ne eivät välttämättä kuvaa InnerSourcen kautta saavutettavissa olevia etuja.

Harkitse sen sijaan mittareiden lisäämistä osoittamaan, miten ulkoinen osallistuminen paransi projektin laatua. Vastaanottaakö säilö pull-pyyntöjä ulkoisista lähteistä, jotka korjaavat virheitä ja lisäävät ominaisuuksia? Onko hankkeen ja sen tulevaisuuden keskusteluihin aktiivisia osallistujia? Inspiroiko ohjelma InnerSource-laajennusta, joka tuo etuja muualla organisaatiossa?

Lyhyesti sanottuna mittarit ovat vaikeita, erityisesti kun on kyse yksittäisten ja tiimien panoksen arvon ja vaikutusten mittaamisesta. Jos arvoja käytetään väärin, ne voivat haitata kulttuuria ja olemassa olevia prosesseja ja heikentää kollektiivista suhtautumista organisaation tai johtoryhmän käyttöön. Kun harkitset InnerSource-käyttöönoton mittaamista, ota huomioon seuraavat mittareita koskevat ohjeet:

  • Mittariprosessi, ei tulosta
    • Koodin tarkistuksen täyskäännösaika
    • Pull-pyynnön koko
    • Keskeneräinen työ
    • Avautumisaika
  • Mittaa suhteessa tavoitteisiin eikä absoluuttisiin arvoihin
  • Mittaa tiimejä yksityishenkilöiden lisäksi
    • Projektin yksilöllisten osallistujien määrä
    • Koodia uudelleenkäyttävien projektien määrä
    • Joukkueidenvälisten @mentions

Lue lisää siitä, miten muut ovat nauttineet näistä InnerSource -tapaustutkimuksista.