W tym tygodniu w Petersburgu odbędzie się festiwal IT . Jednym z prelegentów będzie Richard Stallman. również bierze udział w festiwalu i oczywiście nie mogliśmy pominąć tematu wolnego oprogramowania. Dlatego jeden z naszych raportów nosi nazwę . Będzie ono poświęcone historii rozwoju Emboxa jako projektu open source. W tym artykule chcę omówić główne idee, które moim zdaniem wpływają na rozwój projektów open source. Artykuł, podobnie jak raport, powstał na podstawie osobistych doświadczeń.
Zacznijmy od czegoś prostego, od definicji terminu opensource. Projekt open source to oczywiście projekt, który posiada jedną z licencji umożliwiającą dostęp do kodu źródłowego projektu. Ponadto otwarty projekt oznacza, że zewnętrzni programiści mogą wprowadzać zmiany. Oznacza to, że jeśli jakaś firma lub programista opublikuje kod swojego produktu, częściowo lub w całości, nie czyni to jeszcze tego produktu projektem open source. I wreszcie każde działanie projektowe musi prowadzić do jakiegoś rezultatu, a otwartość projektu oznacza, że z wyniku tego korzystają nie tylko sami deweloperzy.
Nie będziemy poruszać problemów otwartych licencji. Jest to temat zbyt obszerny i złożony, wymagający dogłębnego zbadania. Na ten temat napisano już wiele dobrych artykułów i materiałów. Ponieważ jednak sam nie jestem ekspertem w dziedzinie prawa autorskiego, powiem tylko, że licencja musi spełniać cele projektu. Na przykład w przypadku Emboxa wybór licencji BSD zamiast licencji GPL nie był przypadkowy.
Fakt, że projekt open source powinien zapewniać możliwość wprowadzania zmian i wpływać na rozwój projektu open source, oznacza, że projekt jest rozpowszechniany. Zarządzanie nim, utrzymanie integralności i wydajności jest znacznie trudniejsze w porównaniu z projektem ze scentralizowanym zarządzaniem. Powstaje rozsądne pytanie: po co w ogóle otwierać projekty? Odpowiedź leży w obszarze wykonalności komercyjnej; w przypadku pewnej klasy projektów korzyści z takiego podejścia przewyższają koszty. Oznacza to, że nie nadaje się do wszystkich projektów i ogólnie akceptowalne jest podejście otwarte. Trudno sobie na przykład wyobrazić opracowanie systemu sterowania elektrownią czy samolotem w oparciu o zasadę otwartą. Nie, oczywiście, takie systemy powinny zawierać moduły oparte na otwartych projektach, ponieważ zapewni to szereg korzyści. Ale ktoś musi być odpowiedzialny za produkt końcowy. Nawet jeśli system jest całkowicie oparty na kodzie otwartych projektów, programista po spakowaniu wszystkiego w jeden system i wykonaniu określonych kompilacji i ustawień w zasadzie go zamyka. Kod może być publicznie dostępny.
Istnieje również wiele korzyści dla tych systemów z tworzenia lub współtworzenia projektów open source. Jak już mówiłem, kod systemu końcowego może pozostać publicznie dostępny. Dlaczego, bo oczywiste jest, że jest mało prawdopodobne, aby ktokolwiek miał ten sam samolot do testowania systemu. To prawda, ale może się zdarzyć, że znajdzie się ktoś, kto będzie chciał sprawdzić pewne sekcje kodu lub na przykład ktoś może odkryć, że używana biblioteka nie jest skonfigurowana całkiem poprawnie.
Jeszcze większa korzyść pojawia się, gdy firma przeznaczy jakąś podstawową część systemu na osobny projekt. Na przykład biblioteka obsługująca jakiś protokół wymiany danych. W takim przypadku, nawet jeśli protokół jest specyficzny dla danego obszaru tematycznego, możesz podzielić się kosztami utrzymania tego fragmentu systemu z innymi firmami z tego obszaru. Ponadto specjaliści, którzy mogą studiować ten fragment systemu w domenie publicznej, potrzebują znacznie mniej czasu, aby efektywnie go wykorzystać. I wreszcie wydzielenie części na niezależną całość, z której korzystają zewnętrzni programiści, pozwala nam ulepszyć tę część, ponieważ musimy oferować skuteczne interfejsy API, tworzyć dokumentację, a nie mówię nawet o poprawie zasięgu testów.
Firma może czerpać korzyści komercyjne bez tworzenia projektów open source, wystarczy, że jej specjaliści będą uczestniczyć w zewnętrznych projektach stosowanych w firmie. Przecież wszystkie korzyści pozostają: pracownicy lepiej znają projekt, dzięki czemu efektywniej z niego korzystają, firma może wpływać na kierunek rozwoju projektu, a wykorzystanie gotowego, zdebugowanego kodu w oczywisty sposób obniża koszty firmy.
Na tym nie kończą się korzyści płynące z tworzenia projektów open source. Weźmy tak ważny element biznesu jak marketing. Dla niego jest to bardzo dobra piaskownica, która pozwala mu skutecznie oceniać wymagania rynku.
I oczywiście nie możemy zapominać, że projekt open source to skuteczny sposób na zadeklarowanie się jako nosiciel dowolnej specjalizacji. W niektórych przypadkach jest to jedyny sposób na wejście na rynek. Na przykład Embox zaczął jako projekt mający na celu stworzenie systemu RTOS. Konkurencji chyba nie trzeba tłumaczyć. Bez stworzenia społeczności po prostu nie mielibyśmy wystarczających zasobów, aby udostępnić projekt użytkownikowi końcowemu, czyli zewnętrznym programistom, którzy mogliby zacząć korzystać z projektu.
Społeczność jest kluczowa w projekcie open source. Pozwala znacznie obniżyć koszty zarządzania projektami, rozwijać i wspierać projekt. Można powiedzieć, że bez społeczności nie ma w ogóle projektu open source.
Napisano wiele materiałów na temat tworzenia społeczności projektów open source i zarządzania nimi. Aby nie powtarzać już znanych faktów, spróbuję skupić się na doświadczeniach z Emboxem. Bardzo ciekawym zagadnieniem jest na przykład proces tworzenia społeczności. Oznacza to, że wielu mówi, jak zarządzać istniejącą społecznością, ale momenty jej powstania są czasami pomijane, uważając to za oczywiste.
Główną zasadą podczas tworzenia społeczności projektu open source jest brak zasad. Mam na myśli, że nie ma uniwersalnych zasad, tak jak nie ma złotego środka, choćby dlatego, że projekty są bardzo różne. Jest mało prawdopodobne, abyś mógł zastosować te same zasady podczas tworzenia społeczności dla biblioteki rejestrującej js i jakiegoś wysoce wyspecjalizowanego sterownika. Co więcej, na różnych etapach rozwoju projektu (a co za tym idzie społeczności) zasady się zmieniają.
Embox zaczynał jako projekt studencki, ponieważ miał dostęp do studentów z działu programowania systemów. Tak naprawdę wkraczaliśmy w jakąś inną wspólnotę. Moglibyśmy zainteresować uczestników tej społeczności, studentów, dobrą praktyką przemysłową w ich specjalności, pracą naukową z zakresu programowania systemowego, zajęciami dydaktycznymi i dyplomami. Oznacza to, że kierowaliśmy się jedną z podstawowych zasad organizowania społeczności: członkowie społeczności muszą coś otrzymać, a cena ta musi odpowiadać wkładowi uczestnika.
Kolejnym etapem dla Emboxa było poszukiwanie zewnętrznych użytkowników. Bardzo ważne jest, aby zrozumieć, że użytkownicy są pełnoprawnymi uczestnikami społeczności open source. Zwykle jest więcej użytkowników niż programistów. A żeby chcieć stać się współtwórcą projektu, najpierw zaczynają go wykorzystywać w taki czy inny sposób.
Pierwszymi użytkownikami Emboxa była Katedra Cybernetyki Teoretycznej. Zaproponowali stworzenie alternatywnego oprogramowania dla Lego Mindstorm. I chociaż byli to nadal lokalni użytkownicy (mogliśmy spotkać się z nimi osobiście i przedyskutować, czego chcą). Ale i tak było to bardzo dobre doświadczenie. Na przykład opracowaliśmy demonstracje, które można pokazać innym, ponieważ roboty są zabawne i przyciągają uwagę. W rezultacie zyskaliśmy naprawdę zewnętrznych użytkowników, którzy zaczęli pytać, czym jest Embox i jak z niego korzystać.
Na tym etapie musieliśmy pomyśleć o dokumentacji, o sposobie komunikacji z użytkownikami. Nie, oczywiście myśleliśmy o tych ważnych sprawach już wcześniej, ale było to przedwczesne i nie dało pozytywnego efektu. Efekt był raczej negatywny. Podam kilka przykładów. Użyliśmy Googlecode, którego wiki wspierało wielojęzyczność. Stworzyliśmy strony w kilku językach, nie tylko angielskim i rosyjskim, w których ledwo mogliśmy się porozumieć, ale także niemieckim i hiszpańskim. W rezultacie pytanie w tych językach wygląda bardzo absurdalnie, ale w ogóle nie możemy odpowiedzieć. Albo wprowadzili zasady dotyczące pisania dokumentacji i komentowania, ale skoro API zmieniało się dość często i znacząco, to okazało się, że nasza dokumentacja była przestarzała i bardziej wprowadzała w błąd, niż pomagała.
W rezultacie wszystkie nasze wysiłki, nawet te błędne, doprowadziły do pojawienia się użytkowników zewnętrznych. Pojawił się nawet klient komercyjny, który chciał, aby opracowano dla niego własny RTOS. Opracowaliśmy go, ponieważ mamy doświadczenie i pewne podstawy. Tutaj musisz porozmawiać zarówno o dobrych, jak i złych chwilach. Zacznę od tych złych. Ponieważ wielu deweloperów było zaangażowanych w ten projekt na zasadach komercyjnych, społeczność była już dość niestabilna i podzielona, co oczywiście nie mogło nie wpłynąć na rozwój projektu. Dodatkowym czynnikiem było to, że kierunek projektu został wyznaczony przez jednego klienta komercyjnego i jego celem nie był dalszy rozwój projektu. Przynajmniej nie to było głównym celem.
Z drugiej strony było wiele pozytywnych aspektów. Mamy naprawdę zewnętrznych użytkowników. Chodziło nie tylko o klienta, ale także o tych, dla których ten system był przeznaczony. Wzrosła motywacja do udziału w projekcie. W końcu jeśli można też zarobić na ciekawym biznesie, to zawsze miło. A co najważniejsze, usłyszeliśmy od klientów jedno pragnienie, które wówczas wydawało nam się szalone, ale które obecnie jest główną ideą Emboxa, a mianowicie wykorzystania w systemie już opracowanego kodu. Teraz główną ideą Emboxa jest używanie oprogramowania Linux bez Linuksa. Oznacza to, że głównym pozytywnym aspektem przyczyniającym się do dalszego rozwoju projektu było uświadomienie sobie, że projekt jest używany przez zewnętrznych użytkowników i powinien rozwiązać część ich problemów.
W tym czasie Embox wykroczył już poza zakres projektu studenckiego. Głównym czynnikiem ograniczającym rozwój projektu według modelu studenckiego jest motywacja uczestników. Studenci uczestniczą w zajęciach podczas studiów, a po ich ukończeniu powinna istnieć inna motywacja. Jeżeli motywacja nie pojawia się, student po prostu przestaje uczestniczyć w projekcie. Jeśli weźmiemy pod uwagę, że studentów trzeba najpierw przeszkolić, okazuje się, że po ukończeniu studiów stają się dobrymi specjalistami, jednak ich wkład w projekt, ze względu na brak doświadczenia, nie jest zbyt duży.
Generalnie płynnie przechodzimy do głównego punktu, który pozwala nam mówić o stworzeniu projektu open source - stworzeniu produktu, który rozwiązałby problemy jego użytkowników. Jak wyjaśniłem powyżej, główną cechą projektu open source jest jego społeczność. Co więcej, członkowie społeczności to przede wszystkim użytkownicy. Ale skąd się biorą, kiedy nie ma z czego skorzystać? Okazuje się więc, że podobnie jak w przypadku projektu non-opensource, trzeba skupić się na stworzeniu MVP (minimalnie opłacalnego produktu), a jeśli zainteresuje to użytkowników, to wokół projektu pojawi się społeczność. Jeśli zajmujesz się tworzeniem społeczności wyłącznie poprzez PR społeczności, pisanie wiki we wszystkich językach świata lub poprawianie przepływu pracy w git na githubie, jest mało prawdopodobne, aby miało to znaczenie na wczesnych etapach projektu. Oczywiście na odpowiednich etapach są to rzeczy nie tylko ważne, ale i niezbędne.
Podsumowując, chciałbym zwrócić uwagę moim zdaniem odzwierciedlające oczekiwania użytkowników dotyczące projektu open source:
Poważnie zastanawiam się nad przejściem na ten system operacyjny (przynajmniej spróbuj. Aktywnie go realizują i robią fajne rzeczy).
PS Włącz Będziemy mieli aż trzy raporty. Jeden o otwartym kodzie źródłowym i dwa o osadzeniu (jeden jest praktyczny). Na stoisku poprowadzimy master class z programowania mikrokontrolerów z wykorzystaniem . Jak zwykle przywieziemy sprzęt i umożliwimy jego zaprogramowanie. Będzie też misja i inne atrakcje. Przyjdźcie na festiwal i na nasze stoisko, będzie fajnie.
Źródło: www.habr.com