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 biorą udział w projektach ponieważ dostrzegają 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 trzymać te ulepszenia z powrotem w prywatnych rozwidleń, są one zmuszane do współtworzenia tych zmian z powrotem do repozytorium źródłowego, aby stać się częścią planu bazowego projektu. Ten cenny cykl ulepszania jest powodem, dla którego wiele firm wytwarza oprogramowania 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ą lub wykorzystują repozytoria innych.
- Współautorzy, którzy aktywnie uczestniczą w ulepszaniu repozytoriów innych.
- Producenci, którzy tworzą i utrzymują własne repozytoria, otwarte dla innych osób.
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ą żadnego procesu. Powodzenie zależy od indywidualnych wysiłków.
- Zarządzane, które mają częściowo udokumentowany proces. Powodzenie zależy od dyscypliny.
- Zdefiniowane, które mają udokumentowany, znormalizowany i zintegrowany proces. 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ć, w jakim punkcie znajduje się organizacja, sprawdź Samooceny oprogramowania 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 to istotne zasady, które należy wyrazić. 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 temacie Przewodnik dotyczący kodeksów postępowania dla oprogramowania 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 powinniśmy wydać ten projekt w modelu open-source?”, który zawiera ramy umożliwiające podjęcie decyzji, czy analizowany projekt powinien być realizowany w modelu 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 zgodny na użycie modelu open source dla projektu, przegląd kodu w celu zapewnienia, że dane poufne zostaną usunięte przed uruchomieniem projektu, znak towarowy lub wyszukiwanie projektu open source, aby upewnić się, że nie występuje konflikt nazw 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że zostać sklonowane jako punkt wyjścia. 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 dotyczący konserwacji, który wyjaśnia obowiązki osoby odpowiedzialnej za konserwację pod kątem utrzymania 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.mdlubCODE_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 dostarczają zatwierdzonych odpowiedzi na najczęstsze 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 dotyczące licencji, które zawierają informacje o licencjach zatwierdzonych lub odrzuconych przez dział prawny w odniesieniu do używania lub współtworzenia zasobów typu open source.