Cel

Powszechny jest pogląd, że oprogramowanie open-source powstaje po godzinach, w wolnych chwilach. Choć w dużej części przypadków jest to prawda, takie podejście budzi zawsze wątpliwość, czy projekt nie zostanie z jakiegoś powodu anulowany. Pół biedy, gdy jest on popularny i pracuje nad nim z dziesięć osób. Na miejsce jednego wchodzi natychmiast kolejny. Jednak są perełki tworzone przez pojedynczych pasjonatów, które wraz z ich rezygnacją umierają śmiercią naturalną. Są to sytuacje ekstremalne. Znacznie częściej bywa, że rozwój takiego projektu jest zakłócany przez inne wydarzenia. Znam to z autopsji, bo nawet ostatnia wersja OPT została wydana znacznie później, niż to było planowane, z powodu przedłużających się prac nad przedsięwzięciem komercyjnym.

Warto też poruszyć kwestię motywacji. Choć cała idea open-source opiera się na swobodnym współdzieleniu efektów własnej pracy, człowiek nie jest maszyną. Może siąść przed komputerem i stwierdzić, że dziś mu się nie chce nic robić na poczet projektu, a skoro nikt go nie ściga, nic się nie stanie. Na sam koniec pozostawiłem kwestię kosztów utrzymania projektu, bowiem w przypadku każdej większej pracy kiedyś przyjdzie taki moment, że trzeba będzie coś sfinansować. Jeżeli się nie ma akurat tyle pieniędzy, kombinuje się z zamiennikami, które nie zawsze są najwyższych lotów. Wszystko to rzutuje na ogólny rozwój całego projektu.

Zalety

Gdy projekt open-source przynosi dochód, odbija się to pozytywnie na całokształcie. Są pieniądze na serwery, są pieniądze na inwestycje, na które normalnie nie można by było sobie pozwolić. I wreszcie: jeśli dochód jest odpowiednio duży, aby się z niego utrzymać, programista może poświęcić mu cały swój czas zawodowy. W dalszej perspektywie użytkownicy zyskują bardziej dopracowany kod, który jest poddawany staranniejszym oględzinom. Można powiedzieć, że jest to wzajemna relacja. Użytkownicy, którym projekt się spodobał lub którzy potrzebują go do jakichś dziwnych celów, płacą za niego i w zamian oczekują, że dostaną coś adekwatnego do poniesionych kosztów. Więc aby tacy użytkownicy nie zrezygnowali i nie zrobili antyreklamy, konieczna jest staranność.

Z grubsza można wyróżnić dwa modele zarabiania na projektach open-source. Część firm lub osób prywatnych stosuje podwójne licencjonowanie kodu. Ogólna społeczność otrzymuje pakiet na którejś z wolnych licencji, zaś gdy licencja ta powoduje problemy ze sposobem wykorzystania projektu (najczęściej działalność komercyjna), twórcy oferują możliwość wykupienia innej. Jednak ogólnie patrząc, licencje open-source wcale nie zabraniają pobierania opłat za rozpowszechniane na ich warunkach oprogramowanie. Sztuczka leży w tym, że jeśli takowe kupisz, możesz je legalnie udostępnić innym za darmo. Przez to zwykłe umieszczenie paczki na własnym serwerze i przycisku "Kup teraz za 100 złotych" nie zdaje egzaminu. Sens robi się większy, gdy w parze za tym idą dodatkowe korzyści. Więcej materiałów informacyjnych, zestaw nowych modułów czy pomoc techniczna to tylko niektóre z udogodnień. Można zapytać, dlaczego dostępne są one za opłatą. Odpowiedź jest prosta: gdyby nie było ich dostępnych za opłatą, najprawdopodobniej nie byłoby ich w ogóle. Niestety, przygotowanie cyklu tutoriali oraz ich aktualizacja to pracochłonne zajęcie. Za darmo żaden człowiek nie będzie na wezwanie pod telefonem 24 godziny niezależnie od tego, co aktualnie robi - inna sprawa, że przy większej liczbie użytkowników jest to także niewykonalne. Tak samo wiele innych dodatków wymaga czasu, który wtedy byłby tak cenny, że nie starczyłoby go na pisanie nowego kodu. To są realia. Jeśli są pieniądze, można to komuś zlecić bez obawy, że dwa dni później powie, że mu się jednak nie chce.

Słuszność

Zwróćmy uwagę, że w tym wszystkim kluczowe jest słowo dobrowolność. Samo oprogramowanie dostępne jest dla każdego zainteresowanego za darmo. Może je legalnie ściągnąć, przetestować, przerobić, wysłać znajomym i nikt go za to do więzienia nie wsadzi. Nie przyjdzie do niego żaden pan z pytaniem, gdzie ma certyfikat autentyczności. Jeżeli projekt mu się spodoba, może wesprzeć autora finansowo, ale nikt go do tego nie zmusza. A jeśli wiąże się to z otrzymaniem szeregu dodatków? Czemu nie?

Uważam, że każdy programista ma prawo do wynagrodzenia za swoją pracę. Jeśli projekt podoba się, należy mu się coś za to, że mu się chciało i dopiął swego - że poświęcił swój czas, żebym ja nie musiał poświęcać swojego. Bo tak naprawdę gdy się coś samemu zacznie pisać, wtedy widzi się, że to nie powstaje w jeden wieczór przy piwku i pizzy, tylko niekiedy wymaga naprawdę sporej gimnastyki oraz umiejętności, które w końcu także na drzewach nie rosną. Może zaprezentuję małą ilustrację sprzed kilku dni z prac nad dziedziczeniem w OPTv2. Pierwsze wyobrażenie po przeczytaniu możliwości: "przyszedł, siadł, napisał, opublikował, fajne". W praktyce zasiadnięcie do klawiatury poprzedzał pewien okres przemyśleń, jak powinien wyglądać całokształt i jak go wbudować w już istniejący kod z zachowaniem kompatybilności. Było tam trochę rozważań w stylu "zrobić tak, czy tak". W końcu nadszedł pewien wieczór i stwierdziłem, że pora to ostatecznie zakodować. Gdyby rozpisać to godzinowo, wyglądałoby to mniej więcej tak:

• 17.00 - rozpoczynam przegląd istniejącego kodu. Kartka w ruch. Znalazłem notatki z wczoraj.
• 17.20 - ustaliłem miejsca, które będą wymagać przeróbki oraz wstępną koncepcję, jak je przerobić. Rozpoczynam kodowanie.
• 17.40 - dokończyłem kodowanie instrukcji snippetów i insertów, bo coś tam brakowało. Stworzyłem szkielet dla "extend". Nagle mi się przypomniało, że muszę jeszcze jedną rzecz zmienić, by mój pomysł w ogóle zadziałał.
• 18.00 - OK, zmienione. Pasuje do tego, do tego, do tego... o cholera, ale przecież obecny rezultat się lekko kłóci z zamiarami. Świeżo napisany kod do poprawy.
• 18.10 - zabieram się za przeróbkę kompilatora. Kurde, najlepiej byłoby to przenieść do osobnej metody i sprawić, aby nie przechowywało tych danych w polach klasy. Rozpoczynam więc prace.
• 18.40 - kod uporządkowany pod zmiany. Zaczynamy testy.
• 19.00 - OK, kod zdebugowany i się nie sypie. Przy okazji sprawdziłem też snippety. Krótka przerwa. Trzeba coś zjeść.
• 19.30 - wracam do kodu. Hmmm... napisałem 10 linijek, ale coś mi tu nie gra cały czas. Mam wrażenie, że to nie będzie działać w tej formie. Zaczynam krążyć po domu i myśleć.
• 20.00 - znów wracam do kodu. Kasuję to i piszę w innym kształcie. Będzie potrzebna struktura drzewa.
• 20.15 - drzewo ukończone. Trzeba je podpiąć.
• 20.20 - przejdźmy do parsera, bo tam też trzeba dopisać nową metodę.
• 20.40 - kurrrr.... straszny się burdel zrobił, parę rzeczy wypada wysłać do osobnych metod.
• 21.00 - Napisałem instrukcję "extend". Powrót do kompilatora.
• 21.30 - kurde, większość tego, co jest w instrukcji "extend", musi być w kompilatorze bezpośrednio, gdyż za bardzo to ingeruje w jądro.
• 21.40 - siadam nad kartką papieru i rozpisuję sobie działanie.
• 22.00 - shit, kompilator mi wyszedł taki, że jeszcze potrzebuję paru rzeczy w parserze. Przerabiam.
• 22.30 - gotowe, sprawdzone. Tja, jednak część rzeczy wraca do "extend". Czas na jakiś test.
• 22.40 - nie działa. Szukamy przyczyny.
• 23.00 - kij wie, czemu to nie działa. Hmmm... a tak w ogóle to jak się ta reszta szablonów w dziedziczeniu zachowa, gdy to się zacznie rekompilować? Kartka w dłoń.
• 23.20 - nie. To nie może być tak kompilowane. Błąd w założeniach. Siedzę nad kartką.
• 23.30 - przyjmuję koncepcję poprzednio odrzuconą. Dla pewności raz jeszcze rozrysowuję schemat kompilacji.
• 23.50 - tak, teraz już mam pewność, że w takiej postaci zadziała to, jak trzeba. Wykasowałem parę linijek w kompilatorze. Ale późno. Idę spać.
• 8.00 - z powrotem na kodzie. OK, dokończyłem usuwanie tego, co zbędne, z metody kompilującej. Zaczynam przeróbkę.
• 8.40 - przeróbka w kompilatorze skończona. Piszę teścik.
• 8.45 - teścik działa, ale coś dziwnie przymula. Debugujemy.
• 9.20 - ok, mam błąd. Przy okazji trochę zmodyfikowałem metody w parserze. Działa.
• 9.30 - hmmm... trochę śmieci zostało po tym moim. Ale trudno. Wychodzę.
• 11.00 - jestem z powrotem. Czas na porządki.
• 11.15 - Wywaliłem drzewo, bo niepotrzebne. Posprzątałem po "extend". Przejrzałem kod, pododawałem komentarze. Jeszcze parę testów.
• 11.35 - działa. Piszemy notkę na bloga.
• 12.14 - notka poszła w świat.

Około 9 godzin wyjętych z życia. Co prawda wiele rzeczy, jakie pozostały do zrobienia nie jest aż tak czasochłonnych pod względem planowania, ale jednak też sporo zabierają. A jak do tego doliczymy kolejne biblioteki...

Wady

Niestety do wad modelu częściowo płatnego można zaliczyć ludzkie podejście. Człowiek najchętniej chciałby mieć dużo pieniędzy i wszystko za darmo, a że jest to tak samo realne, jak silnik Carnotta, w rzeczywistości jest myślami bliżej lub dalej tego niedoścignionego ideału. Dlatego na widok ofert zakupu niektórzy mogą zrezygnować ze wspierania, nawet pomimo faktu, że uczestniczą w wielu innych projektach, które z czegoś takiego korzystają (chociażby PHP i komercyjna wersja Zend Core, żeby daleko nie szukać). Jak na mój gust, jest to bardzo nieostrożna krótkowzroczność. Osobiście nie mam absolutnie nic przeciwko wspieraniu projektu prowadzonego według jednego z powyższych modeli. Jeśli autorzy uznali, że dobrowolne dotacje są zbyt niepewne i oferują rozszerzony pakiet, w którym mogą znaleźć się moje poprawki - dopóki są one dostępne także za darmo, niech oferują. Zaczęli ten projekt, stworzyli cały szkielet oraz strukturę organizacyjną. Niech mają coś z tego. Ponadto pomyślmy też inaczej: jeśli aktywnie włączę się w rozwój, być może twórcom tak się spodobają poprawki i propozycje, że zapragną mieć mnie w zespole, "za kulisami"?

Zakończenie

Podsumowując - moim zdaniem idea pieniędzy i open-source nie tylko nie są ze sobą sprzeczne, ale idą ze sobą w parze. Odpowiednie fundusze mądrze dysponowane wpływają pozytywnie na całe przedsięwzięcie i w dłuższej perspektywie mogą podnieść jego jakość. Oczywiście korzyści odczuwają wszyscy użytkownicy: i Ci, którzy płacą, i Ci, którzy stwierdzili, że płatna wersja im niepotrzebna. Osobiście nie miałbym nic przeciwko tworzeniu open-source na etacie. Pracuję dla społeczności, bez żadnych nie-wiedzących-czego-chcą-klientów, i nie muszę martwić się o pieniądze dzięki stałej pensji... jak dla mnie, oferta kusząca.

Powrót

Na Zyxist.com panuje swoboda wyrażania opinii oraz krytyki pod dowolnym adresem. Jedyny warunek: musi być ona kulturalna i rzeczowa. Na chamstwo, prostactwo lub jawne obrażanie kogokolwiek nie ma tu miejsca i takie komentarze są bardzo szybko usuwane. Jeśli zamierzasz polemizować z treścią wpisu, wpierw uważnie ją przeczytaj.