Jak stworzyć program open source

W tym miejscu omówimy kluczowe zagadnienia dotyczące tworzenia programu open source.

Co oznacza "open source?"

Program typu open source to więcej niż publiczny dostęp do bazy kodu. Polega na stworzeniu żyjącego projektu, w którym uczestniczyć może każda zainteresowana osoba. W przypadku prawidłowego wykonania odpowiedniego projektu program open source może pomóc w istotnych ulepszeniach jakości produktu.

Jednym z kluczowych powodów, dla których firmy realizują projekty open-source jest chęć zaangażowania społeczności. Popularne projekty otrzymują znaczną pomoc ze strony społeczności, w dodatku otrzymują ją nieodpłatnie.

Niekoniecznie wynika to z altruizmu. Osoby i organizacje wykorzystują projekty, ponieważ widzą korzyści osobiste lub biznesowe. Gdy projekt nie spełnia swoich potrzeb lub oczekiwań, może skorzystać z możliwości rozwiązania usterek lub dodania funkcji. Zamiast zatrzymywać te ulepszenia w prywatnych rozgałęzieniach, są zmuszani do wprowadzania tych zmian z powrotem do repozytorium źródłowego, aby stać się częścią podstawy projektu. Ten cnotliwy cykl poprawy jest powodem, dla którego wiele firm tworzy oprogramowanie przy użyciu modelu open source.

Cele oprogramowania open source

Reasumując, istnieją trzy wymiary uczestnictwa w oprogramowaniu open source:

• Użytkownicy, którzy badają repozytoria innych użytkowników lub korzystają z nich.
• Współtwórcy, którzy aktywnie uczestniczą w ulepszaniu repozytoriów innych osób.
• Producenci, którzy tworzą i utrzymują własne repozytoria, które są otwarte dla innych użytkowników.

Ponieważ organizacje dokładniej zastanawiają się nad tym, co chcą uzyskać z każdego wymiaru, dobrą praktyką jest dokonywanie oceny tego, w jakim miejscu się obecnie znajdują. W każdym wymiarze istnieje pięć poziomów procesowych.

• Ad hoc, które nie mają ustanowionego procesu. Powodzenie zależy od indywidualnych wysiłków.
• Zarządzane, które mają proces częściowo udokumentowany. Powodzenie zależy od dyscypliny.
• Zdefiniowane, które charakteryzują się udokumentowanym, ustandaryzowanym oraz zintegrowanym procesem. Powodzenie zależy od automatyzacji.
• Mierzone, które mają proces zarządzany ilościowo. Powodzenie zależy od pomiaru metryk w odniesieniu do celów biznesowych.
• Zoptymalizowane, które mają proces, który jest stale i niezawodnie ulepszany przez zarówno przyrostowe, jak i innowacyjne zmiany. Powodzenie zależy od ograniczenia ryzyka zmiany.

Aby lepiej zrozumieć, gdzie stoi Twoja organizacja, zapoznaj się z ocenami własnymi typu open source.

Co warto realizować w modelu open source?

Wiele projektów nie jest przeznaczonych do wielkości open source. Chociaż kryteria mogą się różnić w zależności od celów i poziomu procesów firmy, poniżej przedstawiono kilka zalecanych kryteriów, które należy wziąć pod uwagę przed otwarciem projektu:

• Czy projekt zawiera własność intelektualną, która ma być chroniona? Jeśli tak, otwarcie jego kodu źródłowego spowoduje przekazanie jego wartości. Nie należy otwierać takich projektów, chyba że uważasz, że korzyści przewyższają ryzyko.

• Czy projekt jest w stabilnym stanie z dobrą jakością kodu? Projekt nie musi być doskonały, ale potencjalni współautorzy mogą odejść, jeśli projekt jest w strasznej formie, aby rozpocząć.

• Czy projekt jest przydatny dla osób spoza firmy? Jeśli nie, prawdopodobnie nie otrzymujesz żadnego udziału.

• Czy osoby spoza firmy mogą współtworzyć swoje działania? Potrzebują oni dostępu do wszystkich zależności projektu, procesów kompilacji i innych elementów potrzebnych do uruchomienia projektu. Jeśli nie mogą go uruchomić, nie mogą współtworzyć.

• Czy zespół posiada przepustowość umożliwiającą obsługę programu open source? Jeśli nie, zaczekaj, aż to zrobisz. Jeśli projekt typu open source nie jest obsługiwane, możesz stracić możliwość utworzenia zaufanej społeczności.

Te pytania to tylko kilka z najbardziej podstawowych kwestii do rozważenia. Organizacja może mieć inne problemy z działalnością biznesową lub zgodnością, aby pamiętać.

Projektowanie programu open source

Prowadzenie programu open source jest podobne do prowadzenia programu InnerSource, ale dla odbiorców publicznych. W związku z tym istnieje jeszcze kilka zagadnień.

Ustalenie oczekiwań społeczności

Pliki takie jak README.md i CONTRIBUTING.md są jeszcze ważniejsze, ponieważ są one udostępniane osobom, które nie mają kontekstu organizacyjnego. Należy je ocenić z perspektywy kogoś spoza firmy, aby zapewnić przejrzystość.

Ponadto kodeks postępowania jest ważną polityką do wyrażenia. Standardem jest dodanie CODE_OF_CONDUCT.md pliku do katalogu głównego repozytorium i użycie go w celu wyjaśnienia zachowania oczekiwanego od uczestników w społeczności. Wiele grup w organizacji powinno przejrzeć ten dokument, w tym zespół prawny. Na szczęście dostępnych jest wiele standardowych kodeksów postępowania, od których można zacząć. Wiele projektów używa tych kodeksów w wyjściowej formie, bez żadnych modyfikacji. Dowiedz się więcej w przewodniku dotyczącym kodeksów postępowania typu open source.

Przygotowanie pracowników do obsługi repozytorium

Pracownicy mogą nie mieć doświadczenia w pracy ze społecznością open source. Aby ułatwić im przygotowanie, zalecamy, aby firma oferowała zestaw przewodników, które obejmują najważniejsze rzeczy, które każdy powinien wiedzieć przed rozpoczęciem pracy. Te przewodniki powinny być publikowane w wewnętrznym repozytorium lub portalu, które jest regularnie obsługiwane i dostępne tylko dla pracowników firmy. Poniżej przedstawiono kilka najważniejszych przewodników:

• Przewodnik "Czy ten projekt powinien być open source?" zawierający strukturę do decydowania, czy projekt kandydata powinien być open source. Ten przewodnik może być zbudowany w formie schematu blokowego, zestawu pytań lub listy kwestii do rozważenia.

• Lista kontrolna konfiguracji zawierająca wszystkie elementy robocze, które zespół musi ukończyć przed uruchomieniem projektu open source i po nim. Ta lista powinna obejmować uzyskanie zgody na otwarcie projektu jako open source, przeglądy kodu w celu zapewnienia, że poufne dane zostały usunięte, zanim projekt zostanie uruchomiony, poszukiwanie znaku towarowego lub projektu open source, aby upewnić się, że nie występuje konflikt nazewnictwa, itd.

• Lista kontaktów dla kluczowych osób w organizacji, z którymi może być konieczne skontaktowanie się w przypadku, gdy wymagana jest bezpośrednia pomoc techniczna od opiekunów. Ta lista powinna obejmować osoby odpowiadające za kwestie zabezpieczeń oprogramowania, zabezpieczeń lokacji, prawne, public relations i inne.

• Link do repozytorium początkowego, które można sklonować jako punkt startowy. Powinien on zawierać przykładowy plik README, licencję, kodeks postępowania, przewodnik dla współautorów oraz wszelkie inne pliki pomocnicze, które muszą posiadać projekty open source firmy. Nie powinien zawierać żadnych elementów, które nie powinny zostać przypadkowo udostępnione odbiorcom publicznym.

• Przewodnik osoby odpowiedzialnej za konserwację, który wyjaśnia obowiązki osoby odpowiedzialnej za utrzymanie repozytorium w dobrej kondycji. Te obowiązki obejmują aktualizowanie dokumentacji repozytorium, zapewnienie, że problemy i żądania ściągnięcia zwracają uwagę odpowiednich osób w odpowiednim czasie i tak dalej.

• Przewodnik po komunikacji, który oferuje wskazówki dotyczące obsługi repozytoriów dla niektórych tematów, których nie chcesz uwzględniać w plikach publicznych, takich jak README.md, CONTRIBUTING.mdlub CODE_OF_CONDUCT.md. Tematy te mogą być wrażliwe na tematy biznesowe, takie jak brak dyskusji na temat konkurencji; lub bardziej ogólne tematy dotyczące postępowania, takie jak sposób odpowiedniego rozpoznawania najważniejszych współautorów.

• Wewnętrzne często zadawane pytania, które zawierają zatwierdzone odpowiedzi na typowe pytania. Ta lista jest szczególnie przydatna, jeśli istnieją prawne subtelności dotyczące tematów, które firma może omówić w trakcie utrzymywania programu open source.

• Zasady licencji, które zawierają listę licencji, które zostały zatwierdzone lub odrzucone przez dział prawny na potrzeby korzystania z oprogramowania open source lub współtworzenia.