Już w tym tygodniu w Petersburgu odbędzie się festiwal IT . Jednym z prelegentów będzie Richard Stallman. też bierze udział w festiwalu, i oczywiście nie mogliśmy przejść obojętnie obok tematu otwartego oprogramowania. Dlatego jeden z naszych wykładów nosi nazwę . Będzie on poświęcony historii rozwoju Embox jako projektu z otwartym kodem. W tym artykule chcę opowiedzieć o podstawowych ideach, które moim zdaniem wpływają na rozwój projektów opensource. Artykuł, podobnie jak wykład, oparty jest na osobistym doświadczeniu.
Zacznijmy od prostego określenia terminu opensource. Oczywiste jest, że projekt z otwartym kodem to projekt posiadający jedną z licencji, które umożliwiają dostęp do kodu źródłowego projektu. Ponadto otwarty projekt oznacza możliwość wprowadzania zmian przez zewnętrznych programistów. To znaczy, że jeśli jakaś firma lub programista opublikuje kod swojego produktu, częściowo lub w całości, to nie czyni to jeszcze tego produktu projektem opensource. I wreszcie, wszelka działalność projektowa powinna prowadzić do powstania jakiegoś rezultatu, przy czym otwartość projektu oznacza, że ten wynik wykorzystują nie tylko sami programiści.
Nie będziemy poruszać problemów związanych z otwartymi licencjami. To zbyt duży i skomplikowany temat, który wymaga głębokiego zrozumienia. W tej kwestii napisano dość wiele dobrych artykułów i materiałów. Ale ponieważ sam nie jestem specjalistą w dziedzinie prawa autorskiego, powiem tylko, że licencja powinna odpowiadać celom projektu. Na przykład, dla Embox wybór licencji BSD, a nie GPL nie był przypadkowy.
Fakt, że projekt open source musi umożliwiać wprowadzanie zmian i wpływanie na rozwój projektu, oznacza, że projekt jest rozproszony. Zarządzanie nim, zachowanie jego integralności i funkcjonalności jest znacznie trudniejsze w porównaniu do projektu mającego centralne zarządzanie. Pojawia się uzasadnione pytanie, po co w ogóle realizować projekty open source. Odpowiedź leży w obszarze zasadności komercyjnej – w przypadku określonej klasy projektów zyski z takiego podejścia przewyższają koszty. Oznacza to, że nie wszystkie projekty nadają się do otwartego podejścia, a w ogóle możliwe jest takie podejście. Na przykład, trudno wyobrazić sobie opracowanie systemu zarządzania elektrownią lub samolotem, opartego na otwartym zasadzie. Nie, oczywiście w skład takich systemów powinny wchodzić moduły oparte na projektach open source, ponieważ przynosi to wiele korzyści. Ale za końcowy produkt musi ktoś odpowiadać. Nawet jeśli system jest całkowicie oparty na kodzie projektów open source, programista, pakując wszystko w jeden system i dokonując konkretnych kompilacji oraz ustawień, w istocie go zamyka. Kod może być przy tym dostępny publicznie.
Dla tych systemów istnieje wiele zalet z tworzenia otwartych projektów lub uczestnictwa w nich. Jak już powiedziałem, kod końcowego systemu może pozostać publicznie dostępny. Po co, skoro oczywiste jest, że mało kto ma taki sam samolot, aby przetestować system. To prawda, ale mogą się znaleźć chętni, aby sprawdzić pojedyncze fragmenty kodu, lub na przykład, ktoś może odkryć, że używana biblioteka nie jest do końca poprawnie skonfigurowana.
Jeszcze większe korzyści pojawiają się, gdy firma wydziela pewną podstawową część systemu do osobnego projektu. Na przykład, bibliotekę do wsparcia jakiegoś protokołu wymiany danych. W takim przypadku, nawet jeśli protokół jest specyficzny dla danej dziedziny, można podzielić koszty utrzymania tej części systemu z innymi firmami z tej branży. Ponadto specjaliści, którzy mogą zbadać tę część systemu w otwartym dostępie, potrzebują znacznie mniej czasu na jej efektywne wykorzystanie. I wreszcie, wydzielenie fragmentu do samodzielnej jednostki, z której korzystają zewnętrzni deweloperzy, pozwala uczynić tę część lepszą, ponieważ trzeba oferować efektywne API, stworzyć dokumentację, a nawet nie wspominam o poprawie pokrycia testowego.
Firma może uzyskać korzyści komercyjne także bez tworzenia otwartych projektów, wystarczy, aby jej specjaliści brali udział w zewnętrznych projektach wykorzystywanych w firmie. Wszystkie zalety pozostają: pracownicy lepiej znają projekt, co oznacza, że efektywniej go wykorzystują, firma może wpływać na kierunek rozwoju projektu, a korzystanie z gotowego, przetestowanego kodu oczywiście obniża koszty firmy.
Na tym korzyści z tworzenia projektów opensource się nie kończą. Weźmy pod uwagę taki ważny element biznesu jak marketing. Dla niego to bardzo dobra piaskownica, która pozwala efektywnie ocenić wymagania rynku.
I oczywiście nie można zapominać, że projekt opensource jest efektywnym sposobem na zaprezentowanie się jako nośnik jakiejś specjalizacji. W niektórych przypadkach to wręcz jedyny sposób na wejście na rynek. Na przykład, Embox rozpoczął jako projekt tworzenia OSRV. Pewnie nie trzeba tłumaczyć, że jest mnóstwo konkurentów. Bez stworzenia społeczności, po prostu nie mielibyśmy wystarczających zasobów, aby doprowadzić projekt do końcowego użytkownika, czyli aby projekt wykorzystywali zewnętrzni deweloperzy.
Społeczność jest kluczowa w projekcie opensource. Pozwala znacznie obniżyć koszty zarządzania projektem, rozwija i wspiera projekt. Można powiedzieć, że bez społeczności w ogóle nie ma projektu opensource.
O tym, jak stworzyć i zarządzać społecznością projektu z otwartym kodem, napisano wiele materiałów. Ja, aby nie powtarzać znanych faktów, postaram się skupić na doświadczeniach Embox. Na przykład, bardzo interesującym zagadnieniem jest proces tworzenia społeczności. To znaczy, wielu mówi, jak zarządzać istniejącą społecznością, ale momenty jej tworzenia często zostają pominięte, uznawane za coś oczywistego.
Główna zasada przy tworzeniu społeczności projektu open-source to brak jakichkolwiek reguł. Mam na myśli, że nie istnieją uniwersalne zasady, tak jak nie ma srebrnej kuli, chociażby dlatego, że projekty są bardzo różne. Trudno byłoby zastosować te same zasady przy tworzeniu społeczności dla biblioteki logowania w js oraz dla jakiegoś wąsko wyspecjalizowanego sterownika. Co więcej, na różnych etapach rozwoju projektu (a tym samym społeczności) zasady się zmieniają.
Embox rozpoczął się jako projekt studencki, ponieważ mieliśmy dostęp do studentów z katedry programowania systemowego. W zasadzie wchodziliśmy w jakieś inne środowisko. Uczestników tej społeczności, studentów, mogliśmy zainteresować dobrą praktyką przemysłową w ich specjalności, pracami naukowymi w dziedzinie programowania systemowego, pracami semestralnymi i dyplomowymi. To znaczy, że realizowaliśmy jedną z podstawowych zasad organizacji społeczności: uczestnicy społeczności muszą coś zyskać, a cena tego zysku powinna odpowiadać wkładowi uczestnika.
Następnym etapem dla Embox było poszukiwanie zewnętrznych użytkowników. Bardzo ważne jest zrozumienie, że użytkownicy są pełnoprawnymi uczestnikami społeczności open-source. Zazwyczaj użytkowników jest więcej niż programistów. Aby stać się współtwórcą projektu, najpierw w ten czy inny sposób zaczynają go używać.
Pierwszymi użytkownikami Embox była Katedra Teoretycznej Cybernetyki. Zaproponowali stworzenie alternatywnego oprogramowania dla Lego Mindstorm. I chociaż byli to wciąż lokalni użytkownicy (mogliśmy się z nimi spotkać osobiście i omówić, czego potrzebują), to i tak był to bardzo dobry doświadczenie. Na przykład stworzyliśmy demo, które mogły być pokazane innym, ponieważ roboty są ciekawe i przyciągają uwagę. Ostatecznie pojawiły się prawdziwe zewnętrzne użytkownicy, którzy zaczęli pytać, czym jest Embox i jak z niej korzystać.
Na tym etapie musieliśmy zacząć myśleć o dokumentacji i środkach komunikacji z użytkownikami. Oczywiście myśleliśmy o tych ważnych rzeczach wcześniej, ale to było przedwcześnie i nie przynosiło pozytywnego efektu. Efekt był raczej negatywny. Podam kilka przykładów. Używaliśmy googlecode, którego wiki wspierało wielojęzyczność. Stworzyliśmy strony w kilku językach, nie tylko w angielskim i rosyjskim, na których mogliśmy, w miarę możliwości, komunikować się, ale także w niemieckim i hiszpańskim. W rezultacie było bardzo nieporadnie, gdy pytano w tych językach, a my nie mogliśmy w ogóle odpowiedzieć. Wprowadzaliśmy również zasady pisania dokumentacji i komentarzy, ale ponieważ API zmieniało się dość często i w sposób istotny, nasza dokumentacja szybko stawała się przestarzała i wprowadzała w błąd bardziej niż pomagała.
Ostatecznie wszystkie nasze wysiłki, nawet te niepoprawne, doprowadziły do pojawienia się zewnętrznych użytkowników. Zjawił się nawet komercyjny zleceniodawca, który chciał, abyśmy opracowali dla niego własny system operacyjny. I opracowaliśmy go, ponieważ mamy doświadczenie i pewne rozwiązania. Muszę opowiedzieć zarówno o dobrych, jak i o złych momentach. Zacznę od rzeczy złych. Ponieważ wielu programistów zostało zaangażowanych w ten projekt na podstawie komercyjnej, społeczność, i tak dość nieustabilizowana, podzieliła się, co oczywiście nie mogło nie wpłynąć na rozwój projektu. Dodatkowym czynnikiem było to, że kierunek projektu był określany przez jednego kluczowego zleceniodawcę, a jego celem nie było dalsze rozwijanie projektu. Przynajmniej ten cel nie był priorytetowy.
Z drugiej strony, było wiele pozytywnych aspektów. Otrzymaliśmy naprawdę zewnętrznych użytkowników. To byli nie tylko klienci, ale także ci, dla których ten system został stworzony. Motywacja do uczestnictwa w projekcie wzrosła. W końcu, jeśli na interesującym przedsięwzięciu można również zarobić, to zawsze jest miłe. Co najważniejsze, usłyszeliśmy jedno życzenie klientów, które wówczas wydawało nam się dziwne, ale które teraz jest główną ideą Embox, a mianowicie, wykorzystanie w systemie już opracowanego kodu. Teraz główną ideą Embox jest użycie oprogramowania Linux bez Linuxa. To znaczy, że głównym pozytywnym aspektem sprzyjającym dalszemu rozwojowi projektu było uświadomienie sobie, że projekt jest używany przez zewnętrznych użytkowników i ma rozwiązywać ich problemy.
W tamtym czasie Embox już wyszedł poza ramy projektu studenckiego. Głównym czynnikiem hamującym rozwój projektu w modelu studenckim jest motywacja uczestników. Studenci biorą udział, dopóki się uczą, a kiedy kończą studia, muszą mieć inną motywację. Jeśli motivacja się nie pojawi, student po prostu przestaje uczestniczyć w projekcie. Jeśli wziąć pod uwagę, że studentów najpierw trzeba nauczyć, to okazuje się, że dobrymi specjalistami stają się w momencie ukończenia studiów, ale ich wkład w projekt, z powodu braku doświadczenia, nie jest zbyt wielki.
Ogólnie rzecz biorąc, płynnie przechodzimy do głównego momentu, który pozwala mówić o stworzeniu projektu open source — stworzeniu produktu, który rozwiązuje problemy jego użytkowników. Jak już wcześniej wyjaśniłem, podstawową cechą projektu open source jest jego społeczność. A uczestnicy społeczności to przede wszystkim użytkownicy. Ale skąd mają się wziąć, skoro nie mają z czego korzystać? Okazuje się więc, że podobnie jak w przypadku projektu nie-open source, trzeba skupić się na stworzeniu MVP (minimalnego opłacalnego produktu), a jeśli przyciągnie to użytkowników, wokół projektu pojawi się społeczność. Jeśli jednak zajmiemy się tworzeniem społeczności tylko poprzez PR, pisanie wiki we wszystkich językach świata albo odpowiedni workflow git na GitHubie, to mało prawdopodobne, żeby miało to znaczenie na wczesnych etapach projektu. Oczywiście, na odpowiednich etapach są to nie tylko ważne, ale również konieczne rzeczy.
Na zakończenie pragnę przytoczyć , moim zdaniem odzwierciedlający oczekiwania użytkownika wobec projektu opensource:
Poważnie myślę o przejściu na ten system operacyjny (przynajmniej na spróbowanie. Zbyt aktywnie go rozwijają i robią niesamowite rzeczy).
P. S. Na będziemy mieli aż trzy prezentacje. Jedna dotyczy open source, a dwie dotyczą embedded (przy czym jedna będzie praktyczna). Na stoisku przeprowadzimy warsztat programowania mikrokontrolerów przy użyciu . Tradycyjnie przywieziemy sprzęt i pozwolimy go zaprogramować. Będzie też quest i inne aktywności. Zapraszamy na festiwal i na nasze stoisko, będzie wesoło.
Źródło: habr.com
