Open source – to się wszystkim opłaca. Dlaczego warto stać się częścią tej kultury?

Jakie korzyści bliskiej współpracy ze społecznością może przynieść wszystkim zaangażowanym stronom? W jaki sposób monetyzować projekty open source? Te i inne tajniki pracy w ramach modelu open source zdradza Marek Lewandowski, Team leader w CKSource, firmie odpowiedzialnej za sukces CKEditora 5.

Jaki cel powinien przyświecać każdemu autorowi projektu open source?

Opowiem o kilku elementach. Po pierwsze: transparentność, czyli coś, czego każdy szuka w projektach typu open source. Co to oznacza? Z mojej perspektywy dwie rzeczy: komunikowanie zmian oraz otwarcie na feedback od użytkowników. Po drugie: stabilność i utrzymanie bezpieczeństwa. Nikt nie chce, żeby zmiany w naszym projekcie zaskutkowały błędami w rozwiązaniach, za które odpowiadamy. Po trzecie: skalowanie projektu; warto go przygotować tak, aby jego wykorzystanie i ewentualne modyfikacje były jak najłatwiejsze.

Co ze współpracą z innymi? Często za danym projektem stoi samodzielny twórca.

Jednoosobowa praca nie skaluje się zbyt dobrze wraz z rozrostem projektu, a co za tym idzie – także wobec rosnących oczekiwań społeczności. Niejednokrotnie widziałem ciekawe projekty tworzone przez ludzi mających problem z dzieleniem się odpowiedzialnością. Zdarza się, że autorzy wychodzą założenia: „tylko ja zrobię to dobrze”, mają tendencję do traktowania projektów jako osobistych perełek.

Powinno być inaczej?

Tak, powinieneś być otwarty na pomoc. To szczególnie istotne, gdy o projekcie mówi się coraz więcej i zaczyna odnosić pierwsze sukcesy. Warto rozglądać się za osobami, którym chcesz zaufać i z którymi podzielisz się odpowiedzialnością za projekt. Takie podejście rozwija nie tylko sam projekt, ale także nas samych, naszą zdolność komunikacji.

Jak wyznaczyć cel, do którego warto dążyć? Jak podchodzisz do tej kwestii?

Sporo zależy od samego autora projektu. CKSource jest przykładem dużego projektu open source, którego twórcy wsłuchują się w potrzeby użytkowników. Z drugiej strony często widzimy biblioteki pasjonatów z własną wizją, którą realizują, nie zwracając uwagi na feedback od społeczności.

To złe rozwiązanie?

Wszystko zależy od tego, jaki model rozwoju chcesz obrać jako właściciel projektu. Wyróżniam tu dwa podejścia. Pierwsze nastawienie polega na tym, że chcemy zrobić jakiś projekt, który przyda się społeczności – samodzielnie albo w grupie. CKEditor jest tego doskonałym przykładem, bo tworzymy rozbudowane narzędzie, którego żadna firma średnich rozmiarów nie jest w stanie wykonać we własnym zakresie. Uważam, że pracując nad CKEditorem, w pełni wykorzystujemy siłę open source, czyli robimy wszystko, by wiele środowisk mogło uczestniczyć w rozwoju naszego darmowego narzędzia.

Drugie podejście opiera się na samodzielnej pracy autora, który chce dany problem rozwiązać w wybrany przez siebie sposób. Często z góry przyjmuje arbitralne rozwiązanie, żeby podążać w tym konkretnym kierunku, jest uparty i zamknięty w swoim dążeniu do celu. Uważa, że tylko on ma rację, odrzucając wizje i pomysły innych. To głównie domena osób pracujących przy małych projektach, które nie mają dużej ekspozycji.

Rozumiem, wróćmy do celów…

Cele, które wyznaczysz, będą zależały od tego, którą ścieżką chcesz podążać. Jeżeli chcesz zrobić duży projekt, który ma trafić do szerokiej społeczności, to siłą rzeczy musisz trafiać w potrzeby użytkowników, działać tak, żeby jak najwięcej osób widziało wartość w twoim projekcie i chciało w nim kontrybuować.

W przypadku małych projektów cele wyznaczasz sam, ale ważne jest to, żeby realizować je konsekwentnie, ponieważ w momencie, kiedy podchodzisz do tego zbyt luźno, to zaczynają się one rozmywać. Pomaga to uniknąć sytuacji, gdy równocześnie zaczynasz pracę nad wieloma aspektami swojego projektu, a tak naprawdę nie kończysz żadnego z nich. Lepszym podejściem będzie zaplanowanie poszczególnych działań i zajęcie się po kolei każdym z nich.

Co zrobić, gdy społeczność proponuje rozwiązanie, a ty niekoniecznie uważasz je za dobre?

W tym przypadku ważne jest stonowanie reakcji, niepodejmowanie decyzji pod wpływem chwili, niebranie pod uwagę tylko własnych przekonań. Dobrym rozwiązaniem jest rozpoczęcie dyskusji i poproszenie społeczności, żeby przedstawiła jak najwięcej use case’ów. Warto pozwolić wypowiedzieć się jak największej liczbie osób i dać sobie czas na podjęcie decyzji, również w oparciu o te nowe informacje. Uzyskując te wszystkie dane, możemy zadecydować co dalej.

Sporo zależy także od tego, jak mocno zaangażowana w projekt jest twoja społeczność: często jest tak, że większość osób korzystających z twojego projektu nie śledzi na bieżąco dyskusji. Nie bałbym się wtedy skorzystać z social mediów – ankieta na Twitterze, blog post zachęcający do udziału w dyskusji na GitHubie, dyskusja na Discordzie mogą być bardzo pomocne. Gdy po przeanalizowaniu sugerowanych rozwiązań okaże się, że to nie jest kierunek, w którym chcemy podążać, jasno zakomunikujmy, dlaczego tak uważamy.

Są jednak przypadki, kiedy społeczność ma rację. W CKSource mieliśmy co najmniej dwie fundamentalne decyzje podjęte po wskazówkach społeczności, a mniejszych decyzji tego rodzaju było więcej. Dzięki temu, że uwzględniamy ich opinie, ludzie mają poczucie, że ich pomysły i zaangażowanie są dla nas ważne.

Jak wyglądało angażowanie społeczności wokół waszego produktu? Czy w ciągu ostatnich lat zmieniliście podejście? Teraz jest łatwiej?

Mam wrażenie, że kiedyś użytkownicy byli bardziej zaangażowani, przez co utrzymanie społeczności było łatwiejsze. Projektów open source’owych było za to dużo mniej. Dyskusje toczyły się gdzieś na forach, dlatego też wtedy prowadziliśmy własne forum. Jakiś czas temu przenieśliśmy się na GitHub, ale trzymamy rękę na pulsie nie tylko tam – obserwujemy też nasze posty w social mediach oraz komentarze, głównie na Twitterze. Dzisiaj bibliotek jest bardzo wiele, rynek jest rozdrobniony.

Jako developerzy mamy też dużo mniej czasu na to, żeby analizować używane biblioteki open source. Staramy się więc budować świadomość społeczności przez czystą komunikację.

Co to oznacza w praktyce?

Na GitHubie mamy przypiętą rozmowę, gdzie informujemy, nad czym będziemy pracować w najbliższym czasie, co znajdzie się w kolejnej aktualizacji. Informujemy też o rzeczach, które są dla nas kluczowe i rozciągają się na 2-4 release’y (w tym czasie jesteśmy też otwarci na feedback od użytkowników).

W jaki sposób wypromowaliście wasz edytor w społeczności?

Wypromowaliśmy edytor głównie poprzez sam produkt. Developerzy, trafiając na naszą bibliotekę – czy to z polecenia, czy też po przetestowaniu naszego demo – zapamiętywali produkt i chętnie do niego wracali. Trudno w to uwierzyć, ale przez bardzo długi czas nie mieliśmy nikogo, kto zajmowałby się stricte marketingiem. Dzisiaj działamy już szerzej. Dbamy o to, żeby jakość edytora mówiła sama za siebie, ale mamy również dedykowany team odpowiedzialny za marketing, jeździmy też na najróżniejsze branżowe konferencje.

Oferty pracy z

Interesująca jest też perspektywa rynkowa. Jak wygląda praca w projekcie open source od strony biznesowej?

To, co pozwala nam utrzymać projekt w takim stanie, w jakim jest to właśnie mądre połączenie oferty darmowej i płatnej. Z założenia CKEditor ma być darmowy i łatwo dostępny dla każdego – po to, by nikt nie musiał już martwić się o rzeczy, które były problemem jeszcze kilkanaście, kilkadziesiąt lat temu, kiedy tego typu edytorów nie było.

W ofercie premium oferujemy rozwiązania, które wymagają od nas użycia płatnej infrastruktury, np. usługi dotyczące współpracy, które są teraz bardzo na czasie i ludzie ich potrzebują. Taka współpraca (collaboration) wymaga jednak synchronizacji czy też backendu, który będzie dobrze działał, a to generuje koszty. W ofercie premium jest też kilka dodatkowych funkcjonalności, których nie ma w podstawowej wersji edytora.

Inną sprawą jest to, że mimo iż jesteśmy projektem open source, to duże firmy lubią mieć umowy, które gwarantują bezpieczeństwo i wsparcie z naszej strony. A nie dostaniesz lepszego supportu od nikogo innego, jak od twórców danej biblioteki. To istotna usługa w świecie biznesu, a duża liczba naszych klientów korzystających z tego rodzaju wsparcia jest tego najlepszym dowodem.

Trzecim filarem wsparcia darmowego biznesu są customowe prace, które wykonujemy według specyfikacji klienta. Słuchamy, jakie są jego wymagania, doradzamy mu i wchodzimy w implementację pełnych, gotowych rozwiązań.

Te trzy elementy sprawiają, że mamy silną dywersyfikację, jeśli chodzi o wsparcie naszego modelu biznesowego. I funkcjonuje to świetnie – nie tylko pomaga zabezpieczać naszą działalność, ale też pozwala nam inwestować i rozwijać cały ekosystem.

Czy istnieje coś takiego, jak kultura pracy w ramach modelu open source?

Wykonując pracę w ramach projektu open source, masz dużą ekspozycję na jej efekty, co dla niektórych może być stresujące, ale po krótkim czasie staje się wielką zaletą. Społeczność dokładnie widzi, co robisz, do jakiego fragmentu dorzuciłeś swoje rozwiązanie – co jest świetne i stanowi właśnie część kultury open source. Wielu z nas łapie bakcyla i nawet gdy tworzymy własne, mniejsze projekty, to robimy je właśnie w trybie open source. Przesiąkasz tym modelem, co rzutuje na całą twoją pracę. Jestem wielkim zwolennikiem tej kultury. Gdy siadam do własnego projektu, to jest już dla mnie intuicyjny wybór, by prowadzić go w formule open source.

Inną sprawą jest to, że duże projekty open source wymagają bardzo dobrej dokumentacji. Generalnie programiści intuicyjnie radzą sobie nieźle z dokumentowaniem API, lecz zaskakująco niewielu z nich potrafi tworzyć dobrą dokumentację opisującą cały podsystem czy też architekturę. Praca w projekcie open source, a w szczególności praca z ludźmi, którzy mają w tym obszarze duże doświadczenie, pozwala nam wejść na nowy poziom.

Pracując przy szanującym się projekcie, nie masz też pokus zastosowania nieeleganckich albo nieprzemyślanych rozwiązań, czy też wszelkiej maści “haxów”, bo nie chcesz, żeby takie rzeczy wisiały w kodzie.

Zobacz też

PM Team Leader to niekoniecznie kolejny etap kariery seniora. Wywiad z Bartoszem Czerwonką

Jak praca nad projektem typu open source wpływa na rozwój programisty? Co się traci, a co zyskuje, pracując nad jednym projektem?

Pozwolę sobie wypunktować zalety i wady pracy nad projektem open source:

Zalety:

• efekty twojej pracy są dostępne dla wszystkich – powszechna dostępność kodu bywa trochę onieśmielająca i stresująca, ale to szybko mija,
• masz dostęp do dużej liczby użytkowników (inni programiści, designerzy, end userzy), dzięki czemu poznajesz różne kultury,
• z moich obserwacji wynika, że tego typu projekty przyciągają ludzi, którzy chętnie dzielą się swoją wiedzą oraz są wyjątkowo zaangażowani,
• możliwość solidnego dopracowania produktu – nie musisz skakać z miejsca na miejsce oraz masz czas i motywację, żeby dopracować procesy,
• duża przewidywalność,
• niska rotacja w zespole.

Minusy:

• teoretycznie masz mniejszą ekspozycję na rozmaite technologie, ale nie jest to zasada, bo sporo zależy od otwartości zespołu. Musimy spędzić dużo czasu na planowaniu, jaką bibliotekę będziemy wykorzystywać, a następnie konsekwentnie się jej trzymać i pamiętać o kosztach jej wymiany. Gdybyśmy np. szli za trendami, bo pojawia się nowa, ciekawa biblioteka, nie do końca sprawdzona, ale którą fajnie byłoby u nas zweryfikować, ponosilibyśmy olbrzymie koszty samej transformacji, a ona mogłaby nie przynieść żadnych wymiernych korzyści dla naszych użytkowników. Należy unikać takich sytuacji; inaczej jest, gdy mamy małe projekty, w których możemy zaryzykować
• gdy masz powtarzalne, software’owe projekty, np. projektujesz kolejny rozkład jazdy, nic nie stoi na przeszkodzie, by powiedzieć: “dobra, może spróbujmy innej biblioteki, bo w necie piszą, że jest lepsza”. I czasem to “zażre”, a czasem nie – i wtedy zostawiasz klienta z projektem i modlisz się, żeby nic nie zgłaszał, a jak “zażre”, to później możesz to wykorzystywać w kolejnych projektach

Rozmawiamy o monetyzacji projektów open source, skupmy się teraz na CKSource. W jaki sposób monetyzujecie swoje produkty?

Monetyzacja oparta jest o kilka źródeł.

Edytor CKSource jest udostępniony w ramach open sourcowej licencji GPLv2 lub wyższej. Licencja ta wymaga, aby aplikacje wykorzystujące naszą bibliotekę same stały się open source. Nie wszyscy nasi klienci chcą publikować kod źródłowy – w tym wypadku potrzebują komercyjnej licencji na korzystanie z naszego komponentu – jest to jedno z naszych źródeł finansowania.

Dalej mamy usługi cloudowe, które wymagają infrastruktury. Chodzi tu np. o usługi związane ze współpracą dla edytora czy też konwertery HTML do PDF / Word (DOCX).

W ofercie mamy również pluginy premium, przy czym staramy się, aby w darmowej dystrybucji było tak dużo funkcjonalności, jak to tylko możliwe.

Kolejną opcją jest custom development, czyli tworzenie indywidualnych rozwiązań według potrzeb klienta. Są to często bardzo duże projekty.

Kto korzysta z waszych produktów? Kto jest grupą docelową?

Mamy to szczęście, że nasz główny produkt ma niezwykle szerokie zastosowanie. Właściwie dowolna strona, czy też aplikacja, gdzie wymagana jest praca z tekstem to idealne miejsce do użycia CKEditora. Tak więc mogę powiedzieć, że niemal każdy z nas jest w grupie docelowej (tak, programiści też – jeśli korzystacie z ZenDeska, to używacie CKEditora 5!).

Edytor CKSource błyszczy najmocniej, gdy używamy go do tekstu sformatowanego oraz współpracy wielu użytkowników. Wszechstronność naszego edytora szczególnie doceniają firmy, które mają możliwość stworzenia idealnych integracji dla swoich treści.

Jednak edytor CKSource – za sprawą swojej rozszerzalności – może być dobrym wyborem również dla tekstu niesformatowanego (tzw. plain text). W ten sposób można wzbogacić go o funkcjonalności takie jak Mentions, Special characters czy też możliwość wstawiania szablonów. Standardowe kontrolki do wprowadzania tekstu dostępne w HTML nie mają takich możliwości rozszerzania.

Jakie macie plany na przyszłość?

Zmierzamy do dywersyfikacji naszych produktów przy jednoczesnym poszerzaniu funkcjonalności oferowanych przez nasz edytor.

Dla przykładu nową linią produktów są autorskie konwertery do plików PDF czy też Worda. Mogę powiedzieć, że w niedalekiej przyszłości zobaczymy więcej ciekawych projektów oferowanych przez CKSource.

Intensywnie pracujemy nad nowymi funkcjonalnościami dodawanymi do edytora. Większość naszych comiesięcznych release’ów dorzuca, zazwyczaj większą, nową funkcjonalność. Pracujemy też nad nowymi funkcjonalnościami premium; przykładem może być Revision History.

Marek Lewandowski. Team leader w CKSource. Zwolennik kultury open source. Na co dzień wspiera zespoły, które tworzą rozwiązania dla klientów CKSource oraz pomaga w identyfikacji ich wymagań. Mając ponad dekadę doświadczenia w tworzeniu oprogramowania, chętnie dołącza do rozmów zespołów nietechnicznych, aby wspomagać je swoją wiedzą. W wolnych chwilach projektuje układy elektroniczne, wdraża systemy IoT i relaksuje się przy muzyce.