Introduktion
För inte så länge sedan erbjöd programvaruutvecklingsvärlden två skarpt distinkta modeller: öppen källkod och proprietära. Programvara med öppen källkod gynnades av dess varumärkesöppning: vem som helst får erbjuda bidrag, så många människor gör det. Egenutvecklad programvara begränsar å andra sidan åtkomsten via ett stängt system som värdesätter sekretessen kring den immateriella egendomen (IP).
Anta att du är ledande på ett företag som gjort betydande investeringar i sin egen programvara. Det behöver inte vara ett teknikföretag. Företag i alla former och storlekar skapar och underhåller sin egen programvara och annan immateriell egendom för att vara konkurrenskraftiga i sin bransch. Du har dock utvecklat en stor respekt för de mönster som används i öppen källkod, till exempel synlighet för källkod, information om projektbuggar och transparens för funktionsbegäran. Du gillar också pull-request-modellen som förenklar integreringen av externa bidrag. Du vill använda dig av de här fördelarna i dina utvecklingsteam, men vill inte göra företagets värdefulla programvara till öppen källkod. Vad du behöver är en hybrid som ger fördelarna med båda metoderna. Det du behöver är InnerSource.
I den här modulen får du lära dig hur du hanterar ett lyckat InnerSource-program på GitHub genom effektiv identifiering, vägledning och underhåll.
Utbildningsmål
I den här modulen lär du dig att:
- Kontrastera användar- och organisationsägda projekt.
- Ge rekommendationer om hur många GitHub-organisationer du bör ha.
- Skapa identifieringsbara lagringsplatser.
- Skapa robusta lagringsplats-READMEs.
- Använd mallar för problem och pull-begäranden.
- Skapa transparens i lagringsplatser.
- Mät framgången för InnerSource i din organisation.
- Distribuera din InnerSource-verktygslåda.
Förutsättningar
- Ett GitHub-konto.
- Möjligheten att navigera och redigera filer i GitHub.
- Kunskap om pull-begäranden.
Vi rekommenderar att du slutför introduktionen till GitHub innan du påbörjar den här modulen.